From owner-svn-src-all@FreeBSD.ORG Wed Mar 10 14:40:25 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 969B3106564A; Wed, 10 Mar 2010 14:40:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 654898FC16; Wed, 10 Mar 2010 14:40:25 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 177AC46B92; Wed, 10 Mar 2010 09:40:25 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 604F48A025; Wed, 10 Mar 2010 09:40:24 -0500 (EST) From: John Baldwin To: "Robert N. M. Watson" Date: Wed, 10 Mar 2010 09:38:35 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <201003092210.o29MABkU044256@svn.freebsd.org> <201003100815.40537.jhb@freebsd.org> <2F464F17-5C54-4815-A1EE-0BC92B1A8C2E@freebsd.org> In-Reply-To: <2F464F17-5C54-4815-A1EE-0BC92B1A8C2E@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003100938.35279.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 10 Mar 2010 09:40:24 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx 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-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 14:40:25 -0000 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