On Thu, 30 May 2024 at 07:17, Lennart Poettering <mzxreary@xxxxxxxxxxxx> wrote:
>
> Linus, what's the policy if some subsystem by mistake is leaking
> internal kernel error codes (such as ENOTSUP) to userspace?
Try to fix it, and stop leaking silly garbage in the hope that nobody cared.
And in most cases, people don't actually care, because they don't know
to even test for non-standard errno values.
In fact it is _very_ rare that some actual program - outside of some
test suite - cares about the errno values outside of the really
special ones
So things like "EAGAIN" and "EINTR" have real semantic meaning and
people test for them and do something explicitly different. Sometimes
a few others too, but those are the two obvious ones.
The rest are *almost* always entirely interchangeable and only result
in different error messages, not different _behavior_.
But then occasionally if it turns out that user space then breaks
because some random case actually tested for a _particular_ error, and
we have to put the silly garbage back.
Congrats, you have now invented a new ABI that you will support until
the end of time (or until user space stops caring, whichever comes
first).
That said, while I think ENOTSUPP should not be encouraged because
it's so non-standard, I think the ship on ENOTSUPP has long since
sailed.
Yes, yes, the comment may say "These should never be seen by user
programs." but that comment is historically about ERESTARTSYS and
friends, that are supposed to be turned into EINTR (and a restart etc
depending on process flags and signal details).
And nobody reads comments anyway, and perhaps more importantly, they
by definition have no semantic meaning, so...
We have a ton of code that returns ENOTSUPP - not in the least limited
to bpf - and while we have a checkpatch rule for it, it's more of a
"don't add new ones". Even that one is likely not really relevant.
And yes, some of them may get translated, but the very first one I
randomly looked at was a proc_handler thing for some driver, and read
-> ...->read_iter() -> proc_sys_read() -> proc_sys_call_handler() ->
...->proc_handler() most definitely does not.
ENOTSUPP in particular is very understandable, because the "standard"
error names are garbage that nobody would ever use. EOPNOTSUPP? Never
heard of it.
The standard errno for that is EINVAL, and people actively avoid it
because it's _so_ common, so everybody goes "I want to make it clear
that this is somethign else" and then they pick some other random name
that sounds likely. And ENOTSUPP is right there and sounds very likely
indeed.
If we really cared, we should have made them have a very different
naming syntax, I'm afraid. Something explicitly inconvenient to make
people not want to use it. Like __INTERNAL_ONLY_ENOTSUPP.
Linus
