From owner-freebsd-stable@FreeBSD.ORG Sun Jul 26 14:28:10 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FDB5106564A for ; Sun, 26 Jul 2009 14:28:10 +0000 (UTC) (envelope-from jamie@FreeBSD.org) Received: from gritton.org (gritton.org [161.58.222.4]) by mx1.freebsd.org (Postfix) with ESMTP id BE4948FC17 for ; Sun, 26 Jul 2009 14:28:09 +0000 (UTC) (envelope-from jamie@FreeBSD.org) Received: from glorfindel.gritton.org (c-76-27-80-223.hsd1.ut.comcast.net [76.27.80.223]) (authenticated bits=0) by gritton.org (8.13.6.20060614/8.13.6) with ESMTP id n6QES7SN005343; Sun, 26 Jul 2009 08:28:08 -0600 (MDT) Message-ID: <4A6C67F5.8080408@FreeBSD.org> Date: Sun, 26 Jul 2009 08:28:05 -0600 From: Jamie Gritton User-Agent: Thunderbird 2.0.0.19 (X11/20090220) MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <4A6B0BD3.6040206@protected-networks.net> <4A6B9A60.90302@FreeBSD.org> <4A6BAC1A.5080303@protected-networks.net> <20090726120608.GE55190@deviant.kiev.zoral.com.ua> <20090726122230.E245@maildrop.int.zabbadoz.net> In-Reply-To: <20090726122230.E245@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , freebsd-stable Subject: Re: regression with jexec? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2009 14:28:10 -0000 Bjoern A. Zeeb wrote: > On Sun, 26 Jul 2009, Kostik Belousov wrote: > >> On Sat, Jul 25, 2009 at 09:06:34PM -0400, Michael Butler wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Jamie Gritton wrote: >>>> Michael Butler wrote: >>>>> imb@aaron:/home/imb> sudo jexec 5 tcsh >>>>> jexec: Unable to parse jail ID.: No such file or directory >>> >>>> >>>> The symptom in jexec can be fixed by this little patch: >>>> >>>> Index: usr.sbin/jexec/jexec.c >>>> =================================================================== >>>> --- usr.sbin/jexec/jexec.c (revision 195879) >>>> +++ usr.sbin/jexec/jexec.c (working copy) >>>> @@ -248,6 +248,7 @@ >>>> if (argc < 2) >>>> usage(); >>>> if (strlen(argv[0]) > 0) { >>>> + errno = 0; >>>> jid = (int)strtol(argv[0], NULL, 10); >>>> if (errno) >>>> err(1, "Unable to parse jail ID."); >>> >>> Thanks - this certainly cures the effect. >>> >>>> But the broader problem is malloc. It's leaving errno set to >>>> ENOENT when /etc/malloc.conf doesn't exist. This seems like >>>> wrong behavior to me. >>> >>> Seems like a POLA violation to me, >> >> No, this is how errno generally work, it is not changed if no error >> happens. > > I haven't really understood which part, when and why would set the errno in > first place so that it would still be there? Is it something in jexec > that gets the errno in first place or is it something internal to > malloc that sets it returns successfully and doesn't clear it? The POLA violation is in malloc - it sets errno even when there was no error. The allocation succeeded and a pointer was returned, yet errno was set to ENOENT (not even an error malloc should be able to return). The fact that malloc looks for an optional config file and doesn't find one shouldn't be relayed back to the caller in errno. If /etc/malloc.conf doesn't exist, it should either clear errno after that, or perhaps restore its previous value. There's also a getenv("MALLOC_OPTIONS") that can similarly set errno. Perhaps this has all been gone over before and I missed it (this is from code that's been stable since 2006), so I wouldn't want to just rush in and fix malloc. Maybe this general principle has already been discussed and my viewpoint lost. But if not, it's my opinion that malloc is acting badly and needs a change. In the meantime, I have no problem with errno not being cleared in strtol, and the patch to jexec is correct (though strictly speaking it shouldn't be necessary since we "know" errno has not yet been set). - Jamie