From owner-svn-src-stable-7@FreeBSD.ORG Wed Mar 10 13:56:22 2010 Return-Path: Delivered-To: svn-src-stable-7@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C05D6106566C; Wed, 10 Mar 2010 13:56:22 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 991528FC1C; Wed, 10 Mar 2010 13:56:22 +0000 (UTC) Received: from lemongrass.sec.cl.cam.ac.uk (lemongrass.sec.cl.cam.ac.uk [128.232.18.47]) by cyrus.watson.org (Postfix) with ESMTPSA id 8CB2D46B51; Wed, 10 Mar 2010 08:56:21 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <201003100815.40537.jhb@freebsd.org> Date: Wed, 10 Mar 2010 13:56:15 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <2F464F17-5C54-4815-A1EE-0BC92B1A8C2E@freebsd.org> References: <201003092210.o29MABkU044256@svn.freebsd.org> <201003100815.40537.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1077) 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 X-BeenThere: svn-src-stable-7@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for only the 7-stable src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 13:56:22 -0000 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=