From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f68.google.com ([209.85.220.68]:35040 "EHLO mail-pa0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752406AbcHQT7V (ORCPT ); Wed, 17 Aug 2016 15:59:21 -0400 Received: by mail-pa0-f68.google.com with SMTP id cf3so7934297pad.2 for ; Wed, 17 Aug 2016 12:59:21 -0700 (PDT) Subject: Re: [glibc PATCH] fcntl: put F_OFD_* constants under #ifdef __USE_FILE_OFFSET64 To: Jeff Layton , Mike Frysinger References: <1471445251-2450-1-git-send-email-jlayton@redhat.com> <20160817184333.GC21655@vapier.lan> <1471461304.3196.101.camel@redhat.com> Cc: mtk.manpages@gmail.com, libc-alpha@sourceware.org, linux-fsdevel@vger.kernel.org, Carlos O'Donell , Yuriy Kolerov From: "Michael Kerrisk (man-pages)" Message-ID: Date: Thu, 18 Aug 2016 07:59:13 +1200 MIME-Version: 1.0 In-Reply-To: <1471461304.3196.101.camel@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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/