Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 10 Mar 2010 13:56:15 +0000
From:      "Robert N. M. Watson" <rwatson@freebsd.org>
To:        John Baldwin <jhb@freebsd.org>
Cc:        svn-src-stable@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, svn-src-stable-7@freebsd.org
Subject:   Re: svn commit: r204931 - in stable/7/sys: amd64/include i386/include
Message-ID:  <2F464F17-5C54-4815-A1EE-0BC92B1A8C2E@freebsd.org>
In-Reply-To: <201003100815.40537.jhb@freebsd.org>
References:  <201003092210.o29MABkU044256@svn.freebsd.org> <alpine.BSF.2.00.1003100025290.9081@fledge.watson.org> <201003100815.40537.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On Mar 10, 2010, at 1:15 PM, John Baldwin wrote:

> On Tuesday 09 March 2010 7:27:06 pm Robert Watson wrote:
>>=20
>> On Tue, 9 Mar 2010, John Baldwin wrote:
>>=20
>>> Log:
>>> MFC 183525: Bump MAXCPU to 32 now that 32 CPU x86 systems exist.
>>=20
>> Hmmm.  I'd be a bit surprised if this doesn't cause ABI issues for=20
>> management/crashdump analysis tools, and KBI problems for kernel =
modules,=20
>> although it being 12:30am I'm having trouble thinking of specific =
instances=20
>> currently.
>=20
> That did occur to me.  I could revert it.  The public KBI for modules =
is that=20
> they should be using mp_maxid and not MAXCPU.  Generally MAXCPU is =
only used=20
> for sizing static arrays for early boot before malloc() is available, =
and that=20
> code cannot be run from a KLD anyway (even kld's loaded via the loader =
don't=20
> start running SYSINITs until after SI_SUB_KLD).  I think other uses of =
MAXCPU=20
> are most likely broken and that MAXCPU should not be part of the =
public KBI,=20
> but only for use in the kernel image itself.  DPCPU in 8.0 makes this =
process=20
> 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=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2F464F17-5C54-4815-A1EE-0BC92B1A8C2E>