[Bridge] bridge_list orphans in linux-2.4

[Bridge] bridge_list orphans in linux-2.4

[Alex Zeffertt]

Hi all,

We use linux-2.4.20 in one of our products and we've found what looks
to be a problem in the bridge module.  (I know this is old code but we
don't send our customers kernel upgrades unless we really have to!)

The problem is that some of our bridges have become orphaned from the
bridge module.  Specifically

	ifconfig ourbridgename

shows that the device "ourbridgename" is known to the kernel, but

	brctl show

does not list "ourbridgename".


I've looked through the bridge module and it seems that the most likely
explanation is that bridge_list in br_if.c has become corrupted, causing
the bridge called "ourbridgename" to become orphaned.

I cannot see how this would happen, however, since bridge_list is only
ever referenced under the ioctl_mutex.  I should also point out that
br_del_bridge() is not called by our application.

I noticed that in later kernels the ioctl_mutex has been replaced by
the rtnl_lock().  Why was this done?  Could this be related to our
problem?

TIA,

Alex

Re: [Bridge] bridge_list orphans in linux-2.4

[Stephen Hemminger]

On Thu, 21 Sep 2006 14:42:22 +0100
Alex Zeffertt <ajz@cambridgebroadband.com> wrote:

> Hi all,
> 
> We use linux-2.4.20 in one of our products and we've found what looks
> to be a problem in the bridge module.  (I know this is old code but we
> don't send our customers kernel upgrades unless we really have to!)
> 
> The problem is that some of our bridges have become orphaned from the
> bridge module.  Specifically
> 
> 	ifconfig ourbridgename
> 
> shows that the device "ourbridgename" is known to the kernel, but
> 
> 	brctl show
> 
> does not list "ourbridgename".

You need to find a sequence of commands that reproduces it.
Unless you run multiple commands in parallel, I don't think
there should be a problem with 2.4.

> I've looked through the bridge module and it seems that the most likely
> explanation is that bridge_list in br_if.c has become corrupted, causing
> the bridge called "ourbridgename" to become orphaned.
> 
> I cannot see how this would happen, however, since bridge_list is only
> ever referenced under the ioctl_mutex.  I should also point out that
> br_del_bridge() is not called by our application.
> 
> I noticed that in later kernels the ioctl_mutex has been replaced by
> the rtnl_lock().  Why was this done?  Could this be related to our
> problem?

In 2.6 it was observed that all changes to bridge list were already
being done under the RT netlink mutex, so no additional locking
was needed.

-- 
Stephen Hemminger <shemminger@osdl.org>

Re: [Bridge] bridge_list orphans in linux-2.4

[Alex Zeffertt]

Hi Majjari,

We've solved the problem now.  It turned out that the bridge_list in the
kernel was not being corrupted.   The problem was actually that
"brctl show" was only returning the last 32 bridges created.  We upped
this to 2048, which required a brctl change and also a kernel module change.

The patch is attached.

HTH,

Alex

===================================================================
RCS file: /newcvs/intel-linux/net/bridge/br_ioctl.c,v
retrieving revision 1.3
retrieving revision 1.3.14.1
diff -u -r1.3 -r1.3.14.1
--- br_ioctl.c  20 Jul 2004 10:13:42 -0000      1.3
+++ br_ioctl.c  2 Nov 2006 16:59:14 -0000       1.3.14.1
@@ -5,7 +5,7 @@
   *     Authors:
   *     Lennert Buytenhek               <buytenh@gnu.org>
   *
- *     $Id: br_ioctl.c,v 1.3 2004/07/20 10:13:42 ajz Exp $
+ *     $Id: br_ioctl.c,v 1.3.14.1 2006/11/02 16:59:14 srowe Exp $
   *
   *     This program is free software; you can redistribute it and/or
   *     modify it under the terms of the GNU General Public License
@@ -233,18 +233,22 @@

         case BRCTL_GET_BRIDGES:
         {
-               int i;
-               int indices[64];
+               int *indices;
+               int ret = 0;

-               for (i=0;i<64;i++)
-                       indices[i] = 0;
+               if (arg1 >= 2048)
+                       return -ENOMEM;
+               indices = kmalloc(arg1*sizeof(int), GFP_KERNEL);
+               if (indices == NULL)
+                       return -ENOMEM;
+
+               memset(indices, 0, arg1*sizeof(int));

-               if (arg1 > 64)
-                       arg1 = 64;
                 arg1 = br_get_bridge_ifindices(indices, arg1);
-               if (copy_to_user((void *)arg0, indices, arg1*sizeof(int)))
-                       return -EFAULT;
+               ret = copy_to_user((void *)arg0, indices, arg1*sizeof(int))
+                       ? -EFAULT : arg1;

+               kfree(indices);
                 return arg1;
         }


===================================================================
RCS file: /newcvs/third-party/bridge-utils/libbridge/libbridge_init.c,v
retrieving revision 1.3
retrieving revision 1.3.14.1
diff -u -r1.3 -r1.3.14.1
--- libbridge_init.c    25 May 2004 16:42:58 -0000      1.3
+++ libbridge_init.c    2 Nov 2006 16:59:55 -0000       1.3.14.1
@@ -158,10 +158,10 @@
  int br_make_bridge_list()
  {
         int i;
-       int ifindices[32];
+       int ifindices[2047];
         int num;

-       num = br_ioctl(BRCTL_GET_BRIDGES, (unsigned long)ifindices, 32);
+       num = br_ioctl(BRCTL_GET_BRIDGES, (unsigned long)ifindices, 2047);
         if (num < 0)
                 return errno;




Majjari Vikram(TLS-ESG), Bangalore wrote:
> Hi I have a similar problem. Can u please send me how u have solved it.
> 
>  
> 
> /*/ /*/
> 
> /*/Regards,/*/
> 
> /*/Vikram./*/////
> 
>  
> 
> DISCLAIMER:
> -----------------------------------------------------------------------------------------------------------------------
> 
> The contents of this e-mail and any attachment(s) are confidential and 
> intended for the named recipient(s) only.
> It shall not attach any liability on the originator or HCL or its 
> affiliates. Any views or opinions presented in
> this email are solely those of the author and may not necessarily 
> reflect the opinions of HCL or its affiliates.
> Any form of reproduction, dissemination, copying, disclosure, 
> modification, distribution and / or publication of
> this message without the prior written consent of the author of this 
> e-mail is strictly prohibited. If you have
> received this email in error please delete it and notify the sender 
> immediately. Before opening any mail and
> attachments please check them for viruses and defect.
> 
> -----------------------------------------------------------------------------------------------------------------------
> 

Re: [Bridge] bridge_list orphans in linux-2.4

[Stephen Hemminger]

On Fri, 15 Dec 2006 15:01:51 +0000
Alex Zeffertt <ajz@cambridgebroadband.com> wrote:

> Hi Majjari,
> 
> We've solved the problem now.  It turned out that the bridge_list in the
> kernel was not being corrupted.   The problem was actually that
> "brctl show" was only returning the last 32 bridges created.  We upped
> this to 2048, which required a brctl change and also a kernel module change.
> 
> The patch is attached.
> 
> HTH,
> 
> Alex
>

I'll clean this up, and submit it. The current bridge-utils already supports
both 2.4 and 2.6, and handles up to 1024 bridges.

Re: [Bridge] bridge_list orphans in linux-2.4

[Stephen Hemminger]

On Fri, 15 Dec 2006 15:01:51 +0000
Alex Zeffertt <ajz@cambridgebroadband.com> wrote:

> Hi Majjari,
> 
> We've solved the problem now.  It turned out that the bridge_list in the
> kernel was not being corrupted.   The problem was actually that
> "brctl show" was only returning the last 32 bridges created.  We upped
> this to 2048, which required a brctl change and also a kernel module change.
> 
> The patch is attached.
> 
> HTH,
> 
> Alex

Actually, I would prefer NOT to send this upstream for later 2.4 releases because
the 2.4 code is in long term stability mode, and support >32 bridges is an enhancement,
not a bug.

Re: [Bridge] bridge_list orphans in linux-2.4

[Alex Zeffertt]

Stephen Hemminger wrote:
> On Fri, 15 Dec 2006 15:01:51 +0000
> Alex Zeffertt <ajz@cambridgebroadband.com> wrote:
> 
>> Hi Majjari,
>>
>> We've solved the problem now.  It turned out that the bridge_list in the
>> kernel was not being corrupted.   The problem was actually that
>> "brctl show" was only returning the last 32 bridges created.  We upped
>> this to 2048, which required a brctl change and also a kernel module change.
>>
>> The patch is attached.
>>
>> HTH,
>>
>> Alex
> 
> Actually, I would prefer NOT to send this upstream for later 2.4 releases because
> the 2.4 code is in long term stability mode, and support >32 bridges is an enhancement,
> not a bug.

That is perfectly reasonable.  However, if the bridge-utils does not support
more than 32 bridges then it should fail to create more than 32.  At the
moment it allows you to create as many as you wish but only returns info on the
most recent 32 when you run "brctl show".

Regards,

Alex