Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934910AbdC3UGG (ORCPT ); Thu, 30 Mar 2017 16:06:06 -0400 Received: from mail-wr0-f171.google.com ([209.85.128.171]:33087 "EHLO mail-wr0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933493AbdC3UGD (ORCPT ); Thu, 30 Mar 2017 16:06:03 -0400 Subject: Re: RFC: reject unknown open flags To: Linus Torvalds , Christoph Hellwig References: <20170330163327.23920-1-hch@lst.de> <20170330172159.GA24139@lst.de> <20170330182620.GA25251@lst.de> Cc: Alexander Viro , Linux API , linux-fsdevel , Linux Kernel Mailing List , libc-alpha From: Boaz Harrosh Message-ID: <6cbf0110-eb29-9b18-8f92-7ddf1d6c5cc2@plexistor.com> Date: Thu, 30 Mar 2017 23:05:59 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1506 Lines: 40 On 03/30/2017 09:45 PM, Linus Torvalds wrote: > On Thu, Mar 30, 2017 at 11:26 AM, Christoph Hellwig wrote: >> >> That would be nice, but still won't work as we blindly copy f_flags >> into F_GETFL, not even masking our internal FMODE_ bits. > > Ok, *that* is just silly of us, and we could try to just fix, and even backport. > > There's no possible valid use I could see where that should break > (famous last words - user code does some damn odd things at times). > > Of course, that won't fix old kernels that are out there, but then > neither would your original patch... > > Side note: I think you *can* detect the O_ATOMIC support by using > F_SETFL, because F_SETFL only allows you to change flags that we > recognize. So somebody who really wants to *guarantee* that O_ATOMIC > is there and honored even with old kernels could presumable do > something like > > fd = open(..); // *no* O_ATOMIC > fcnt(fd, F_SETFL, O_ATOMIC); > if (fcnt(fd, F_GETFL, NULL) & O_ATOMIC) > // Yay! We actually got it > else > // I guess we need to fall back on old behavior > > although I agree that that is ridiculously inconvenient and not a > great thing, and it's worth trying to aim for some better model. > Perhaps in that case it is time for an F_GETFL2 an F_GET_REAL_FL that gives you the nice simple user code Linus wanted for new applications. and solves forward and backwords for applications and Kernels? Just my $0.017 Boaz > Linus >