From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org ([140.211.166.183]:44932 "EHLO smtp.gentoo.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753495AbcHQUDG (ORCPT ); Wed, 17 Aug 2016 16:03:06 -0400 Date: Wed, 17 Aug 2016 13:03:05 -0700 From: Mike Frysinger To: Jeff Layton Cc: libc-alpha@sourceware.org, linux-fsdevel@vger.kernel.org, Michael Kerrisk , Carlos O'Donell , Yuriy Kolerov Subject: Re: [glibc PATCH] fcntl: put F_OFD_* constants under #ifdef __USE_FILE_OFFSET64 Message-ID: <20160817200305.GE21655@vapier.lan> References: <1471445251-2450-1-git-send-email-jlayton@redhat.com> <20160817184333.GC21655@vapier.lan> <1471461304.3196.101.camel@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Lb0e7rgc7IsuDeGj" Content-Disposition: inline In-Reply-To: <1471461304.3196.101.camel@redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: --Lb0e7rgc7IsuDeGj Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 17 Aug 2016 15:15, Jeff Layton wrote: > On Wed, 2016-08-17 at 11:43 -0700, Mike Frysinger wrote: > > On 17 Aug 2016 10:47, Jeff Layton wrote: > > >=20 > > > The Linux kernel expects a flock64 structure whenever you use OFD loc= ks > > > with fcntl64. Unfortunately, you can currently build a 32-bit program > > > that passes in a struct flock when it calls fcntl64. > > >=20 > > > Only define the F_OFD_* constants when __USE_FILE_OFFSET64 is also > > > defined, so that the build fails in this situation rather than > > > producing a broken binary. > >=20 > > this seems to be going against the glibc API/guarantees we've provided > > before (or at least tried to promise), and what the fcntl(2) man page > > says now.=C2=A0=C2=A0namely, we haven't documented F_GETLK64 or struct = flock64, > > with the expectation that the user just calls fcntl() with a struct > > flock.=C2=A0=C2=A0in fact, the man page even goes so far as to discoura= ge people > > from using the *64 variants. > >=20 > > it should be possible using our existing LFS framework to make the OFD > > cmds available even to 32-bit apps (where sizeof(off_t) =3D=3D 32).=C2= =A0=C2=A0but > > maybe the usage of F_GETLK64/struct flock64/etc... in the real world > > has made it hard to put that genie back in the bottle ?=C2=A0=C2=A0we'd= have to > > version the current fcntl symbol, create a new fcntl symbol that does > > 32->64 munging, and add a new fcntl64 symbol that we'd transparently > > rewrite to when LFS is turned on. >=20 > There should be no need to use struct flock64 explicitly, and there is > already a proposed patch to fix the manpage accordingly. >=20 > What we _do_ want to ensure is that large file offsets are in use if > the application wants to use OFD locks (either by virtue of being on a > 64 bit arch, or by defining _FILE_OFFSET_BITS=3D64). >=20 > In principle, we could try to fix it up so that the kernel can handle > OFD locks with legacy struct flock. That would mean adding > F_OFD_SETLK64 and friends in both the kernel and glibc, and we'd have > to ensure that legacy kernel+new glibc is handled sanely (and vice- > versa). That's a lot of effort (and more risk for breakage) to handle a > use case that I'm not sure even exists. This approach is much simpler, > and we'll just be breaking at build time a case that was already broken > at runtime. >=20 > In hindsight, I wish I had just introduced F_OFD_SETLK64 and friends to > make them work with legacy struct flock when I did these patches (mea > culpa!), but I don't really see the value in doing that at this point. this the crux of my point though ... if we want fcntl to be transparent, then that includes making OFD locks "just work" in userspace. the trouble is that glibc only does fcntl->fcntl64, it doesn't do any other cmd or arg translation. that means users are forced to pick the right cmd (FOO or FOO64) that matches the LFS build mode. i.e. they can't use FOO w/LFS turned on, and they can't use FOO64 w/LFS turned off. otherwise there's a mismatch in the struct flock. imo, we should either adapt our documentation (manual & man page) to match reality, or we should bite the bullet and commit to doing the heavy lifting with fcntl. -mike --Lb0e7rgc7IsuDeGj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXtML4AAoJEEFjO5/oN/WB8agP/iyauEMlbEJVO00HijMyMA6B 4NSG6a8HvoEX7v/MPchOS5v7LKLzYTV3CIFbj844NjroLr0m+c5CZATVkixC+0f6 Y1WXAS7/Ds74LQ3WgIA/QQQsGJjYfklReSBFEqUCTimy1SdnYfL9BrpkJkgasqpo YteAlEy/ZoyqshgUUH8nhJa6tt+kxM9YnZvHMn/35jbkm1prkRZa94XezmWcv7G5 oucQUrQwN6aLLp1wSgYrPcaph3GLfq5ckWXP1FAg3kpIXbI41nnmOZAlA7aBuSxV 6N+6uk8sEIGiEVBW3hsE7IRofazzwCw2dxrvuxLrNXjvib0huc0UHpa8FnRX5S86 W1sM6TviC5EXeAX73FvIsIq46dp/5kmQKFF+hXPVnTRJD1Nnnwf/EzB60hUP2XE1 mmGNdHDqJY2t2VqrslGRESnQCu4vyjGmLxUqY57TaoZFmvXS7kF2lxG3OItMczRN ro4VqlpSW9PQp/SXpSLGe/h0Wghk8tGYbvCLf4uDebqI1zNEg7jJk16Q+NNtVtyL k0NFA3EDDR+wCEL/ueDADU+uXNt+IOYPW+HTo9fo6w95gEdH/FcXBkmqumfXOMb1 JWzMuw/qjGxa/vPzyGLG6mRL7vfSl3c/+so8S9z549JZ5YwgUOYHTfTVYeHcNQu4 v6TKRGYy5jzYdxtpWb97 =89yF -----END PGP SIGNATURE----- --Lb0e7rgc7IsuDeGj--