Return value for "impossible" situations
In user space, I use assertions to check (and document) the assumptions built in to my code - this value won't ever be negative, this int will only ever by one of these 3 values, etc. For kernel code, I can use pr_err, dump_stack, WARN_ON, etc. to report the issue in the log, but I often also need to return some sort of error code (negative errno value). Is there any sort of convention around what to return in the case of an error in the logic of the code itself, something that will make it as obvious as possible that the problem is a bug. TIA! -- ======================================================================== In Soviet Russia, Google searches you! ========================================================================
Hi all! On 25/07/2021 20:07, Ian Pilcher wrote: [...]
For kernel code, I can use pr_err, dump_stack, WARN_ON, etc. to report the issue in the log, but I often also need to return some sort of error code (negative errno value).
This value goes up to userspace (otherwise it makes no real sense to use errno-values).
Is there any sort of convention around what to return in the case of an error in the logic of the code itself, something that will make it as obvious as possible that the problem is a bug.
That depends on the situation/sys-call/.... You habe to choose the value (the list and short explanation is in `man errno`) which leads the userspace application and it's user in the best direction. And no, you can't invent new values. MfG, Bernd -- Bernd Petrovitsch Email : bernd@petrovitsch.priv.at There is NO CLOUD, just other people's computers. - FSFE LUGA : http://www.luga.at
On 7/25/21 1:59 PM, Bernd Petrovitsch wrote:
This value goes up to userspace (otherwise it makes no real sense to use errno-values).
Yes. I know that.
That depends on the situation/sys-call/.... You habe to choose the value (the list and short explanation is in `man errno`) which leads the userspace application and it's user in the best direction.
Yes. I've already reviewed the manpage and the kernel headers, and I don't see anything that jumps out as appropriate for an unexpected "logic" error. Thus my question about a convention for this sort of situation.
And no, you can't invent new values.
I know. -- ======================================================================== In Soviet Russia, Google searches you! ========================================================================
On Sun, 25 Jul 2021 13:07:21 -0500, Ian Pilcher said:
Is there any sort of convention around what to return in the case of an error in the logic of the code itself, something that will make it as obvious as possible that the problem is a bug.
In general, there's no good way to signal such issues back to userspace, because there's no reserved '-EHIT_A_BUG' value. This has been true for decades, ever since Unix was still on the 18-bit PDP-7 in 1969. And it's basically useless to return such a value to userspace, because there's nothing useful that userspace can *do* in such a case. Note that pretty much all the defined error codes refer back to things that userspace could at least potentially do something useful - it may retry the operation after a delay, or tell the user that an optional facility isn't available in the currently running kernel, or try an alternate method of doing an operation (for example, trying again with IPv4 if an IPv6 connection fails, or use a different method of file locking). But if a userspace process hits an actual kernel bug, what is it supposed to do to recover? Do you add "check for -EHIT_A_BUG' to every single place you do a syscall? After all, 98% of userspace code is, *at best*, going to simply do an 'if (!erro)' test. And userspace code only does a more detailed check of *which* errno it got handed if it can do something different/useful for a specific code (such as code that goes into a retry loop if it gets -EEXIST when trying to create a lock file that shouldn't exist, and should be removed by another process when it's done). In particular, userspace has no ability to log any useful debugging information. There's the additional issue that the actual problem may not even be in that syscall's code - it could be some previous syscall from the current process that mis-set something in a structure, or some other kernel thread doing a write-after-free and corrupting memory, or code that assumed that it wouldn't be rescheduled to another CPU, or a myriad of other ways to fail. The *proper* thing to do is, instead of deciding to return -EHIT_A_BUG, do a WARN(), or BUG(), so that the dmesg has something that's at least potentially useful. Then use that information to fix the issue.
On 7/25/21 6:15 PM, Valdis Klētnieks wrote:
The *proper* thing to do is, instead of deciding to return -EHIT_A_BUG, do a WARN(), or BUG(), so that the dmesg has something that's at least potentially useful. Then use that information to fix the issue.
The question is, after the WARN_ON, what code does one return to user- space? What is the "kernel bug; go look at dmesg" return value? (Obviously, there isn't an obvious one for this situation. Thus my original question about whether there was any convention. Sadly, it seems that there really isn't one, which means that I'm basically forced to return a garbage error code that is likely to confuse a system administrator or cause them to waste time chasing the wrong issue.) -- ======================================================================== In Soviet Russia, Google searches you! ========================================================================
On 26/07/2021 06:18, Ian Pilcher wrote:
On 7/25/21 6:15 PM, Valdis Klētnieks wrote:
The *proper* thing to do is, instead of deciding to return -EHIT_A_BUG, do a WARN(), or BUG(), so that the dmesg has something that's at least potentially useful. Then use that information to fix the issue.
The question is, after the WARN_ON, what code does one return to user- space? What is the "kernel bug; go look at dmesg" return value?
You handle the bug gracefully in the kernel and be done. Or return some "good" errno value. There is no "go look into dmesg output" error or even the need for it.
(Obviously, there isn't an obvious one for this situation. Thus my original question about whether there was any convention. Sadly, it
There is no convention as these errors do not exist for userspace applications - the typical person in front or the application can't do anything about it.
seems that there really isn't one, which means that I'm basically forced to return a garbage error code that is likely to confuse a system administrator or cause them to waste time chasing the wrong issue.)
The error in userspace is usually seen by mere users and not some admin/root/kernel hacker so it makes no sense to bug them with it - let alone look into dmesg output and try to learn something from it. MfG, Bernd -- Bernd Petrovitsch Email : bernd@petrovitsch.priv.at There is NO CLOUD, just other people's computers. - FSFE LUGA : http://www.luga.at
On 26/07/2021 06:18, Ian Pilcher wrote:
On 7/25/21 6:15 PM, Valdis Klētnieks wrote:
The *proper* thing to do is, instead of deciding to return -EHIT_A_BUG, do a WARN(), or BUG(), so that the dmesg has something that's at least potentially useful. Then use that information to fix the issue.
The question is, after the WARN_ON, what code does one return to user- space? What is the "kernel bug; go look at dmesg" return value?
You handle the bug gracefully in the kernel and be done. Or return some "good" errno value. There is no "go look into dmesg output" error or even the need for it.
(Obviously, there isn't an obvious one for this situation. Thus my original question about whether there was any convention. Sadly, it
There is no convention as these errors do not exist for userspace applications - the typical person in front or the application can't do anything about it.
seems that there really isn't one, which means that I'm basically forced to return a garbage error code that is likely to confuse a system administrator or cause them to waste time chasing the wrong issue.)
The error in userspace is usually seen by mere users and not some admin/root/kernel hacker so it makes no sense to bug them with it - let alone look into dmesg output and try to learn something from it. MfG, Bernd -- Bernd Petrovitsch Email : bernd@petrovitsch.priv.at There is NO CLOUD, just other people's computers. - FSFE LUGA : http://www.luga.at
participants (3)
-
Bernd Petrovitsch -
Ian Pilcher -
Valdis Klētnieks