Re: 2.6.25-rc9: Reported regressions from 2.6.24

Re: 2.6.25-rc9: Reported regressions from 2.6.24

[Patrick McHardy]

Rafael J. Wysocki wrote:
> This message contains a list of some regressions from 2.6.24, for which there
> are no fixes in the mainline I know of.  If any of them have been fixed already,
> please let me know.
>
>
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10323
> Subject		: panic using bridging on linus kernel 2.6.25-rc6
> Submitter	: Andy Gospodarek <andy@greyhouse.net>
> Date		: 2008-03-25 11:40 (20 days old)

This looks like another network-namespace regression.
icmp_send() does:

        net = rt->u.dst.dev->nd_net;

The bridge netfilter code attaches a fake dst_entry to the
skb which has dev == NULL when passing it to IPv4 netfilter.

Pavel, do you have a better ideas for fixing this than
instantiating a dst_entry in br_netfilter.c for every
device (or at least for every namespace)?

Re: 2.6.25-rc9: Reported regressions from 2.6.24

[Patrick McHardy]

[CC list trimmed slightly]

Patrick McHardy wrote:
> Rafael J. Wysocki wrote:
>> This message contains a list of some regressions from 2.6.24, for 
>> which there
>> are no fixes in the mainline I know of.  If any of them have been 
>> fixed already,
>> please let me know.
>>
>>
>> Bug-Entry    : http://bugzilla.kernel.org/show_bug.cgi?id=10323
>> Subject        : panic using bridging on linus kernel 2.6.25-rc6
>> Submitter    : Andy Gospodarek <andy@greyhouse.net>
>> Date        : 2008-03-25 11:40 (20 days old)
>
> This looks like another network-namespace regression.
> icmp_send() does:
>
>        net = rt->u.dst.dev->nd_net;
>
> The bridge netfilter code attaches a fake dst_entry to the
> skb which has dev == NULL when passing it to IPv4 netfilter.
>
> Pavel, do you have a better ideas for fixing this than
> instantiating a dst_entry in br_netfilter.c for every
> device (or at least for every namespace)? 

The description of the problem was not entirely correct, the
bridge-netfilter dst_entry does have a proper device pointer,
it points to a dummy net_device structure however that doesn't
have a namespace associated with it. This blows up in
__ip_route_output_key.

Re: 2.6.25-rc9: Reported regressions from 2.6.24

[Patrick McHardy]

[-- Attachment #1: Type: text/plain, Size: 1049 bytes --]

Patrick McHardy wrote:
>>>
>>> Bug-Entry    : http://bugzilla.kernel.org/show_bug.cgi?id=10323
>>> Subject        : panic using bridging on linus kernel 2.6.25-rc6
>>> Submitter    : Andy Gospodarek <andy@greyhouse.net>
>>> Date        : 2008-03-25 11:40 (20 days old)
>>
>> This looks like another network-namespace regression.
>> icmp_send() does:
>>
>>        net = rt->u.dst.dev->nd_net;
>>
>> The bridge netfilter code attaches a fake dst_entry to the
>> skb which has dev == NULL when passing it to IPv4 netfilter.
>>
>> Pavel, do you have a better ideas for fixing this than
>> instantiating a dst_entry in br_netfilter.c for every
>> device (or at least for every namespace)? 
>
> The description of the problem was not entirely correct, the
> bridge-netfilter dst_entry does have a proper device pointer,
> it points to a dummy net_device structure however that doesn't
> have a namespace associated with it. This blows up in
> __ip_route_output_key.

For now I suggest this fix. Andy, could you please test whether it
fixes the problem?



[-- Attachment #2: x --]
[-- Type: text/plain, Size: 1143 bytes --]

[BRIDGE]: Fix crash in __ip_route_output_key with bridge netfilter

The bridge netfilter code attaches a fake dst_entry with a pointer to a
fake net_device structure to skbs it passes up to IPv4 netfilter. This
leads to crashes when the skb is passed to __ip_route_output_key when
dereferencing the namespace pointer.

Since bridging can currently only operate in the init_net namespace,
the easiest fix for now is to initialize the nd_net pointer of the
fake net_device struct to &init_net.

Should fix bugzilla 10323: http://bugzilla.kernel.org/show_bug.cgi?id=10323

Signed-off-by: Patrick McHardy <kaber@trash.net>

diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
index 1c0efd8..af7e8be 100644
--- a/net/bridge/br_netfilter.c
+++ b/net/bridge/br_netfilter.c
@@ -110,7 +110,8 @@ static inline __be16 pppoe_proto(const struct sk_buff *skb)
  * ipt_REJECT needs it.  Future netfilter modules might
  * require us to fill additional fields. */
 static struct net_device __fake_net_device = {
-	.hard_header_len	= ETH_HLEN
+	.hard_header_len	= ETH_HLEN,
+	.nd_net			= &init_net,
 };
 
 static struct rtable __fake_rtable = {

Re: 2.6.25-rc9: Reported regressions from 2.6.24

[David Miller]

From: Patrick McHardy <kaber@trash.net>
Date: Sun, 13 Apr 2008 22:18:54 +0200

> [BRIDGE]: Fix crash in __ip_route_output_key with bridge netfilter
> 
> The bridge netfilter code attaches a fake dst_entry with a pointer to a
> fake net_device structure to skbs it passes up to IPv4 netfilter. This
> leads to crashes when the skb is passed to __ip_route_output_key when
> dereferencing the namespace pointer.
> 
> Since bridging can currently only operate in the init_net namespace,
> the easiest fix for now is to initialize the nd_net pointer of the
> fake net_device struct to &init_net.
> 
> Should fix bugzilla 10323: http://bugzilla.kernel.org/show_bug.cgi?id=10323
> 
> Signed-off-by: Patrick McHardy <kaber@trash.net>

Even though we don't have a test report back yet, I've applied this,
thanks Patrick.

Re: 2.6.25-rc9: Reported regressions from 2.6.24

[Andy Gospodarek]

On Sun, Apr 13, 2008 at 10:18:54PM +0200, Patrick McHardy wrote:
> Patrick McHardy wrote:
> >>>
> >>>Bug-Entry    : http://bugzilla.kernel.org/show_bug.cgi?id=10323
> >>>Subject        : panic using bridging on linus kernel 2.6.25-rc6
> >>>Submitter    : Andy Gospodarek <andy@greyhouse.net>
> >>>Date        : 2008-03-25 11:40 (20 days old)
> >>
> >>This looks like another network-namespace regression.
> >>icmp_send() does:
> >>
> >>       net = rt->u.dst.dev->nd_net;
> >>
> >>The bridge netfilter code attaches a fake dst_entry to the
> >>skb which has dev == NULL when passing it to IPv4 netfilter.
> >>
> >>Pavel, do you have a better ideas for fixing this than
> >>instantiating a dst_entry in br_netfilter.c for every
> >>device (or at least for every namespace)? 
> >
> >The description of the problem was not entirely correct, the
> >bridge-netfilter dst_entry does have a proper device pointer,
> >it points to a dummy net_device structure however that doesn't
> >have a namespace associated with it. This blows up in
> >__ip_route_output_key.
> 
> For now I suggest this fix. Andy, could you please test whether it
> fixes the problem?
> 
> 

I'm guessing it will.  I've been testing my older kernels today and
somehow I'm unable to reproduce the original problem, so I need to
figure out what is different about my config now and before.

I'll definitely post back when I test this, but I wanted to make sure
you guys knew I was at least trying it. :)

Re: 2.6.25-rc9: Reported regressions from 2.6.24

[Andy Gospodarek]

On Mon, Apr 14, 2008 at 04:31:11PM -0400, Andy Gospodarek wrote:
> On Sun, Apr 13, 2008 at 10:18:54PM +0200, Patrick McHardy wrote:
> > Patrick McHardy wrote:
> > >>>
> > >>>Bug-Entry    : http://bugzilla.kernel.org/show_bug.cgi?id=10323
> > >>>Subject        : panic using bridging on linus kernel 2.6.25-rc6
> > >>>Submitter    : Andy Gospodarek <andy@greyhouse.net>
> > >>>Date        : 2008-03-25 11:40 (20 days old)
> > >>
> > >>This looks like another network-namespace regression.
> > >>icmp_send() does:
> > >>
> > >>       net = rt->u.dst.dev->nd_net;
> > >>
> > >>The bridge netfilter code attaches a fake dst_entry to the
> > >>skb which has dev == NULL when passing it to IPv4 netfilter.
> > >>
> > >>Pavel, do you have a better ideas for fixing this than
> > >>instantiating a dst_entry in br_netfilter.c for every
> > >>device (or at least for every namespace)? 
> > >
> > >The description of the problem was not entirely correct, the
> > >bridge-netfilter dst_entry does have a proper device pointer,
> > >it points to a dummy net_device structure however that doesn't
> > >have a namespace associated with it. This blows up in
> > >__ip_route_output_key.
> > 
> > For now I suggest this fix. Andy, could you please test whether it
> > fixes the problem?
> > 
> > 
> 
> I'm guessing it will.  I've been testing my older kernels today and
> somehow I'm unable to reproduce the original problem, so I need to
> figure out what is different about my config now and before.
> 
> I'll definitely post back when I test this, but I wanted to make sure
> you guys knew I was at least trying it. :)
> 

I just got done testing 159d83363b629c91d020734207c1bc788b96af5a and I
can confirm that is resolves my issue.

Re: 2.6.25-rc9: Reported regressions from 2.6.24

[Patrick McHardy]

Andy Gospodarek wrote:
> On Mon, Apr 14, 2008 at 04:31:11PM -0400, Andy Gospodarek wrote:
>> On Sun, Apr 13, 2008 at 10:18:54PM +0200, Patrick McHardy wrote:
>>>
>>> For now I suggest this fix. Andy, could you please test whether it
>>> fixes the problem?
>>>
>>>
>> I'm guessing it will.  I've been testing my older kernels today and
>> somehow I'm unable to reproduce the original problem, so I need to
>> figure out what is different about my config now and before.
>>
>> I'll definitely post back when I test this, but I wanted to make sure
>> you guys knew I was at least trying it. :)
>>
> 
> I just got done testing 159d83363b629c91d020734207c1bc788b96af5a and I
> can confirm that is resolves my issue.


Thanks Andy.

Re: 2.6.25-rc9: Reported regressions from 2.6.24

[Pavel Emelyanov]

Patrick McHardy wrote:
> Rafael J. Wysocki wrote:
>> This message contains a list of some regressions from 2.6.24, for which there
>> are no fixes in the mainline I know of.  If any of them have been fixed already,
>> please let me know.
>>
>>
>> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10323
>> Subject		: panic using bridging on linus kernel 2.6.25-rc6
>> Submitter	: Andy Gospodarek <andy@greyhouse.net>
>> Date		: 2008-03-25 11:40 (20 days old)
> 
> This looks like another network-namespace regression.
> icmp_send() does:
> 
>         net = rt->u.dst.dev->nd_net;
> 
> The bridge netfilter code attaches a fake dst_entry to the
> skb which has dev == NULL when passing it to IPv4 netfilter.
> 
> Pavel, do you have a better ideas for fixing this than
> instantiating a dst_entry in br_netfilter.c for every
> device (or at least for every namespace)?

Hm... Why not make this dst entry point to looback device? This would
allow us to make the dst entry per-namespace and instantiate it with
the ns's lo.

Thanks,
Pavel

Re: 2.6.25-rc9: Reported regressions from 2.6.24

[Patrick McHardy]

Pavel Emelyanov wrote:
> Patrick McHardy wrote:
>> Rafael J. Wysocki wrote:
>>> This message contains a list of some regressions from 2.6.24, for which there
>>> are no fixes in the mainline I know of.  If any of them have been fixed already,
>>> please let me know.
>>>
>>>
>>> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10323
>>> Subject		: panic using bridging on linus kernel 2.6.25-rc6
>>> Submitter	: Andy Gospodarek <andy@greyhouse.net>
>>> Date		: 2008-03-25 11:40 (20 days old)
>> This looks like another network-namespace regression.
>> icmp_send() does:
>>
>>         net = rt->u.dst.dev->nd_net;
>>
>> The bridge netfilter code attaches a fake dst_entry to the
>> skb which has dev == NULL when passing it to IPv4 netfilter.
>>
>> Pavel, do you have a better ideas for fixing this than
>> instantiating a dst_entry in br_netfilter.c for every
>> device (or at least for every namespace)?
> 
> Hm... Why not make this dst entry point to looback device? This would
> allow us to make the dst entry per-namespace and instantiate it with
> the ns's lo.


I thought of that myself, but that will result in MTU problems.
The current way is not ideal either (hardcoded MTU of 1500 for
the fake net_device), but that at least works in normal bridge
setups.