svn commit: r204931 - in stable/7/sys: amd64/include
i386/include
Robert N. M. Watson
rwatson at freebsd.org
Wed Mar 10 13:56:22 UTC 2010
On Mar 10, 2010, at 1:15 PM, John Baldwin wrote:
> On Tuesday 09 March 2010 7:27:06 pm Robert Watson wrote:
>>
>> On Tue, 9 Mar 2010, John Baldwin wrote:
>>
>>> Log:
>>> MFC 183525: Bump MAXCPU to 32 now that 32 CPU x86 systems exist.
>>
>> Hmmm. I'd be a bit surprised if this doesn't cause ABI issues for
>> management/crashdump analysis tools, and KBI problems for kernel modules,
>> although it being 12:30am I'm having trouble thinking of specific instances
>> currently.
>
> That did occur to me. I could revert it. The public KBI for modules is that
> they should be using mp_maxid and not MAXCPU. Generally MAXCPU is only used
> for sizing static arrays for early boot before malloc() is available, and that
> code cannot be run from a KLD anyway (even kld's loaded via the loader don't
> start running SYSINITs until after SI_SUB_KLD). I think other uses of MAXCPU
> are most likely broken and that MAXCPU should not be part of the public KBI,
> but only for use in the kernel image itself. DPCPU in 8.0 makes this process
> even easier for modules that need per-CPU data relative to 7 perhaps.
My worry was that code might size an array in a module using the old MAXCPU, and assume that mp_maxid is always < MAXCPU, or that curcpu (or similar) is always < MAXCPU. I agree that breakage in this area is likely a bug but I'm not sure whether it's a theoretical bug or one that real code will see. It's probably worth looking at what code that knows about CPU workers (such as the cxgb driver, perhaps some crypto stuff, a geom module or two) DTRT before reverting, and checking to make sure things like vmstat -m/-z don't blow up too much.
Robert
More information about the svn-src-stable-7
mailing list