On Tue, Feb 01, 2022 at 12:56:51PM -0700, Mathnerd314 wrote: > On Mon, Jan 31, 2022 at 5:30 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > So while it's worth adding EINTR to the man page, I don't think it's > > worth going through an exercise of trying to add every possible > > errno to every syscall. > > It's true that POSIX's error list is purely a guideline. But that > doesn't mean Linux can't specify the precise set of possible error > codes. There are currently 133 error codes defined, across an equally > large number of syscalls - coding defensively and handling every > combination is impossible. Not to mention that the meaning of the > error codes differs from syscall to syscall. But with precise > information there are likely only 5-10 codes per syscall, so handling > every error appropriately is feasible. So the information can be quite > useful. Ahahahaha. For one, every filesystem gets to return its own errors. So basically any syscall that takes an fd gets to return all the errors that any of our 50+ filesystems decides to use. Then there are the interposers. Things like seccomp, Linux Security Modules, and other such hooks which might return their own errors. On top of that there's error injection, which might allow eBPF to return any error that userspace has deemed appropriate from basically any function. Further, you generally don't execute syscalls. You call glibc, which might decide to return its own errors, not even bothering to call the kernel. But the real problem is that the kernel might decide to return new errors at any time. Just because you exhaustively handled every error that could have occurred in 5.15 doesn't mean that there might not be an error returned by 5.20. This isn't even an Herculean task. This is Sisyphean, and you'll probably feel like Prometheus by the end of it. I mean, you'd learn a lot by attempting it, but you'd be better off picking a task that would actually help people.
