From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24855 invoked by alias); 17 Aug 2016 19:15:11 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 24845 invoked by uid 89); 17 Aug 2016 19:15:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,UNSUBSCRIBE_BODY autolearn=no version=3.3.2 spammy=HTo:D*gentoo.org, discourage, virtue, now X-HELO: mail-qk0-f169.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=MJvdc8byiIqPUP8km7okQRqEA7da31Nzg3Ebhm4l3/Q=; b=LLyPb9peOXHIJ85D/aUI4MMJo4hNvfG9JwMKbF91CH5/f6oifv4J9VG+cN+CGOxoQV 8pHmiBMhtITx+tfp2aXa8mmmjQQHb1omjRGvoqeczqqWDDnCjquWYFyQbrjJnLubJSJ9 Wtj8ieRWfyRyrSm1aIyF0jMyEQSU3HxRlEcSpOExzLqbugHi7WN/t1fKmXBtZeh0ydBJ RtYzeRFPRQXsUpPO7UeCTBpVJ7VzxjVA4jLoedvD0dj7PFTL3qf42yqq1sgRuSGaD/ly ZrJVBTkk6i5rHu62lX8bKCq6pFTj0pzxrulDkf1wVK3ebTzhx1EX737C7IHpfnYU1NI+ HogA== X-Gm-Message-State: AEkoouubWkasq6RZTQ3n4AswbI5VkEW61jXHVYfBROlOSeeqpQAVzR6D+Ozpx8ukGsS+BiPO X-Received: by 10.55.221.131 with SMTP id u3mr45272188qku.243.1471461306825; Wed, 17 Aug 2016 12:15:06 -0700 (PDT) Message-ID: <1471461304.3196.101.camel@redhat.com> Subject: Re: [glibc PATCH] fcntl: put F_OFD_* constants under #ifdef __USE_FILE_OFFSET64 From: Jeff Layton To: Mike Frysinger Cc: libc-alpha@sourceware.org, linux-fsdevel@vger.kernel.org, Michael Kerrisk , Carlos O'Donell , Yuriy Kolerov Date: Wed, 17 Aug 2016 19:15:00 -0000 In-Reply-To: <20160817184333.GC21655@vapier.lan> References: <1471445251-2450-1-git-send-email-jlayton@redhat.com> <20160817184333.GC21655@vapier.lan> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-SW-Source: 2016-08/txt/msg00536.txt.bz2 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