From owner-svn-src-head@FreeBSD.ORG Fri May 15 10:13:37 2009 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0C621065687 for ; Fri, 15 May 2009 10:13:37 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by mx1.freebsd.org (Postfix) with SMTP id B24F08FC1D for ; Fri, 15 May 2009 10:13:37 +0000 (UTC) (envelope-from pho@holm.cc) Received: (qmail 171 invoked from network); 15 May 2009 10:13:35 -0000 Received: from 87.58.145.190 (HELO x2.osted.lan) (87.58.145.190) by relay00.pair.com with SMTP; 15 May 2009 10:13:35 -0000 X-pair-Authenticated: 87.58.145.190 Received: from x2.osted.lan (localhost.osted.lan [127.0.0.1]) by x2.osted.lan (8.14.2/8.14.2) with ESMTP id n4FADZxU031440; Fri, 15 May 2009 12:13:35 +0200 (CEST) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.14.2/8.14.2/Submit) id n4FADZ9f031439; Fri, 15 May 2009 12:13:35 +0200 (CEST) (envelope-from pho) Date: Fri, 15 May 2009 12:13:35 +0200 From: Peter Holm To: Kostik Belousov Message-ID: <20090515101335.GA31378@x2.osted.lan> References: <200905141054.n4EAsvp1088977@svn.freebsd.org> <20090515070239.GQ58540@hoeg.nl> <20090515080613.GA27593@x2.osted.lan> <20090515094852.GC1927@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090515094852.GC1927@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i Cc: svn-src-head@freebsd.org, Ed Schouten , svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r192094 - head/sys/kern X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 10:13:38 -0000 On Fri, May 15, 2009 at 12:48:52PM +0300, Kostik Belousov wrote: > On Fri, May 15, 2009 at 10:06:13AM +0200, Peter Holm wrote: > > On Fri, May 15, 2009 at 09:02:39AM +0200, Ed Schouten wrote: > > > Hi Kostik, > > > > > > * Konstantin Belousov wrote: > > > > Log: > > > > Do not advance req->oldidx when sysctl_old_user returning an > > > > error due to copyout failure or short buffer. > > > > > > > > The later breaks the usermode iterators of the sysctl results that pack > > > > arbitrary number of variable-sized structures. Iterator expects that > > > > kernel filled exactly oldlen bytes, and tries to interpret half-filled > > > > or garbage structure at the end of the buffer. In particular, > > > > kinfo_getfile(3) segfaulted. > > > > > > > > Reported and tested by: pho > > > > MFC after: 3 weeks > > > > > > Is it possible that this change introduces a regression? Right now > > > `pstat -t' gets stuck in an infinite loop. I've added the following > > > printf: > > > > > > | Index: pstat.c > > > | =================================================================== > > > | --- pstat.c (revision 192128) > > > | +++ pstat.c (working copy) > > > | @@ -263,6 +263,7 @@ > > > | if (errno != ENOMEM) > > > | err(1, "sysctlbyname()"); > > > | len *= 2; > > > | + printf("Going to %zu\n", len); > > > | if ((xttys = realloc(xttys, len)) == NULL) > > > | err(1, "realloc()"); > > > | } > > > > > > pstat on -CURRENT prints: > > > > > > | LINE INQ CAN LIN LOW OUTQ USE LOW COL SESS PGID STATE > > > | Going to 0 > > > | Going to 0 > > > | Going to 0 > > > | ... > > > > > > If I use the same patch on RELENG_6, I get the expected result: > > > > > > | LINE RAW CAN OUT IHIWT ILOWT OHWT LWT COL STATE SESS PGID DISC > > > | Going to 272 > > > | Going to 544 > > > | Going to 1088 > > > | Going to 2176 > > > | Going to 4352 > > > | Going to 8704 > > > | sysmouse 0 0 0 0 0 0 0 0 - 0 0 term > > > | ... > > > > > > So the problem is that sysctl overwrites the len argument with 0, even > > > if it returns back to userspace with ENOMEM. > > > > > > I see we have two changes in sysctl. In theory it could also be related > > > to jhb@'s changes to sysctl locking, but I suspect it's less likely. > > > > > > > I can confirm that it is r192094 that triggers the loop. > > Yes, this is what I mean when talked about a breakage. > > Below is the reversal of r192094 + the change to keep the old, ugly > behaviour of sysctl kern.proc.filedesc to return 0 on ENOMEM, but with > oldlen chopped at the end of the last completely written struct kern_info > instead of the middle of partially-written one. > > Peter, could you, please, retest ? Right away. - Peter