All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ville Nuorvala <vnuorval@tcs.hut.fi>
To: Thomas Graf <tgraf@suug.ch>
Cc: David Miller <davem@davemloft.net>, netdev@vger.kernel.org
Subject: Re: [PATCH][IPV6]: Make sure fib6_rule_lookup doesn't return NULL
Date: Wed, 09 Aug 2006 12:42:19 +0300	[thread overview]
Message-ID: <44D9ADFB.90200@tcs.hut.fi> (raw)
In-Reply-To: <20060809092311.GU14627@postel.suug.ch>

Thomas Graf wrote:
> * Ville Nuorvala <vnuorval@tcs.hut.fi> 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

  reply	other threads:[~2006-08-09  9:42 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-08 22:05 [PATCH][IPV6]: Make sure fib6_rule_lookup doesn't return NULL Ville Nuorvala
2006-08-08 22:16 ` Thomas Graf
2006-08-08 23:43   ` David Miller
2006-08-09  6:31     ` Ville Nuorvala
2006-08-09  6:34       ` David Miller
2006-08-09  8:36         ` Ville Nuorvala
2006-08-09  9:23           ` Thomas Graf
2006-08-09  9:42             ` Ville Nuorvala [this message]
2006-08-09  9:48               ` Thomas Graf
2006-08-09 10:45                 ` Ville Nuorvala

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44D9ADFB.90200@tcs.hut.fi \
    --to=vnuorval@tcs.hut.fi \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=tgraf@suug.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.