From: Michael Tokarev <mjt@tls•msk.ru>
To: Eric Dumazet <eric.dumazet@gmail•com>
Cc: netdev <netdev@vger•kernel.org>, David Miller <davem@davemloft•net>
Subject: Re: 3.0: unexpected route cache entry for wrong segment?
Date: Wed, 15 Feb 2012 16:57:55 +0400 [thread overview]
Message-ID: <4F3BABD3.5070404@msgid.tls.msk.ru> (raw)
In-Reply-To: <1329310007.2437.16.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On 15.02.2012 16:46, Eric Dumazet wrote:
> Le mercredi 15 février 2012 à 16:10 +0400, Michael Tokarev a écrit :
>
>> David, any progress with these?
>>
>> 7cc9150ebe8ec06cafea9f1c10d92ddacf88d8ae "route: fix ICMP redirect validation"
>> applies correctly to 3.0, but 9cc20b268a5a14f5e57b8ad405a83513ab0d78dc
>> "ipv4: fix redirect handling" does not, due to some changes in-between,
>> but these should be easy to sort out. Should I perhaps refresh this
>> patch myself? It should be doable, I think.
>
> I totally screwed up when I said that, I was mixing things.
Oh ok. However at least the first patch (fix ICMP redirect validation)
appears to be quite relevant here. And the second patch is also about
the very same area.
> Can you reproduce this problem with latest 3.0.21 ?
As I described before, it was the only occurence of this issue here.
I wasn't able to reproduce it by sending "bad" ICMP redirects to the
host in question (running 3.0.18). The host still hasn't been rebooted,
it is still running the same 3.0.18, but after the neigh entry expired
there hasn't been any other similar issues. Or at least not the ones
I actually seen -- it's been one case which looked the same but I haven't
seen it really, when I looked it's been gone already since the remote
machine were turned off and the entry has expired (it was from the same
remote segment btw).
Since I still don't understand where that entry (caused by what? stray
ICMP redirect? Something else?) come from in the first place, nor do I
know how to reproduce this, I'm just waiting and watching.
3.0.21 included "net: fix NULL dereferences in check_peer_redir()" patch
(which is somewhat large(ish) - I wonder why it has been rolled into
single patch while in reality it consists of 7 commits; and I wonder
why the final result is different from current version in check_peer_redir()
routine, which I mentioned in my other email in this thread), but that
one does not seem to address this very issue - from a quick view anyway.
Thank you!
/mjt
next prev parent reply other threads:[~2012-02-15 12:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-09 17:02 3.0: unexpected route cache entry for wrong segment? Michael Tokarev
2012-02-09 17:45 ` Eric Dumazet
2012-02-09 18:05 ` Eric Dumazet
2012-02-09 18:37 ` Michael Tokarev
2012-02-15 12:10 ` Michael Tokarev
2012-02-15 12:44 ` Michael Tokarev
2012-02-15 12:46 ` Eric Dumazet
2012-02-15 12:57 ` Michael Tokarev [this message]
2012-02-15 13:03 ` Eric Dumazet
2012-02-28 11:38 ` Michael Tokarev
2012-02-28 19:07 ` David Miller
2012-02-29 1:00 ` Michael Tokarev
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=4F3BABD3.5070404@msgid.tls.msk.ru \
--to=mjt@tls$(echo .)msk.ru \
--cc=davem@davemloft$(echo .)net \
--cc=eric.dumazet@gmail$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox