similar to: [Bridge] [PATCH 2.4] bridge - eliminate br_ioctl_mutex

Add four new ioctl's for the operations that can't be done through sysfs. The existing bridge ioctl's are multiplexed, and most go through SIOCDEVPRIVATE so they won't work in a mixed 32/64bit environment. The new release of bridge-utils will use these if possible, and fall back to the old interface. diff -Nru a/include/linux/if_bridge.h b/include/linux/if_bridge.h ---

Merge the ioctl stub calls that just end up calling the sub-function to do the actual ioctl. Move br_get_XXX_ifindices into the ioctl file as well where they can be static. diff -Nru a/net/bridge/br_device.c b/net/bridge/br_device.c --- a/net/bridge/br_device.c 2004-05-20 10:51:05 -07:00 +++ b/net/bridge/br_device.c 2004-05-20 10:51:05 -07:00 @@ -19,21 +19,6 @@ #include <asm/uaccess.h>

In the bug reported by Syzbot, certain bridge devices would have a leaked reference created by race conditions in dev_ioctl, specifically, under SIOCBRADDIF or SIOCBRDELIF operations. The reference leak would be shown in the periodic unregister_netdevice call, which throws a warning and cause Syzbot to report a crash. Upon inspection of the logic in dev_ioctl, it seems the reference was introduced

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"

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 received on. Hairpin mode is required to support basic VEPA (Virtual Ethernet Port Aggregator) capabilities. You can find additional information on VEPA

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 received on. Hairpin mode is required to support basic VEPA (Virtual Ethernet Port Aggregator) capabilities. You can find additional information on VEPA

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 received on. Hairpin mode is required to support basic VEPA (Virtual Ethernet Port Aggregator) capabilities. You can find additional information on VEPA

Hi, The attached patches enables the bridge to filter and forward packets according to their IEEE 802.1q headers. The goals behind this change include : - Enable running STP on 802.1q tagged networks. STP packets must be untagged. It isn't obvious how else to enable STP with the current bridge and vlan code. - Add native support for an untagged vlan. Currently an untagged vlan can

Stephen Hemminger, Yes,I use V2.4.17. Which patch can I use? Or can you tell me the reason,so that i can modify my Kernel.I use this kernel at the embeded system. >Haisen.Zhang wrote: > >>shemminger? >> >> I have a problem with brctl application,following is my operations: >> >> vconfig add eth0 3 >> >> brctl addbr br0 >> >>

Hi Ziqi, On 8/19/23 11:10, Ziqi Zhao wrote: > In the bug reported by Syzbot, certain bridge devices would have a > leaked reference created by race conditions in dev_ioctl, specifically, > under SIOCBRADDIF or SIOCBRDELIF operations. The reference leak would How would it leak a reference, could you elaborate? The reference is always taken and always released after the call. > be

Trivial patch to turn off a debug message. It seems some SNMP daemons just periodically trying to look at MII state. Signed-off-by: Stephen Hemminger <shemminger@osdl.org> diff -Nru a/net/bridge/br_ioctl.c b/net/bridge/br_ioctl.c --- a/net/bridge/br_ioctl.c 2004-06-22 16:28:20 -07:00 +++ b/net/bridge/br_ioctl.c 2004-06-22 16:28:20 -07:00 @@ -403,6 +403,6 @@ } - printk(KERN_DEBUG

I noticed that when I type brctl - it does insmod when the bridge module is not loaded. Where can I find the code (in the brctl or libbridge code) which does that? Thanks, Abhijit

Since commit 19e3a9c90c53 ("net: bridge: convert multicast to generic rhashtable") this is not used, so can remove it. Signed-off-by: YueHaibing <yuehaibing at huawei.com> --- net/bridge/br_private.h | 1 - 1 file changed, 1 deletion(-) diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h index 51e4ca54b537..a1f4acfa6994 100644 --- a/net/bridge/br_private.h +++

Hello, syzbot found the following issue on: HEAD commit: 67faabbde36b selftests/bpf: Add missing prototypes for sev.. git tree: bpf-next console+strace: https://syzkaller.appspot.com/x/log.txt?x=1381363b280000 kernel config: https://syzkaller.appspot.com/x/.config?x=5335204dcdecfda dashboard link: https://syzkaller.appspot.com/bug?extid=881d65229ca4f9ae8c84 compiler: gcc (Debian

Instead of issuing (0) statements when !CONFIG_SYSFS which will cause 'warning: ', we'll use inline statements instead. This will effectively do the same thing, but suppress any unnecessary warnings. Cc: Stephen Hemminger <shemminger at vyatta.com> Cc: bridge at lists.linux-foundation.org Cc: netdev at vger.kernel.org Signed-off-by: Lee Jones <lee.jones at linaro.org> ---

This patch checks kmem_cache_create() error and aborts loading module on failure. Cc: Stephen Hemminger <shemminger@linux-foundation.org> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> --- net/bridge/br.c | 7 ++++++- net/bridge/br_fdb.c | 4 +++- net/bridge/br_private.h | 2 +- 3 files changed, 10 insertions(+), 3 deletions(-) Index:

On 15/05/2023 11:50, Johannes Nixdorf wrote: > A malicious actor behind one bridge port may spam the kernel with packets > with a random source MAC address, each of which will create an FDB entry, > each of which is a dynamic allocation in the kernel. > > There are roughly 2^48 different MAC addresses, further limited by the > rhashtable they are stored in to 2^31. Each entry is

On Thu, May 18, 2023 at 07:08:47PM +0300, Nikolay Aleksandrov wrote: > On 18/05/2023 14:33, Ido Schimmel wrote: > > diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c > > index fc17b9fd93e6..d8ab5890cbe6 100644 > > --- a/net/bridge/br_input.c > > +++ b/net/bridge/br_input.c > > @@ -334,6 +334,7 @@ static rx_handler_result_t br_handle_frame(struct sk_buff

A malicious actor behind one bridge port may spam the kernel with packets with a random source MAC address, each of which will create an FDB entry, each of which is a dynamic allocation in the kernel. There are roughly 2^48 different MAC addresses, further limited by the rhashtable they are stored in to 2^31. Each entry is of the type struct net_bridge_fdb_entry, which is currently 128 bytes big.

On Tue, Jun 20, 2023 at 09:55:31AM +0300, Nikolay Aleksandrov wrote: > On 6/19/23 10:14, Johannes Nixdorf wrote: > > +/* Set a FDB flag that implies the entry was not learned, and account > > + * for changes in the learned status. > > + */ > > +static void __fdb_set_flag_not_learned(struct net_bridge *br, > > + struct net_bridge_fdb_entry *fdb, > >