Re: [glibc PATCH] fcntl: put F_OFD_* constants under #ifdef __USE_FILE_OFFSET64

[Mike Frysinger <vapier at gentoo dot org>]

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:
> > > 
> > > 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.
> 
> 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.

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

Attachment: signature.asc
Description: Digital signature