Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934777AbdC3T35 (ORCPT ); Thu, 30 Mar 2017 15:29:57 -0400 Received: from albireo.enyo.de ([5.158.152.32]:37991 "EHLO albireo.enyo.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934067AbdC3T3z (ORCPT ); Thu, 30 Mar 2017 15:29:55 -0400 X-Greylist: delayed 441 seconds by postgrey-1.27 at vger.kernel.org; Thu, 30 Mar 2017 15:29:54 EDT 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 21:22:29 +0200 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 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2106 Lines: 44 * 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.)