Subject: Re: [PATCH][IPV6]: Make sure fib6_rule_lookup doesn't return NULL

From: Ville Nuorvala <[email-masked]>
Date: Wed, 09 Aug 2006 12:42:19 +0300

Thomas Graf wrote:
> * Ville Nuorvala <[email-masked]> 2006-08-09 11:36
>> Of the three original route lookup functions (ip6_route_input,
>> ip6_route_output and rt6_lookup), rt6_lookup was the only one that was
>> allowed to produce a NULL entry. Of these three rt6_lookup was also the
>> only one not actually being used for routing.
>>
>> The function that absolutely requires ip6_null_entry is ip6_route_input.
> 
> It would mean to change the logic of handling route errors like in the
> IPv4 path and not handle them in .input/.output. Instead of a dst we'd
> return a valid dst or a ERR_PTR() which would force the caller to take
> appropriate actions such as updating statistics and sending ICMPs.

Ok, it might require quite big changes to the existing code, but if
someone is willing to take a look at it I wouldn't be against it :-)

>> There is also one more issue with ip6_null_entry: previously it has
>> always been the result of an unsuccessful route lookup, now it can also
>> be the result of a successful application of a FR_ACT_UNREACHABLE policy
>> rule. From a networking point of view these two cases should IMO be
>> considered equivalent and should therefore trigger the same response.
>> This will however not be true if NULL (or an error code) is the result
>> of an unsuccessful route lookup.
> 
> Both would simply result in a -ENETUNREACHABLE.

You know, I'm starting to think we could perhaps get rid of
ip6_null_entry altogether. I at least don't really see any good reason
to keep it after such changes.

This would apply even more strongly to the new ip6_prohibit_entry and
ip6_blk_hole_entry as they don't even serve as routing table dummy entries.

Regards,
Ville