This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [glibc PATCH] fcntl: put F_OFD_* constants under #ifdef __USE_FILE_OFFSET64
- From: Jeff Layton <jlayton at redhat dot com>
- To: Mike Frysinger <vapier at gentoo dot org>
- Cc: libc-alpha at sourceware dot org, linux-fsdevel at vger dot kernel dot org, Michael Kerrisk <mtk dot manpages at gmail dot com>, Carlos O'Donell <carlos at redhat dot com>, Yuriy Kolerov <Yuriy dot Kolerov at synopsys dot com>
- Date: Wed, 17 Aug 2016 15:15:04 -0400
- Subject: Re: [glibc PATCH] fcntl: put F_OFD_* constants under #ifdef __USE_FILE_OFFSET64
- Authentication-results: sourceware.org; auth=none
- References: <1471445251-2450-1-git-send-email-jlayton@redhat.com> <20160817184333.GC21655@vapier.lan>
On Wed, 2016-08-17 at 11:43 -0700, Mike Frysinger wrote:
> On 17 Aug 2016 10:47, Jeff Layton wrote:
> >
> > The Linux kernel expects a flock64 structure whenever you use OFD locks
> > with fcntl64. Unfortunately, you can currently build a 32-bit program
> > that passes in a struct flock when it calls fcntl64.
> >
> > 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.
>
> 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. namely, we haven't documented F_GETLK64 or struct flock64,
> with the expectation that the user just calls fcntl() with a struct
> flock. in fact, the man page even goes so far as to discourage people
> from using the *64 variants.
>
> it should be possible using our existing LFS framework to make the OFD
> cmds available even to 32-bit apps (where sizeof(off_t) == 32). but
> 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 ? we'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.
> -mike
There should be no need to use struct flock64 explicitly, and there is
already a proposed patch to fix the manpage accordingly.
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=64).
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.
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.
--
Jeff Layton <jlayton@redhat.com>