[Ksummit-discuss] [CORE TOPIC] More useful types in the linux kernel
Alexey Dobriyan
adobriyan at gmail.com
Tue Jul 26 13:59:43 UTC 2016
On Tue, Jul 26, 2016 at 3:53 PM, Hannes Reinecke <hare at suse.com> wrote:
> 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.
This requires rewriting kernel in a programming language
with real type system. :^)
More information about the Ksummit-discuss
mailing list