4 ms·
One of the issues that came to mind is how limited and overloaded the Linux error codes are, and EPERM might be one of the worst offenders. While obviously not
by zokier 7y ago
One of the issues that came to mind is how limited and overloaded the Linux error codes are, and EPERM might be one of the worst offenders. While obviously not expecting Linux to change that due compatibility concerns, it'd be wonderful if we'd have unique identifier for any code path (or nearly so) that causes error to be returned. Of course it'd be useful to have some grouping, so that applications that do not care do not need to know every possible error code, but for investigations it'd be useful to know exactly why something failed. For EPERM especially (but also others) there might some security concerns about leaking more information about why the request was denied, so in some cases some discretion is needed. But I'd be surprised if that is frequent true concern.
I do wonder how much stuff would break if you patched Linux to return error numbers with high bits set to autogenerated values. Obviously libc (and go if used) would need patching, but how many places call syscalls directly and are checking error codes carefully. Probably surprisingly long tail, but still could be fun experiment.
- scintill76 7y agoCool idea. I would put the extended error information in a separate variable, like errno.
- zokier 7y agoI happen to hate errno with passion, so that option is out :) Besides especially on 64 bit systems I don't think we are going to run out of negative numbers any time soon. Of course there are the few outliers that need the whole space (mmap), but those should be fairly rare?
- quotemstr 7y agoIf error codes were instead some kind of exception packaged with ancillary data, you could easily stick a kernel stack in the event payload and get the localization you're discussing that way. The ability to add context is what makes error codes lose so badly to exceptions.
- cyphar 7y agoGenerating a kernel stacktrace for every syscall error return seems like it would be needlessly wasteful on the return path (not to mention that it would change between kernel releases, and wouldn't be useful to most developers). A richer error system could be as simple as giving some more information about why a syscall returned -EINVAL (because checking all possible flag bits to see which one is not supported is really not a fun exercise).
- cyphar 7y ago> One of the issues that came to mind is how limited and overloaded the Linux error codes are, and EPERM might be one of the worst offenders. Funnily enough, EPERM is awful for another reason -- the vast majority of EPERM returns for kernel APIs should really be EACCES. The problem is that EPERM reads as though it means "Permission denied" when in reality it means "Operation not permitted".