From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84027 invoked by alias); 30 Mar 2017 19:22:36 -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 84011 invoked by uid 89); 30 Mar 2017 19:22:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=rage, H*r:TLS1.2, basically, H*r:4.88 X-HELO: albireo.enyo.de From: Florian Weimer To: Linus Torvalds Cc: Christoph Hellwig , Alexander Viro , Linux API , linux-fsdevel , Linux Kernel Mailing List , libc-alpha Subject: Re: RFC: reject unknown open flags References: <20170330163327.23920-1-hch@lst.de> Date: Thu, 30 Mar 2017 19:22:00 -0000 In-Reply-To: (Linus Torvalds's message of "Thu, 30 Mar 2017 10:08:10 -0700") Message-ID: <87tw6atvre.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2017-03/txt/msg00698.txt.bz2 * Linus Torvalds: > But probing for flags is why we *could* add things like O_NOATIME etc > - exactly because it "just worked" with old kernels, and people could > just use the new flags knowing that it was a no-op on old kernels. Right, it mostly works for the flags we added. > The whole concept of "probing for supported features" is very suspect. > It's a bad bad idea. Don't do it. It's vastly preferable to hard-coding kernel version dependencies in source or object code. Particularly if you want to move applications between different kernel versions (which seems to be all the rage right now). The problem with probing for flags is that it's kind of hard to see which flag causes the failure. Maybe application code could retroactively apply it with fcntl. This is what we did when there was no support for O_CLOEXEC, but this was easy because there has been FD_CLOEXEC in fcntl since basically forever. > What kind of new flag did you even have in mind that would have such > broken semantics that it would completely change the other flags? I think we had to go through some gymnastics to get the desired behavior for O_TMPFILE and O_PATH. There's another consideration. open/openat flags are very special in one regard: glibc tries to implement the system call wrapper in standard C, with proper processing. This means that the wrapper has to determine whether there is a mode argument or not, and avoid the va_arg call if it is missing. Consequently, we parse the flag argument to see if it implies the need for a mode. This broke with O_TMPFILE. We don't do that for fcntl, which has exactly the same issue because F_GETFD has an empty variable argument list. We just call va_arg beyond the end of the argument list in the F_GETFD case. We don't check the command argument and use it to adjust the number of va_arg calls. We should do the same for open/openat because it obviously works for all architectures we care about in the fcntl case. (This is independent if there is going to be another system call with different semantics for handling unknown flags.)