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

[Jeff Layton <jlayton@redhat.com>]

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>