From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 9 12:45:03 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BA52106564A; Wed, 9 Nov 2011 12:45:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 2E2938FC12; Wed, 9 Nov 2011 12:45:02 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pA9Cit6l024640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Nov 2011 14:44:55 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pA9Cit67068905; Wed, 9 Nov 2011 14:44:55 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pA9Citp0068904; Wed, 9 Nov 2011 14:44:55 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 9 Nov 2011 14:44:55 +0200 From: Kostik Belousov To: Mikolaj Golub Message-ID: <20111109124455.GW50300@deviant.kiev.zoral.com.ua> References: <20111031094948.GB50300@deviant.kiev.zoral.com.ua> <86vcr21agm.fsf@kopusha.home.net> <20111105135801.GT50300@deviant.kiev.zoral.com.ua> <86ehxmpogp.fsf@kopusha.home.net> <20111105154443.GB50300@deviant.kiev.zoral.com.ua> <86ehxmjsza.fsf@kopusha.home.net> <20111105194553.GK50300@deviant.kiev.zoral.com.ua> <8662iyjof9.fsf@kopusha.home.net> <20111106181041.GH50300@deviant.kiev.zoral.com.ua> <86r51iqoad.fsf@kopusha.home.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JIU8dMvCuAW53rIa" Content-Disposition: inline In-Reply-To: <86r51iqoad.fsf@kopusha.home.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org, Robert Watson Subject: Re: "ps -e" without procfs(5) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 12:45:03 -0000 --JIU8dMvCuAW53rIa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 08, 2011 at 11:47:54PM +0200, Mikolaj Golub wrote: >=20 > On Sun, 6 Nov 2011 20:10:41 +0200 Kostik Belousov wrote: >=20 > KB> On Sat, Nov 05, 2011 at 10:37:46PM +0200, Mikolaj Golub wrote: > >>=20 > >> http://people.freebsd.org/~trociny/env.sys.3.patch >=20 > KB> Oops, I missed this in the previous review. You cannot use fubyte in > KB> proc_read_mem(). fubyte reads a byte from the address space of the c= urrent > KB> process. The fix is easy, use proc_rwmem for 1 byte. >=20 > KB> I do not think that fall back to single byte read is warranted for > KB> proc_read_mem calls e.g. for ps_strings. Add a flag to indicate whet= her > KB> the proc_read_mem should fall back to byte read ? >=20 > KB> I would prefer using sizeof(uint64_t) and sizeof(uint32_t) instead o= f 8 > KB> and 4 constants in the align checks. >=20 > KB> Might be, add PROC_ASSERT_HELD() to get_ps_string() ? >=20 > KB> procfs patch looks good. >=20 > Thanks. The updated version: >=20 > http://people.freebsd.org/~trociny/env.sys.4.patch >=20 > Investigating cases when EFAULT was returned and if the fallback was > successful I noticed that most of the cases were when p->p_comm changed d= uring > the read, so the process was in exec in that time. In order to avoid this > error I added a check for P_INEXEC flag. And now you return success and nothing gets copied out for the process in P_INEXEC state. Either you should return an error like EAGAIN, or consider the P_INEXEC state as transitional and wait till process leaves it. Or, ignore the state as it was before, and return whatever error proc_rwmem generated (my preference). >=20 > After this I observed EFAULT (very rarely) only when reading arg or env > strings and fallback was successful for those cases. So I modified the pa= tch > to do fallback only when reading strings (as it was in one of my earlier > versions but with wrong fubyte), and returned your comment which explains= why > it may happen :-) >=20 > Also in the procfs patch I have added the check for process state. >=20 > The userland part has not been changed since my first report: >=20 > http://people.freebsd.org/~trociny/env.user.patch >=20 > --=20 > Mikolaj Golub --JIU8dMvCuAW53rIa Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk66dccACgkQC3+MBN1Mb4iarACgvhzunOIjpRYaGRExe96olR3j BQgAnRIhrLZcozVy/okSIulpv+zrmM4+ =w/U9 -----END PGP SIGNATURE----- --JIU8dMvCuAW53rIa--