ip_rt_bug questions.

ip_rt_bug questions.

[Dave Jones]

I managed to trigger this today..

ip_rt_bug: 0.0.0.0 -> 255.255.255.255, ?

if this is useful in some way, maybe it should be enhanced
to print out something else, like a backtrace ?

Also, should it be a printk_ratelimit() ? Or is there
ratelimiting done elsewhere in the routing code ?

or should it just be silenced, leaving just the kfree_skb ?

	Dave

Re: ip_rt_bug questions.

[David Miller]

From: Dave Jones <davej@redhat.com>
Date: Mon, 18 Apr 2011 17:48:10 -0400

> I managed to trigger this today..
> 
> ip_rt_bug: 0.0.0.0 -> 255.255.255.255, ?
> 
> if this is useful in some way, maybe it should be enhanced
> to print out something else, like a backtrace ?
> 
> Also, should it be a printk_ratelimit() ? Or is there
> ratelimiting done elsewhere in the routing code ?
> 
> or should it just be silenced, leaving just the kfree_skb ?

It's a very serious issue, it means we used an input route for
packet output.

Kernel version and what you were doing to trigger this?

Re: ip_rt_bug questions.

[David Miller]

From: David Miller <davem@davemloft.net>
Date: Mon, 18 Apr 2011 14:49:09 -0700 (PDT)

> From: Dave Jones <davej@redhat.com>
> Date: Mon, 18 Apr 2011 17:48:10 -0400
> 
>> I managed to trigger this today..
>> 
>> ip_rt_bug: 0.0.0.0 -> 255.255.255.255, ?
>> 
>> if this is useful in some way, maybe it should be enhanced
>> to print out something else, like a backtrace ?
>> 
>> Also, should it be a printk_ratelimit() ? Or is there
>> ratelimiting done elsewhere in the routing code ?
>> 
>> or should it just be silenced, leaving just the kfree_skb ?
> 
> It's a very serious issue, it means we used an input route for
> packet output.
> 
> Kernel version and what you were doing to trigger this?

BTW, if you could modify this thing to spit out a stack
trace (probably by using WARN_ON() or similar) that will
probably show us where the bug is coming from.

Thanks.

Re: ip_rt_bug questions.

[Dave Jones]

On Mon, Apr 18, 2011 at 02:50:23PM -0700, David Miller wrote:
 
 > >> ip_rt_bug: 0.0.0.0 -> 255.255.255.255, ?
 > >> 
 > > It's a very serious issue, it means we used an input route for
 > > packet output.
 > > 
 > > Kernel version and what you were doing to trigger this?

current HEAD from Linus' tree.
It fell out twice so far this afternoon from my system call fuzzer.

 > BTW, if you could modify this thing to spit out a stack
 > trace (probably by using WARN_ON() or similar) that will
 > probably show us where the bug is coming from.

Ok, I'll add that, and see if I can reproduce it again.

	Dave

Re: ip_rt_bug questions.

[David Miller]

From: Dave Jones <davej@redhat.com>
Date: Mon, 18 Apr 2011 17:59:23 -0400

> On Mon, Apr 18, 2011 at 02:50:23PM -0700, David Miller wrote:
>  
>  > BTW, if you could modify this thing to spit out a stack
>  > trace (probably by using WARN_ON() or similar) that will
>  > probably show us where the bug is coming from.
> 
> Ok, I'll add that, and see if I can reproduce it again.

Thanks a lot Dave.

Re: ip_rt_bug questions.

[Dave Jones]

On Mon, Apr 18, 2011 at 10:04:19PM -0700, David Miller wrote:
 > From: Dave Jones <davej@redhat.com>
 > Date: Mon, 18 Apr 2011 17:59:23 -0400
 > 
 > > On Mon, Apr 18, 2011 at 02:50:23PM -0700, David Miller wrote:
 > >  
 > >  > BTW, if you could modify this thing to spit out a stack
 > >  > trace (probably by using WARN_ON() or similar) that will
 > >  > probably show us where the bug is coming from.
 > > 
 > > Ok, I'll add that, and see if I can reproduce it again.
 > 
 > Thanks a lot Dave.

So I hit that twice in the same hour yesterday, but haven't been
able to reproduce it since.  My fuzzer must have been dependant
upon something I can't influence (memory contents perhaps, I pass
around random pointers).

I'll keep the WARN_ON in there in case I do stumble across it again.

	Dave

Re: ip_rt_bug questions.

[David Miller]

From: Dave Jones <davej@redhat.com>
Date: Tue, 19 Apr 2011 14:13:22 -0400

> So I hit that twice in the same hour yesterday, but haven't been
> able to reproduce it since.  My fuzzer must have been dependant
> upon something I can't influence (memory contents perhaps, I pass
> around random pointers).
> 
> I'll keep the WARN_ON in there in case I do stumble across it again.

Maybe it only triggers when a certain combination of your analog synths
are turned on?

Re: ip_rt_bug questions.

[Dave Jones]

On Mon, Apr 18, 2011 at 02:50:23PM -0700, David Miller wrote:
 > From: David Miller <davem@davemloft.net>
 > Date: Mon, 18 Apr 2011 14:49:09 -0700 (PDT)
 > 
 > > From: Dave Jones <davej@redhat.com>
 > > Date: Mon, 18 Apr 2011 17:48:10 -0400
 > > 
 > >> I managed to trigger this today..
 > >> 
 > >> ip_rt_bug: 0.0.0.0 -> 255.255.255.255, ?
 > >> 
 > >> if this is useful in some way, maybe it should be enhanced
 > >> to print out something else, like a backtrace ?
 > >> 
 > >> Also, should it be a printk_ratelimit() ? Or is there
 > >> ratelimiting done elsewhere in the routing code ?
 > >> 
 > >> or should it just be silenced, leaving just the kfree_skb ?
 > > 
 > > It's a very serious issue, it means we used an input route for
 > > packet output.
 > > 
 > > Kernel version and what you were doing to trigger this?
 > 
 > BTW, if you could modify this thing to spit out a stack
 > trace (probably by using WARN_ON() or similar) that will
 > probably show us where the bug is coming from.

I haven't been able to hit this again since I added the WARN_ON.
But you can guarantee that the next time I see it it will be on
a kernel where I forgot to re-add this.  Could we get this merged
so I don't have to keep remembering it ?

	Dave

Add a stack backtrace to the ip_rt_bug path for debugging

Signed-off-by: Dave Jones <davej@redhat.com>

diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 99e6e4b..6fb18b7 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1687,6 +1687,7 @@ static int ip_rt_bug(struct sk_buff *skb)
 		&ip_hdr(skb)->saddr, &ip_hdr(skb)->daddr,
 		skb->dev ? skb->dev->name : "?");
 	kfree_skb(skb);
+	WARN_ON(1);
 	return 0;
 }
 

Re: ip_rt_bug questions.

[David Miller]

From: Dave Jones <davej@redhat.com>
Date: Sat, 21 May 2011 13:16:42 -0400

> Add a stack backtrace to the ip_rt_bug path for debugging
> 
> Signed-off-by: Dave Jones <davej@redhat.com>

Applied.