Return value for "impossible" situations

Return value for "impossible" situations

[Ian Pilcher]

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

Re: Return value for "impossible" situations

[Bernd Petrovitsch]

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

Re: Return value for "impossible" situations

[Ian Pilcher]

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

Re: Return value for "impossible" situations

[Valdis Klētnieks]

[-- 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

Re: Return value for "impossible" situations

[Ian Pilcher]

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

Re: Return value for "impossible" situations

[Bernd Petrovitsch]

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

Re: Return value for "impossible" situations

[Bernd Petrovitsch]

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