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