On Thu, 2016-08-18 at 07:59 +1200, Michael Kerrisk (man-pages) wrote: > 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 > > Sounds nice, but that is a bit more difficult. Let's explore it though... The big question is: how do we do that without breaking applications that are currently working? The way it works now is that when you define _FILE_OFFSET_BITS=64 and call fcntl(fd, F_SETLK, fl) glibc swaps in a struct flock64 for your struct flock, and F_SETLK64 for the F_SETLK. So, suppose we do the same here -- define a set of F_OFD_SETLK64 constants, and then pass those in in the same way using glibc, and teach the kernel to handle things in the same way. The problem there is that we'd be silently changing the behavior for applications that are working. Applications that are using F_OFD_SETLK and passing in a flock64 structure would be broken. We need to preserve how F_OFD_SETLK behaves today for applications that do set _FILE_OFFSET_BITS=64. OTOH, we could define a set of new F_OFD_*32 constants and use those to indicate to the kernel that this is a legacy struct flock. That would actually work, though you'd need to have a new kernel and build against a new glibc. If you built with a new glibc and run against an old kernel, then you'd (presumably) fail with -EINVAL at runtime in the problematic case. Maybe that is the best option though...thoughts? -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
