From owner-freebsd-arch@FreeBSD.ORG Tue Jul 8 15:36:33 2008 Return-Path: Delivered-To: arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4CA3106567E; Tue, 8 Jul 2008 15:36:33 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:610:652::211]) by mx1.freebsd.org (Postfix) with ESMTP id 64F338FC0C; Tue, 8 Jul 2008 15:36:33 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id BAAFE1CE27; Tue, 8 Jul 2008 17:36:32 +0200 (CEST) Date: Tue, 8 Jul 2008 17:36:32 +0200 From: Ed Schouten To: Robert Watson Message-ID: <20080708153632.GI14567@hoeg.nl> References: <9484951.340521215467447990.JavaMail.root@vms126.mailsrvcs.net> <20080708001929.E63144@fledge.watson.org> <20080708161802.N89342@fledge.watson.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wwX5Nmi7feudBrEr" Content-Disposition: inline In-Reply-To: <20080708161802.N89342@fledge.watson.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: arch@FreeBSD.ORG Subject: Re: Proposal: a revoke() system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2008 15:36:33 -0000 --wwX5Nmi7feudBrEr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Robert, * Robert Watson wrote: > BTW, on a similar note to the above: I've noticed there are several spots= =20 > of relative non-atomicity in the Linux emulation code, where rather than= =20 > just wrapping existing system calls with binary conversion of arguments= =20 > and return values, we do a semantic wrapping that is necessarily=20 > non-atomic with respect to the native code. For example, consider the=20 > Linuxulator open code in linux_common_open(): I also noticed similar constructs inside the stat() calls, to translate device major/minor numbers. As you can see, some stat() routines call translate_path_major_minor_at() after performing the regular stat() operation. The translate_path_major_minor_at() is implemented by calling kern_openat(). This has three disadvantages: - It is non-atomic. - It can only perform the translation on nodes it has O_RDONLY access to. This shouldn't be a big problem, but may cause inconsistencies when users look around in devfs. - The translation may not always work when the calling process is out of file descriptors. Yours, --=20 Ed Schouten WWW: http://80386.nl/ --wwX5Nmi7feudBrEr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkhziYAACgkQ52SDGA2eCwUufgCdFABNXxHgwgRGa466AlktkxDv 7AgAnjCTLlEcDeG+6WL7bruGhIwE7on7 =meaN -----END PGP SIGNATURE----- --wwX5Nmi7feudBrEr--