Return value for "impossible" situations

[Valdis Kl=?utf-8?Q?=c4=93?=tnieks]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 494 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20210725/fe0b0197/attachment.sig>