From owner-svn-src-all@FreeBSD.ORG Fri May 15 13:20:38 2009 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 2B4E21065676; Fri, 15 May 2009 13:20:38 +0000 (UTC) (envelope-from flo@kasimir.com) Received: from mail.solomo.de (mail.solomo.de [85.214.49.72]) by mx1.freebsd.org (Postfix) with ESMTP id A37618FC19; Fri, 15 May 2009 13:20:36 +0000 (UTC) (envelope-from flo@kasimir.com) Received: from localhost (localhost [127.0.0.1]) by mail.solomo.de (Postfix) with ESMTP id 6B96E3F4EB; Fri, 15 May 2009 15:20:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at vistream.de Received: from mail.solomo.de ([127.0.0.1]) by localhost (mail.solomo.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cjbgDBYk2+9T; Fri, 15 May 2009 15:20:33 +0200 (CEST) Received: from nibbler.vistream.local (relay3.vistream.de [87.139.10.28]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.solomo.de (Postfix) with ESMTPSA id F3B003F4B0; Fri, 15 May 2009 15:20:32 +0200 (CEST) Message-ID: <4A0D6C20.3050908@kasimir.com> Date: Fri, 15 May 2009 15:20:32 +0200 From: Florian Smeets User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b5pre) Gecko/20090515 Shredder/3.0b3pre MIME-Version: 1.0 To: Kostik Belousov References: <200905141054.n4EAsvp1088977@svn.freebsd.org> <20090515070239.GQ58540@hoeg.nl> <20090515080613.GA27593@x2.osted.lan> <20090515094852.GC1927@deviant.kiev.zoral.com.ua> <20090515103853.GE1927@deviant.kiev.zoral.com.ua> In-Reply-To: <20090515103853.GE1927@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, Peter Holm , svn-src-all@freebsd.org, src-committers@freebsd.org, Ed Schouten Subject: Re: svn commit: r192094 - head/sys/kern 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: Fri, 15 May 2009 13:20:38 -0000 On 15.05.09 12:38, Kostik Belousov wrote: > 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 ? > > Err, the patch. > [snip patch] The patch fixes my problems. Thanks, Florian