* Return value for "impossible" situations
@ 2021-07-25 18:07 Ian Pilcher
2021-07-25 18:59 ` Bernd Petrovitsch
2021-07-25 23:15 ` Valdis Klētnieks
0 siblings, 2 replies; 7+ messages in thread
From: Ian Pilcher @ 2021-07-25 18:07 UTC (permalink / raw)
To: kernelnewbies
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!
========================================================================
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: Return value for "impossible" situations 2021-07-25 18:07 Return value for "impossible" situations Ian Pilcher @ 2021-07-25 18:59 ` Bernd Petrovitsch 2021-07-25 19:13 ` Ian Pilcher 2021-07-25 23:15 ` Valdis Klētnieks 1 sibling, 1 reply; 7+ messages in thread From: Bernd Petrovitsch @ 2021-07-25 18:59 UTC (permalink / raw) To: Ian Pilcher, kernelnewbies 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 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Return value for "impossible" situations 2021-07-25 18:59 ` Bernd Petrovitsch @ 2021-07-25 19:13 ` Ian Pilcher 0 siblings, 0 replies; 7+ messages in thread From: Ian Pilcher @ 2021-07-25 19:13 UTC (permalink / raw) To: kernelnewbies 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! ======================================================================== _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Return value for "impossible" situations 2021-07-25 18:07 Return value for "impossible" situations Ian Pilcher 2021-07-25 18:59 ` Bernd Petrovitsch @ 2021-07-25 23:15 ` Valdis Klētnieks 2021-07-26 4:18 ` Ian Pilcher 1 sibling, 1 reply; 7+ messages in thread From: Valdis Klētnieks @ 2021-07-25 23:15 UTC (permalink / raw) To: Ian Pilcher; +Cc: kernelnewbies [-- Attachment #1.1: Type: text/plain, Size: 2265 bytes --] 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. [-- Attachment #1.2: Type: application/pgp-signature, Size: 494 bytes --] [-- Attachment #2: Type: text/plain, Size: 170 bytes --] _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Return value for "impossible" situations 2021-07-25 23:15 ` Valdis Klētnieks @ 2021-07-26 4:18 ` Ian Pilcher 2021-07-26 10:42 ` Bernd Petrovitsch 2021-07-26 11:08 ` Bernd Petrovitsch 0 siblings, 2 replies; 7+ messages in thread From: Ian Pilcher @ 2021-07-26 4:18 UTC (permalink / raw) To: Valdis Klētnieks; +Cc: kernelnewbies 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! ======================================================================== _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Return value for "impossible" situations 2021-07-26 4:18 ` Ian Pilcher @ 2021-07-26 10:42 ` Bernd Petrovitsch 2021-07-26 11:08 ` Bernd Petrovitsch 1 sibling, 0 replies; 7+ messages in thread From: Bernd Petrovitsch @ 2021-07-26 10:42 UTC (permalink / raw) To: Ian Pilcher; +Cc: Valdis Klētnieks, kernelnewbies 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 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Return value for "impossible" situations 2021-07-26 4:18 ` Ian Pilcher 2021-07-26 10:42 ` Bernd Petrovitsch @ 2021-07-26 11:08 ` Bernd Petrovitsch 1 sibling, 0 replies; 7+ messages in thread From: Bernd Petrovitsch @ 2021-07-26 11:08 UTC (permalink / raw) To: Ian Pilcher; +Cc: Valdis Klētnieks, kernelnewbies 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 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-07-26 11:09 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-07-25 18:07 Return value for "impossible" situations Ian Pilcher 2021-07-25 18:59 ` Bernd Petrovitsch 2021-07-25 19:13 ` Ian Pilcher 2021-07-25 23:15 ` Valdis Klētnieks 2021-07-26 4:18 ` Ian Pilcher 2021-07-26 10:42 ` Bernd Petrovitsch 2021-07-26 11:08 ` Bernd Petrovitsch
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).