Making System Calls Reject Unknown Flags

Christoph Hellwig was unhappy with the fact that anyone could pass random garbage as input to system calls, without breaking anything. As a result, user code can't test system calls to see if they accept this or that input flag – they accept them all, even if they do nothing with them. He wanted to write a patch that would make system calls reject input flags that weren't actually supported.

Christoph acknowledged that this would be an application binary interface (ABI) change, which was nearly always a no-no for a few important reasons. For one thing, it made it impossible to "bisect" the kernel development tree in order to hunt down bugs that crossed the version that implemented the ABI-breaking change. More importantly, however, it would break existing user code running out in the world on everybody's system and require that code to be recompiled. This is actually a big no-no because in many cases, the people running the binaries don't have the source code anymore!

So, ABI changes are generally hit with hammers by various folks, including Linus Torvalds. In this case, Linus didn't bother addressing the ABI issue, but objected to Christoph's main point, saying:

"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.

The whole concept of 'probing for supported features' is very suspect. It's a bad, bad idea. Don't do it.

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? Because now I'm starting to think that the whole series has an even deeper bug: stupid new features that were badly thought out and not even described."

Christoph pointed to the atomic input/output issue as described in https://lwn.net/Articles/573092/. Linus was unimpressed, saying that in the typical case, any code that wanted atomic input/output would probably still want to perform input/output without the atomicity guarantee, in which case there were straightforward ways to handle it. He added, "My guess is that there is going to be very few O_ATOMIC users anyway, and they'll very carefully set it once and test it (or not even test it – just make it be a configuration flag and tell people 'don't ask for O_ATOMIC if your system doesn't support it')."

Meanwhile, Florian Weimer said that probing for flags was "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)."

But the conversation trailed off at that point. Regardless of whether there's a decent justification for probing, it's still an ABI change, which kills it at the starting gate.