[Ksummit-discuss] [CORE TOPIC] More useful types in the linux kernel

[Hannes Reinecke]

On 07/26/2016 01:48 PM, David Woodhouse wrote:
> On Fri, 2016-07-22 at 15:57 +0200, Hannes Reinecke wrote:
>>
>>> I guess that almost all functions return only a few possible error codes?
>>
>> Precisely. If we had a way of specifying "the return value is an errno
>> with the possible values '0', '-EIO', and '-EINVAL'" that would be
>> _so_ cool.
>
> And perpetually out of date. Because functions call through to *other*
> functions which might return an errno outside the 'known' set.
>
What I want to catch with that are value range collisions; has the 'int' 
returned from that function the same meaning as the 'int' returned from 
the next function.
Random example: drivers/net/veth.c:veth_newlink()
'rtnl_nla_parse_ifla()' returns a value which is stored in the same 
variable as the return value from veth_validate(). And that value is 
then used as the return value for the entire function.
ATM we need to do code inspection to figure out if both indeed return an 
errno or not.

> Any why would you *want* to know the precise set of errnos that a
> function might return, if not to deliberately code your error handling
> non-defensively?
>
The ultimate goal is to provide a map with the known return codes for 
the various functions. Then we can invert that map and _inject_ errors
via systemtap and friend for those functions to test the error paths.
Using a fuzzer would work, too, but I think it's a bit too generic here
(scanning the entire range of 'int' _does_ take some time).
In general we want to trigger the 'exciting' cases (ie values where 
there _is_ an error path coded) to figure out if the error handling 
actually does behave as advertised.

> I can understand wanting to distinguish between errors and non-errors
> and ensure that the ranges cannot overlap. But IS_ERR_VALUE() typically
> reserves the whole range to -4095 (-MAX_ERRNO) for that. And I don't
> think we'd ever want to do anything different.
>
Even that would be fine; even restricting the range from the entire 
'int' to 4096 will make live easier.
But ATM we don't even have a way of expressing that.

> In particular I don't want anyone ever saying "oh, -123 is a valid non-
> error return but no other negative numbers are. But that's OK because
> it'll never *actually* return an error of -ENOMEDIUM so there's no
> ambiguity."
>
Na, of course not.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		               zSeries & Storage
hare at suse.com			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)