Bug#625914: [Bridge] Bug#625914: linux-image-2.6.38-2-amd64: bridging is not interacting well with multicast in 2.6.38-4

2011-05-13 Thread Stephen Hemminger
On Tue, 10 May 2011 16:35:40 -0700
Noah Meyerhans no...@debian.org wrote:

 On Tue, May 10, 2011 at 03:11:00PM -0700, Stephen Hemminger wrote:
  There were two more follow on commits in stable related to this.
  I recommend merging 2.6.38.6 which includes these.
 
 The problem still exists in the current 2.6.38.6.  Backing out 5f1c356a
 still solves the problem there.
 
 I have not yet tried anything outside the stable-2.6.38.y tree, but it
 seems like these same changes are present there, and it's unlikely that
 other releases will work any better.
 
 noah
 

Is this unique to the tap interfaces or does bridging multicast
not work for all devices?


-- 



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110513110326.60fa09b4@nehalam



Bug#625914: [Bridge] Bug#625914: linux-image-2.6.38-2-amd64: bridging is not interacting well with multicast in 2.6.38-4

2011-05-12 Thread David Miller
From: Noah Meyerhans no...@debian.org
Date: Tue, 10 May 2011 16:35:40 -0700

 On Tue, May 10, 2011 at 03:11:00PM -0700, Stephen Hemminger wrote:
 There were two more follow on commits in stable related to this.
 I recommend merging 2.6.38.6 which includes these.
 
 The problem still exists in the current 2.6.38.6.  Backing out 5f1c356a
 still solves the problem there.
 
 I have not yet tried anything outside the stable-2.6.38.y tree, but it
 seems like these same changes are present there, and it's unlikely that
 other releases will work any better.

So the issue is that if we back out that change, we get crashes.

Aparently there is a code path where whatever is existing in the
SKB ip options block matters, and needs to be maintained.

Someone needs to audit all of this and figure out how to fix the
problem properly.



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110512.155916.115945119.da...@davemloft.net



Bug#625914: [Bridge] Bug#625914: linux-image-2.6.38-2-amd64: bridging is not interacting well with multicast in 2.6.38-4

2011-05-12 Thread Stephen Hemminger
On Thu, 12 May 2011 15:59:16 -0700 (PDT)
David Miller da...@davemloft.net wrote:

 From: Noah Meyerhans no...@debian.org
 Date: Tue, 10 May 2011 16:35:40 -0700
 
  On Tue, May 10, 2011 at 03:11:00PM -0700, Stephen Hemminger wrote:
  There were two more follow on commits in stable related to this.
  I recommend merging 2.6.38.6 which includes these.
  
  The problem still exists in the current 2.6.38.6.  Backing out 5f1c356a
  still solves the problem there.
  
  I have not yet tried anything outside the stable-2.6.38.y tree, but it
  seems like these same changes are present there, and it's unlikely that
  other releases will work any better.
 
 So the issue is that if we back out that change, we get crashes.
 
 Aparently there is a code path where whatever is existing in the
 SKB ip options block matters, and needs to be maintained.
 
 Someone needs to audit all of this and figure out how to fix the
 problem properly.
 --
 To unsubscribe from this list: send the line unsubscribe netdev in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

I suspect tuntap is part of the problem. The skb may not be
allocated with enough padding or something like that. No guarantees
but will do some investigation.


-- 



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110512162810.34b8d55a@nehalam



Bug#625914: [Bridge] Bug#625914: linux-image-2.6.38-2-amd64: bridging is not interacting well with multicast in 2.6.38-4

2011-05-12 Thread Stephen Hemminger
On Tue, 10 May 2011 16:35:40 -0700
Noah Meyerhans no...@debian.org wrote:

 On Tue, May 10, 2011 at 03:11:00PM -0700, Stephen Hemminger wrote:
  There were two more follow on commits in stable related to this.
  I recommend merging 2.6.38.6 which includes these.
 
 The problem still exists in the current 2.6.38.6.  Backing out 5f1c356a
 still solves the problem there.
 
 I have not yet tried anything outside the stable-2.6.38.y tree, but it
 seems like these same changes are present there, and it's unlikely that
 other releases will work any better.

Does this fix the problem?  The tap driver allocates an skb and throws
it into the receive path, but the skb does not have the same padding
as normal skb's received.

--- a/drivers/net/tun.c 2011-05-12 16:36:15.231347935 -0700
+++ b/drivers/net/tun.c 2011-05-12 16:36:38.503464573 -0700
@@ -614,7 +614,7 @@ static __inline__ ssize_t tun_get_user(s
}
 
if ((tun-flags  TUN_TYPE_MASK) == TUN_TAP_DEV) {
-   align = NET_IP_ALIGN;
+   align = NET_IP_ALIGN + NET_SKB_PAD;
if (unlikely(len  ETH_HLEN ||
 (gso.hdr_len  gso.hdr_len  ETH_HLEN)))
return -EINVAL;

-- 



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110512164322.45626683@nehalam



Bug#625914: [Bridge] Bug#625914: linux-image-2.6.38-2-amd64: bridging is not interacting well with multicast in 2.6.38-4

2011-05-12 Thread Noah Meyerhans
On Thu, May 12, 2011 at 04:43:22PM -0700, Stephen Hemminger wrote:
   There were two more follow on commits in stable related to this.
   I recommend merging 2.6.38.6 which includes these.
  
  The problem still exists in the current 2.6.38.6.  Backing out 5f1c356a
  still solves the problem there.
  
  I have not yet tried anything outside the stable-2.6.38.y tree, but it
  seems like these same changes are present there, and it's unlikely that
  other releases will work any better.
 
 Does this fix the problem?  The tap driver allocates an skb and throws
 it into the receive path, but the skb does not have the same padding
 as normal skb's received.
 
 --- a/drivers/net/tun.c   2011-05-12 16:36:15.231347935 -0700
 +++ b/drivers/net/tun.c   2011-05-12 16:36:38.503464573 -0700
 @@ -614,7 +614,7 @@ static __inline__ ssize_t tun_get_user(s
   }
  
   if ((tun-flags  TUN_TYPE_MASK) == TUN_TAP_DEV) {
 - align = NET_IP_ALIGN;
 + align = NET_IP_ALIGN + NET_SKB_PAD;
   if (unlikely(len  ETH_HLEN ||
(gso.hdr_len  gso.hdr_len  ETH_HLEN)))
   return -EINVAL;
 

Sorry, this does not fix the problem.

noah



signature.asc
Description: Digital signature


Bug#625914: [Bridge] Bug#625914: linux-image-2.6.38-2-amd64: bridging is not interacting well with multicast in 2.6.38-4

2011-05-10 Thread Stephen Hemminger
On Tue, 10 May 2011 11:05:40 -0700
Noah Meyerhans no...@debian.org wrote:

 On Tue, May 10, 2011 at 01:42:49PM +0100, Ben Hutchings wrote:
This is pretty weird.  Debian version 2.6.38-3 has a few bridging
changes from stable 2.6.38.3 and 2.6.38.4, but they don't look like they
would cause this.
   
   I have apparently filed the bug against the wrong version of Debian's
   kernel.  2.6.38-3 is not affected, and works as expected.  The change
   was introduced in -4.  That may have been clear from the report itself,
   but the report was filed against -3.  I've fixed that in the BTS.
  
  I gathered that, and then made the same mistake in writing the above!
  The version with the regression, 2.6.38-4, includes the changes from
  stable 2.6.38.3 and 2.6.38.4
 
 With a little help from git bisect, I've tracked this regression down to
 the following commit to the stable-2.6.38.y tree:
 
 commit 5f1c356a3fadc0c19922d660da723b79bcc9aad7
 Author: Herbert Xu herb...@gondor.apana.org.au
 Date:   Fri Mar 18 05:27:28 2011 +
 
 bridge: Reset IPCB when entering IP stack on NF_FORWARD
 
 [ Upstream commit 6b1e960fdbd75dcd9bcc3ba5ff8898ff1ad30b6e ]
 
 Whenever we enter the IP stack proper from bridge netfilter we
 need to ensure that the skb is in a form the IP stack expects
 it to be in.
 
 The entry point on NF_FORWARD did not meet the requirements of
 the IP stack, therefore leading to potential crashes/panics.
 
 This patch fixes the problem.
 
 Signed-off-by: Herbert Xu herb...@gondor.apana.org.au
 Acked-by: Stephen Hemminger shemmin...@vyatta.com
 Signed-off-by: David S. Miller da...@davemloft.net
 Signed-off-by: Greg Kroah-Hartman gre...@suse.de
 
 The diff is
 diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
 index 4b5b66d..49d50ea 100644
 --- a/net/bridge/br_netfilter.c
 +++ b/net/bridge/br_netfilter.c
 @@ -741,6 +741,9 @@ static unsigned int br_nf_forward_ip(unsigned int
 hook, struct sk_buff *skb,
 nf_bridge-mask |= BRNF_PKT_TYPE;
 }
  
 +   if (br_parse_ip_options(skb))
 +   return NF_DROP;
 +
 /* The physdev module checks on this */
 nf_bridge-mask |= BRNF_BRIDGED;
 nf_bridge-physoutdev = skb-dev;
 
 If I revert this change, network connectivity functions as expected for
 the VMs on this host.
 
 I don't know enough about this change or the problem it was supposed to
 solve to be able to guess about what's going wrong.
 
 noah
 

There were two more follow on commits in stable related to this.
I recommend merging 2.6.38.6 which includes these.


-- 



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110510151100.52a9f8fa@nehalam



Bug#625914: [Bridge] Bug#625914: linux-image-2.6.38-2-amd64: bridging is not interacting well with multicast in 2.6.38-4

2011-05-10 Thread Noah Meyerhans
On Tue, May 10, 2011 at 03:11:00PM -0700, Stephen Hemminger wrote:
 There were two more follow on commits in stable related to this.
 I recommend merging 2.6.38.6 which includes these.

The problem still exists in the current 2.6.38.6.  Backing out 5f1c356a
still solves the problem there.

I have not yet tried anything outside the stable-2.6.38.y tree, but it
seems like these same changes are present there, and it's unlikely that
other releases will work any better.

noah



signature.asc
Description: Digital signature