svn commit: r204931 - in stable/7/sys: amd64/include i386/include

[John Baldwin]

On Wednesday 10 March 2010 8:56:15 am Robert N. M. Watson wrote:
> 
> 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.

Grr, it looks like some opensolaris and dtrace code uses MAXCPU, so I will
revert.

-- 
John Baldwin