From: Pavel Emelianov <[EMAIL PROTECTED]>
Date: Tue, 17 Apr 2007 15:49:30 +0400
> From: Evgeny Kravtsunov <[EMAIL PROTECTED]>
>
> compare_ether_addr() implicitly requires that the addresses
> passed are 2-bytes aligned in memory.
>
> This is not true for br_stp_change_bridge_id() and
> br_stp_re
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Tue, 17 Apr 2007 12:55:41 -0700
> David Miller wrote:
> > From: Pavel Emelianov <[EMAIL PROTECTED]>
> > Date: Tue, 17 Apr 2007 15:49:30 +0400
> >
> >
> >> From: Evgeny Kravtsunov <[EMAIL PR
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Tue, 17 Apr 2007 13:37:23 -0700
> The previous patch relied on the bridge id being aligned by
> the compiler (which happens as a side effect). So please use
> this instead.
>
> compare_ether_addr() implicitly requires that the addresses
> passed a
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Tue, 17 Apr 2007 23:24:36 +0200
> I suspect you missed part of Stephen patch :
>
> (maybe some mailer problem...)
My bad, sorry :(
I pushed the other version of the fix to Linus just now.
I'll put Stephen's version in if he sends me a fixup relative
From: Pavel Emelianov <[EMAIL PROTECTED]>
Date: Wed, 18 Apr 2007 10:43:56 +0400
> [snip]
>
> > --- linux-2.6.orig/net/bridge/br_private.h 2007-04-17
> > 13:26:48.0 -0700 +++ linux-2.6/net/bridge/br_private.h
> > 2007-04-17 13:30:29.0 -0700 @@ -36,7 +36,7 @@
> > {
> > unsigne
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Wed, 18 Apr 2007 07:44:39 -0700
> On Wed, 18 Apr 2007 01:28:04 -0700 (PDT)
> David Miller <[EMAIL PROTECTED]> wrote:
>
> > From: Pavel Emelianov <[EMAIL PROTECTED]>
> > Date: Wed, 18 A
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Thu, 19 Apr 2007 16:14:23 +0200
> On Wed, 18 Apr 2007 13:04:22 -0700 (PDT)
> David Miller <[EMAIL PROTECTED]> wrote:
>
> >
> > Although I don't think gcc does anything fancy since we don't
> > use memc
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Wed, 25 Apr 2007 16:47:38 -0700
> The change to forward STP bpdu's (for usermode STP) through normal path,
> changed the packet type in the process. Since link local stuff is multicast,
> it
> should stay pkt_type = PACKET_MULTICAST. The code was
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Wed, 25 Apr 2007 16:47:39 -0700
> Pause frames should never make it out of the network device into
> the stack. But if a device was misconfigured, it might happen.
> So drop pause frames in bridge.
>
> Signed-off-by: Stephen Hemminger <[EMAIL PROT
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Wed, 25 Apr 2007 16:47:41 -0700
> Writing to /sys/class/net/brX/bridge/stp_state causes a warning because
> RTNL is not held when call br_stp_if.c
>
> Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Applied, thanks Stephen.
_
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Wed, 30 May 2007 12:14:22 -0700
> Peroidic STP timers don't have to be exact.
> The hold timer runs at 1HZ, and the hello timer normally runs
> at 2HZ; save power by aligning it them to next second.
>
> Signed-off-by: Stephen Hemminger <[EMAIL PRO
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Tue, 14 Aug 2007 14:50:52 +0100
> Forget earlier patch, it is wrong...
>
> The stp change code generates "sleeping function called from invalid context"
> because rtnl_lock() called with BH disabled. This fixes it by not acquiring
> then
> droppi
From: "John W. Linville" <[EMAIL PROTECTED]>
Date: Thu, 30 Aug 2007 16:03:13 -0400
> On Thu, Aug 30, 2007 at 12:22:58PM -0700, Stephen Hemminger wrote:
> > This patch fixes some packet leakage in bridge. The bridging code
> > was allowing forward table entries to be generated even if a device
> >
From: Matthew Wilcox <[EMAIL PROTECTED]>
Date: Thu, 30 Aug 2007 10:48:13 -0600
> On Thu, Aug 30, 2007 at 08:29:32AM -0700, Stephen Hemminger wrote:
> > Bridge code calls ethtool to get speed. The conversion to using
> > only ethtool_ops broke the case of devices without ethtool_ops.
> > This is a
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Wed, 26 Sep 2007 15:33:30 -0700
> ipv6 is not a network driver, it is a protocol. You might be able to
> remove it if you zap all the routes and applications, ...
It is purposefully set to have a permanent elevated reference
count because it is no
From: Helge Hafting <[EMAIL PROTECTED]>
Date: Thu, 27 Sep 2007 13:54:23 +0200
> Wouldn't it be enough to down all the interfaces and close all the sockets?
> No need to bring down every app.
And there are routes, and neighbour cache entries, and all sorts
of external references to the stack. For
From: Jan Engelhardt <[EMAIL PROTECTED]>
Date: Thu, 27 Sep 2007 16:55:36 +0200 (CEST)
>
> On Sep 27 2007 07:51, Stephen Hemminger wrote:
> >
> >You need every socket to close and all routes to go away including the
> >routes through loopback device, and still there probably are control
> >socke
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Thu, 1 May 2008 13:42:09 -0700
> The forwarding table binary interface (my bad choice), only exposes the
> port number of the first 8 bits. The bridge code was limited to 256 ports
> at the time, but now the kernel supports up 1024 ports, so the up
From: Adrian Bunk <[EMAIL PROTECTED]>
Date: Tue, 20 May 2008 01:08:34 +0300
> This patch updates the URL of the bridge homepage.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Applied, thanks Adrian.
___
Bridge mailing list
Bridge@lists.linux-found
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Wed, 2 Jul 2008 09:48:17 -0700
> On Wed, 02 Jul 2008 15:04:14 +0200
> Patrick McHardy <[EMAIL PROTECTED]> wrote:
>
> > commit 96f1dd78dad10d61bdd487edadea6adda5425e4c
> > Author: Patrick McHardy <[EMAIL PROTECTED]>
> > Date: Wed Jul 2 15:02:23 2
From: Bill Nottingham <[EMAIL PROTECTED]>
Date: Mon, 7 Jul 2008 17:34:20 -0400
> I could look at wireless network configuration, but I doubt that's going to
> help your argument.
Just like any system with age, we have a lot of legacy to
convert over. But it will happen.
> That being said, how i
From: Rick Jones <[EMAIL PROTECTED]>
Date: Tue, 02 Sep 2008 09:40:46 -0700
> Can one change the TCP maximum RTO to be smaller than specified in the specs?
We always min-clamp the RTO at RTO calculation time in order to be
compatible with BSD's coarse grained times.
___
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Sun, 31 Aug 2008 10:43:09 -0700
> The Spanning Tree Protocol timers need to be set within certain boundaries
> to keep the internal protocol engine working, and to be interoperable.
> This patch restricts changes to those timers to the values defin
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Thu, 4 Sep 2008 15:47:09 -0700
> The bridge hello time can't be safely set to values less than 1 second,
> otherwise it is possible to end up with a runaway timer.
>
> Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Applied, thanks Stephen.
From: Henk Stegeman
Date: Wed, 18 Feb 2009 11:41:14 +0100
Please CC: netdev, now added, on all networking reports and patches.
Thank you.
> I discovered the hard way that because linux bridging uses
> net_device_ops, bridging only works with network drivers that publish
> their device operation
From: Grant Likely
Date: Tue, 10 Mar 2009 11:13:02 -0600
> Hi Henk,
>
> Acked-by: Grant Likely
...
> Jeff, after Henk provides his s-o-b line, do you want to pick it up,
> or should I merge it through my mpc52xx powerpc tree (via benh).
Send it to netdev, CC:'d to me, Jeff hasn't been handlin
From: Scott James Remnant
Date: Mon, 2 Mar 2009 16:40:10 +
> The bridge module is missing the net-pf-7 alias that would cause it to
> be auto-loaded when a socket of that type is opened. This patch adds
> the alias.
>
> Signed-off-by: Scott James Remnant
> Signed-off-by: Tim Gardner
Brid
From: Stephen Hemminger
Date: Fri, 13 Mar 2009 15:12:00 -0700
> Let's be supportive of Ubuntu maintainers actually working on
> upstream resolution for a change. The normal distro maintainer is
> "patch and ignore".
This has nothing to do with being supportive or not.
If the changes are wrong,
From: Jiri Pirko
Date: Mon, 16 Mar 2009 12:11:28 +0100
> I can see two solutions. Either like my patch or somehow allow bridge to know
> more MAC addressses per port (maybe netdev can be changed to know more then
> one MAC address).
>
> Any thoughts?
The netdev struct already supports having a
From: Jiri Pirko
Date: Thu, 19 Mar 2009 09:44:45 +0100
> Yes I was looking at this thing yesterday (uc_list). But this list serves
> to different purpose. Do you think that it will be correct to use it for
> this? I
> would maybe like to make a new list similar to this for our purpose
> (say add
From: Li Yang
Date: Mon, 23 Mar 2009 15:59:24 +0800
> Any comment about this? Is it possible to be included in 2.6.29?
Patience please? I reviewed and applied more than 80 patches
yesterday, maybe I'll get to your's after I recover from that.
Your patch is in the queue at:
http://pat
From: Li Yang
Date: Mon, 23 Mar 2009 16:15:34 +0800
> I was wondering if this one failed to get your attention.
yeah, happens all the time
___
Bridge mailing list
Bridge@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/bri
From: Stephen Hemminger
Date: Mon, 23 Mar 2009 08:51:22 -0700
> That ensures big enough header for locally generated packets, but
> any drivers that need bigger headroom still must handle bridged packets
> that come in with smaller space. When bridging packets, the skb comes
> from the allocation
From: Stephen Hemminger
Date: Mon, 23 Mar 2009 15:45:17 -0700
> So you dynamically compute the additional space but if the space was
> an awkward size, could it cause driver to breaks alignment assumptions?
Yes, you'd need to 16-byte align or something like that.
> And you didn't fixup the skb
From: Li Yang
Date: Fri, 20 Mar 2009 17:04:29 +0800
> The bridging device used a constant hard_header_len. This will cause
> headroom shortage for ports with additional hardware header. The patch
> makes bridging device to use the maximum value of all ports.
>
> Signed-off-by: Li Yang
Your d
From: Li Yang
Date: Wed, 25 Mar 2009 15:05:20 +0800
> On Wed, Mar 25, 2009 at 2:40 PM, David Miller wrote:
> > From: Li Yang
> > Date: Fri, 20 Mar 2009 17:04:29 +0800
> >
> >> The bridging device used a constant hard_header_len. This will cause
> >> head
From: Li Yang
Date: Wed, 25 Mar 2009 16:43:53 +0800
> Dynamically adjusting is a good idea, but the rx_alloc_extra can only
> go up not the other way down in your code.
That's not a problem.
> Another thought is that if you re-allocate skb here the driver would
> be saved from checking the head
From: Jiri Pirko
Date: Wed, 25 Mar 2009 18:44:05 +0100
> Wed, Mar 25, 2009 at 05:31:53PM CET, fu...@us.ibm.com wrote:
> >Jiri Pirko wrote:
> >
> >>Basically here's what's going on. In every mode, bonding interface uses the
> >>same
> >>mac address for all enslaved devices. Except for mode balan
From: Jiri Pirko
Date: Thu, 26 Mar 2009 16:52:06 +0100
> (resend, updated changelog, hook moved into skb_bond_should_drop,
> skb_bond_should_drop ifdefed)
>
> Hi all.
>
> The problem is described in following bugzilla:
> https://bugzilla.redhat.com/show_bug.cgi?id=487763
...
> This patch solve
From: Patrick McHardy
Date: Fri, 27 Mar 2009 08:53:13 +0100
> David Miller wrote:
> > I don't like the hook, but if that's how it's best done
> > Patrick, please review this.
>
> Me neither, but I don't think this approach can be done without the
&
From: Jiri Pirko
Date: Mon, 13 Apr 2009 10:42:02 +0200
> @@ -210,6 +210,12 @@ struct dev_addr_list
> #define dmi_usersda_users
> #define dmi_gusers da_gusers
>
> +struct hw_addr {
> + struct list_headlist;
> + unsigned char addr[MAX_ADDR_LEN];
> + int
From: Jiri Pirko
Date: Mon, 13 Apr 2009 10:44:08 +0200
> diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
> index a48f5ef..6efc556 100644
> --- a/net/bridge/br_fdb.c
> +++ b/net/bridge/br_fdb.c
...
> +static inline int is_dev_addr(struct net_device *dev, unsigned char *addr)
> +{
Please d
From: Stephen Hemminger
Date: Mon, 13 Apr 2009 07:49:17 -0700
> This lock is unnecessary, use RCU list for read.
> Since all changes are under RTNL mutex, there is no chance
> for conflict on update.
Agreed.
___
Bridge mailing list
Bridge@lists.linux-f
From: Patrick McHardy
Date: Wed, 15 Apr 2009 12:13:57 +0200
> David Miller wrote:
>> From: Eric Dumazet
>> Date: Wed, 15 Apr 2009 11:27:50 +0200
>>
>>> Since you obviously need a write lock here to be sure following
>>> can be done by one cpu only.
>
From: Jiri Pirko
Date: Wed, 15 Apr 2009 10:32:24 +0200
> This patch introduces a new list in struct net_device and brings a set of
> functions to handle the work with device address list. The list is a
> replacement
> for the original dev_addr field and because in some situations there is need
From: Eric Dumazet
Date: Wed, 15 Apr 2009 11:27:50 +0200
> Since you obviously need a write lock here to be sure following
> can be done by one cpu only.
>
> You have same problem all over this patch.
RTNL semaphore is held across all modification operations.
___
From: Patrick McHardy
Date: Wed, 15 Apr 2009 12:41:01 +0200
> Herbert (I think) suggested to make address list updates in softirq
> context a two-step process, where addresses would first be added to
> a temporary list and the final change would be done in process context
> while holding the RTNL
From: Jiri Pirko
Date: Mon, 4 May 2009 13:14:18 +0200
> +static void __hw_addr_del_multiple(struct list_head *to_list,
> +struct list_head *from_list,
> +int addr_len, unsigned char addr_type)
> +{
> + __hw_addr_del_multiple_ii(t
From: Jiri Pirko
Date: Tue, 5 May 2009 14:48:28 +0200
> This patch introduces a new list in struct net_device and brings a set of
> functions to handle the work with device address list. The list is a
> replacement
> for the original dev_addr field and because in some situations there is need
>
From: Stephen Hemminger
Date: Wed, 6 May 2009 12:26:45 -0700
> Won't this all break spanning tree which expects 1:1 relationship
> between address and port.
Indeed, this could be a fundamental issue with this change.
___
Bridge mailing list
Bridge@list
From: Stephen Hemminger
Date: Fri, 8 May 2009 15:38:42 -0700
> Not sure if this is such a good idea since the purpose of this was to fix
> a bonding/bridging interaction, but it breaks STP on bridging.
Thanks for not paying attention... :-/
The Intel folks want to have an address list functiona
From: Stephen Hemminger
Date: Fri, 8 May 2009 16:12:04 -0700
> But the other infrastructure may have same issues (netfilter, etc).
> Just seems like it would be either to have multiple network devices
> so that upper layers could disambiguate easier.
That's quite a heavyweight solution to what i
From: Stephen Hemminger
Date: Fri, 15 May 2009 09:11:58 -0700
> If bridge is configured with no STP and forwarding delay of 0 (which
> is typical for virtualization) then when link starts it will flood all
> packets for the first 20 seconds.
>
> This bug was introduced by a combination of earli
From: Stephen Hemminger
Date: Fri, 15 May 2009 09:10:13 -0700
> Currently the bridge catches all STP packets; even if STP is turned
> off. This prevents other systems (which do have STP turned on)
> from being able to detect loops in the network.
>
> With this patch, if STP is off, then any pac
From: Eric Dumazet
Date: Thu, 28 May 2009 13:41:59 +0200
> Jiri Pirko a écrit :
>> [PATCH net-next] bonding: allow bond in mode balance-alb to work properly in
>> bridge -try4.3
>>
>> (updated)
>> changes v4.2 -> v4.3
>> - memcpy the address always, not just in case it differs from
>> master->
From: Stephen Hemminger
Date: Fri, 24 Jul 2009 08:36:07 -0700
> On Fri, 24 Jul 2009 17:06:32 +0800
> Xiaotian Feng wrote:
>
>> kobject_init_and_add will alloc memory for kobj->name, so in br_add_if
>> error path, simply use kobject_del will not free memory for kobj->name.
>> Fix by using kobjec
From: Arnd Bergmann
Date: Thu, 6 Aug 2009 21:50:28 +
> This is a first prototype of a new interface into the network
> stack, to eventually replace tun/tap and the bridge driver
> in certain virtual machine setups.
I don't know enough to say how good a solution this is for
the problem, but
From: "Fischer, Anna"
Date: Thu, 13 Aug 2009 16:55:16 +
> This patch adds a 'hairpin' (also called 'reflective relay') mode
> port configuration to the Linux Ethernet bridge kernel module.
> A bridge supporting hairpin forwarding mode can send frames back
> out through the port the frame was
From: Patrick McHardy
Date: Thu, 26 Nov 2009 17:26:17 +0100
> Arnd Bergmann wrote:
>> Version 2 description:
>> The patch to iproute2 has not changed, so I'm not including
>> it this time. Patch 4/4 (the netlink interface) is basically
>> unchanged as well but included for completeness.
>>
>> Th
From: Arnd Bergmann
Date: Sat, 28 Nov 2009 00:43:58 +0100
> On Friday 13 November 2009, Stephen Hemminger wrote:
>> Also, macvlan should really being calling netif_receive_skb()
>> not going through another queue/softirq cycle.
>
> I've added a patch for this in my experimental queue now.
> When
From: Stephen Hemminger
Date: Fri, 27 Nov 2009 21:38:24 -0800
> Maybe we should figure out a way for protocols to return new skb in
> netif_receive_skb
> to avoid extra softirq, but avoid stack overflow?
Eric Dumazet and I tried to find ways to handle this, please see the
archives. It's not an
From: Arnd Bergmann
Date: Mon, 14 Dec 2009 13:00:36 +0100
> c) prepare a combined patch for net-next.git, or
This is probably fine.
I'll be taking patches into net-next-2.6 right after Linus
releases 2.6.33-rc1.
___
Bridge mailing list
Bridge@lists.li
From: Arnd Bergmann
Date: Wed, 27 Jan 2010 11:05:15 +0100
> + * skb_dev_set -- assign a buffer to a new device
My english is terrible, but I think this should be
"assign a new device to a buffer".
If you agree, please fix this up when you resubmit patches #1 and #2
along with the fix you alread
From: Arnd Bergmann
Date: Sat, 30 Jan 2010 23:22:15 +0100
> This is the fourth version of the macvtap driver,
> based on the comments I got for the last version
> I got a few days ago. Very few changes:
>
> * release netdev in chardev open function so
> we can destroy it properly.
> * Implemen
From: Stephen Hemminger
Date: Fri, 26 Feb 2010 10:01:02 -0800
> TCP connections are never really bound to device. TCP routing is
> flexible; if packets can get through, it doesn't care.
I think he might be talking about SO_BINDTODEVICE
___
Bridge maili
From: Stephen Hemminger
Date: Fri, 26 Feb 2010 10:30:03 -0800
> On Fri, 26 Feb 2010 10:08:00 -0800 (PST)
> David Miller wrote:
>
>> From: Stephen Hemminger
>> Date: Fri, 26 Feb 2010 10:01:02 -0800
>>
>> > TCP connections are never really bound to devi
From: Eric Dumazet
Date: Wed, 03 Mar 2010 07:09:04 +0100
> Le mardi 02 mars 2010 à 15:32 -0800, Stephen Hemminger a écrit :
>> The shared packet statistics are a potential source of slow down
>> on bridged traffic. Convert to per-cpu array, but only keep those
>> statistics which change per-packe
From: Randy Dunlap
Date: Tue, 02 Mar 2010 09:08:23 -0800
> From: Randy Dunlap
>
> br_multicast calls ip_send_check(), so it should depend on INET.
>
> built-in:
> br_multicast.c:(.text+0x88cf4): undefined reference to `ip_send_check'
>
> or modular:
> ERROR: "ip_send_check" [net/bridge/bridge
From: Ingo Molnar
Date: Thu, 4 Mar 2010 04:18:47 +0100
> I suspect Randy went by the MAINTAINERS entry - you might want to add netdev
> as a second 'L:' line:
>
> ETHERNET BRIDGE
> M: Stephen Hemminger
> L: bridge@lists.linux-foundation.org
> W: http://www.linux-foundation.o
From: Herbert Xu
Date: Sat, 6 Mar 2010 20:20:32 +0800
> On Sat, Mar 06, 2010 at 02:14:09PM +0300, Dan Carpenter wrote:
>> We dereference "port" on the lines immediately before and immediately
>> after the test so port should hopefully never be null here.
>>
>> Signed-off-by: Dan Carpenter
>
>
From: Henrik Kretzschmar
Date: Sat, 13 Mar 2010 22:10:11 +0100
> Linking the kernel fails with the the following error message,
> if CONFIG_BRIDGE_IGMP_SNOOPING is set and CONFIG_INET is not set.
>
> net/built-in.o: In function `br_multicast_alloc_query':
> br_multicast.c:(.text+0x52045): undefi
From: Stephen Hemminger
Date: Tue, 2 Mar 2010 15:32:09 -0800
> The shared packet statistics are a potential source of slow down
> on bridged traffic. Convert to per-cpu array, but only keep those
> statistics which change per-packet.
>
> Signed-off-by: Stephen Hemminger
Applied.
__
From: Herbert Xu
Date: Sat, 20 Mar 2010 19:57:47 +0800
> On Sat, Mar 20, 2010 at 02:20:49PM +0300, Dan Carpenter wrote:
>> We never actually use iph again so this assignment can be removed.
>>
>> Signed-off-by: Dan Carpenter
>
> Acked-by: Herbert Xu
Applied, thanks.
_
From: Cong Wang
Date: Tue, 23 Mar 2010 10:13:43 +0800
> Matt Mackall wrote:
>> Seems like a lot of interface for something to be used by only a
>> couple
>> core drivers. Hopefully Dave has an opinion here.
>>
>
> Yeah, I worry about this too, maybe we can group those methods
> for netpoll toge
From: Cong Wang
Date: Tue, 23 Mar 2010 12:39:35 +0800
> How could you let the bridge know netpoll is not sent to
> the one that doesn't support netpoll during setup? This will
> be complex, I am afraid.
Why does this matter at all?
I told you in another mail that we should do away with
these ca
From: Cong Wang
Date: Tue, 23 Mar 2010 12:47:39 +0800
> Yeah, for bonding case, probably. But for bridge case, I think
> we still need to check all, right?
Why? Who cares?
If it goes out one port and reaches it's destination
the objective has been achieved.
Sending it out N more times achieve
From: Matt Mackall
Date: Mon, 22 Mar 2010 23:51:01 -0500
> On Tue, 2010-03-23 at 12:39 +0800, Cong Wang wrote:
>> Matt Mackall wrote:
>> How could you let the bridge know netpoll is not sent to
>> the one that doesn't support netpoll during setup? This will
>> be complex, I am afraid.
>
> I thou
From: Amerigo Wang
Date: Tue, 27 Apr 2010 03:55:41 -0400
> + if (ndev->priv_flags & IFF_DISABLE_NETPOLL
> + || !ndev->netdev_ops->ndo_poll_controller) {
" ||" goes on first line, not second, and second line needs to be indented
properly so that "!ndev->..." matches up wit
From: Amerigo Wang
Date: Tue, 27 Apr 2010 03:55:56 -0400
> + if (p->dev->priv_flags & IFF_DISABLE_NETPOLL
> + || !p->dev->netdev_ops->ndo_poll_controller)
"||" goes on first line, and indentation on second line is incorrect.
See my comments from patch #1.
From: Amerigo Wang
Date: Tue, 27 Apr 2010 03:56:09 -0400
> + if ((slave->dev->priv_flags & IFF_DISABLE_NETPOLL)
> + || !slave->dev->netdev_ops->ndo_poll_controller)
"|| on first line please, plus fix second line's indentation as per
comments given in patch
From: Matt Mackall
Date: Wed, 05 May 2010 21:05:30 -0500
> On Wed, 2010-05-05 at 04:11 -0400, Amerigo Wang wrote:
>> V5:
>> Fix coding style problems pointed by David.
>
> Aside from my concern about the policy of disabling netpoll on
> bridges/bonds with only partial netpoll support, I don't ha
From: Stephen Hemminger
Date: Mon, 10 May 2010 12:31:08 -0700
> Move code around so that the ifdef for NETPOLL_CONTROLLER don't have to
> show up in main code path. The control functions should be in helpers
> that are only compiled if needed.
>
> Signed-off-by: Stephen Hemminger
Applied.
From: Stephen Hemminger
Date: Mon, 10 May 2010 12:31:09 -0700
> Use one set of macro's for all bridge messages.
>
> Note: can't use netdev_XXX macro's because bridge is purely
> virtual and has no device parent.
>
> Signed-off-by: Stephen Hemminger
Applied.
___
From: Stephen Hemminger
Date: Mon, 10 May 2010 12:31:10 -0700
> The function __br_dnat_complain is basically reimplementing existing
> net_ratelimit.
>
> Signed-off-by: Stephen Hemminger
This code is no longer there after the recent netfilter merges.
___
From: Stephen Hemminger
Date: Mon, 10 May 2010 12:31:11 -0700
> From: Simon Arlott
>
> Links for each port are created in sysfs using the device
> name, but this could be changed after being added to the
> bridge.
>
> As well as being unable to remove interfaces after this
> occurs (because us
From: Flavio Leitner
Date: Thu, 27 May 2010 15:05:45 -0300
> I did the following patch to discard the packet if it was IN_NETPOLL
> and the read_lock() fails, so I could go ahead testing it:
This is disgusting, let's just disallow console output from such
locations. Defer them to a workqueue if
From: Cong Wang
Date: Mon, 07 Jun 2010 17:57:49 +0800
> Hmm, I still feel like this way is ugly, although it may work.
> I guess David doesn't like it either.
Of course I don't like it. :-)
I suspect the locking scheme will need to be changed.
Besides, if we're going to hack this up and do wri
From: Flavio Leitner
Date: Mon, 7 Jun 2010 16:24:52 -0300
> There are some networking drivers that hold a lock in the
> transmit path. Therefore, if a console message is printed
> after that, netconsole will push it through the transmit path,
> resulting in a deadlock.
>
> This patch fixes the
From: Matt Mackall
Date: Mon, 07 Jun 2010 15:21:31 -0500
> Open to suggestions. The locks in question are driver-internal. There
> also may not be any actual recursion taking place:
>
> driver path a takes private lock x
> driver path a attempts printk
> printk calls into netconsole
> netconsole
From: Stephen Hemminger
Date: Thu, 15 Jul 2010 12:21:44 -0700
> On Thu, 15 Jul 2010 22:47:33 +0400
> Kulikov Vasiliy wrote:
>
>> ipv6_skip_exthdr() can return error code that is below zero.
>> 'offset' is unsigned, so it makes no sense.
>> ipv6_skip_exthdr() returns 'int' so we can painlessly c
From: Herbert Xu
Date: Thu, 29 Jul 2010 19:12:31 +0800
> bridge: Fix skb leak when multicast parsing fails on TX
>
> On the bridge TX path we're leaking an skb when br_multicast_rcv
> returns an error.
>
> Reported-by: David Lamparter
> Signed-off-by: Herbert Xu
Applied to net-2.6, thanks!
_
From: Simon Horman
Date: Mon, 23 Aug 2010 12:35:32 +0900
> While looking at using netdev_rx_handler_register for openvswitch Jesse
> Gross suggested that an unlikely() might be worthwhile in that code.
> I'm interested to see if its appropriate for the bridge code.
>
> Cc: Jesse Gross
> Signed-
From: Changli Gao
Date: Fri, 20 Aug 2010 13:03:16 +0800
> nf_bridge_alloc() always reset the skb->nf_bridge, so we should always
> put the old one. skb->nf_bridge->use is initialized in nf_bridge_alloc(),
> so we don't need to initialize it again.
>
> Signed-off-by: Changli Gao
We just memcpy(
From: Bart De Schuymer
Date: Mon, 23 Aug 2010 21:33:48 +0200
> Looks correct to me.
>
> Signed-off-by: Bart De Schuymer
Bart, please do not top post.
> Changli Gao schreef:
>> nf_bridge_alloc() always reset the skb->nf_bridge, so we should always
>> put the old one.
>>
>> Signed-off-by: Chang
From: Stephen Hemminger
Date: Mon, 18 Oct 2010 20:28:58 -0700
> On Mon, 18 Oct 2010 22:09:35 -0400
> Benjamin Poirier wrote:
>
>> Make all frames sent to reserved group MAC addresses (01:80:c2:00:00:00 to
>> 01:80:c2:00:00:0f) be forwarded if STP is disabled. This enables
>> forwarding EAPOL fr
From: Tobias Klauser
Date: Fri, 10 Dec 2010 14:18:04 +0100
> If br_multicast_new_group returns NULL, we would return 0 (no error) to
> the caller of br_multicast_add_group, which is not what we want. Instead
> br_multicast_new_group should return ERR_PTR(-ENOMEM) in this case.
> Also propagate th
From: Changli Gao
Date: Sat, 25 Dec 2010 21:41:30 +0800
> Since nf_bridge_maybe_copy_header() may change the length of skb,
> we should check the length of skb after it to handle the ppoe skbs.
>
> Signed-off-by: Changli Gao
This is really strange.
packet_length() subtracts VLAN_HLEN from the
From: Changli Gao
Date: Mon, 3 Jan 2011 18:44:59 +0800
> On Sat, Jan 1, 2011 at 3:10 AM, David Miller wrote:
>> From: Changli Gao
>> Date: Sat, 25 Dec 2010 21:41:30 +0800
>>
>>> Since nf_bridge_maybe_copy_header() may change the length of skb,
>>> we sho
From: Stephen Hemminger
Date: Mon, 3 Jan 2011 10:15:33 -0800
> On Mon, 03 Jan 2011 09:22:14 -0800 (PST)
> David Miller wrote:
>
>> From: Changli Gao
>> Date: Mon, 3 Jan 2011 18:44:59 +0800
>>
>> > On Sat, Jan 1, 2011 at 3:10 AM, David Miller wrote:
>
From: Changli Gao
Date: Wed, 5 Jan 2011 21:37:28 +0800
> On Tue, Jan 4, 2011 at 4:13 AM, David Miller wrote:
>> From: Stephen Hemminger
>>>
>>> Because PPPOE happens afterwards and is not part the calculation.
>>> The check should be moved until after sk
1 - 100 of 549 matches
Mail list logo
