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

["Michael Kerrisk (man-pages)" <mtk dot manpages at gmail dot com>]

On 08/18/2016 07:15 AM, 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.
>> -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.

Requiring _FILE_OFFSET_BITS=64 to use OFD locks on 32 bits seems rather
ugly. So, in the ideal world, the solution in the preceding paragraph
seems preferable. It's more work, but don't we have some precedents here
that can be used as patterns? However, I'm not sure I feel very strongly
about it all, since as you say the use case may not even exist.

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

Well, no one else spotted it at the time either :-).

Cheers,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/