search for: br_ioctl

...,6 +22,7 @@ #include <linux/init.h> #include <linux/if_bridge.h> #include <linux/brlock.h> +#include <linux/rtnetlink.h> #include <asm/uaccess.h> #include "br_private.h" @@ -54,15 +55,13 @@ return 0; } -static void __br_clear_ioctl_hook(void) -{ - br_ioctl_hook = NULL; -} - static void __exit br_deinit(void) { unregister_netdevice_notifier(&br_device_notifier); - br_call_ioctl_atomic(__br_clear_ioctl_hook); + + rtnl_lock(); + br_ioctl_hook = NULL; + rtnl_unlock(); br_write_lock_bh(BR_NETPROTO_LOCK); br_handle_frame_hook = NULL; diff -Nr...

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"

...rning and cause Syzbot to report a crash. Upon inspection of the logic in dev_ioctl, it seems the reference was introduced to ensure proper access to the bridge device after rtnl_unlock. and the latter function is necessary to maintain the following lock order in any bridge related ioctl calls: 1) br_ioctl_mutex => 2) rtnl_lock Conceptually, though, br_ioctl_mutex could be considered more specific than rtnl_lock given their usages, hence swapping their order would be a reasonable proposal. This patch changes all related call sites to maintain the reversed order of the two locks: 1) rtnl_lock =&g...

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 "Bridge does not support ioctl 0x%x\n", cmd); + pr_debug("Bridge does not support ioctl 0x%x\n"...

...a0 /* create new bridge device */ +#define SIOCBRDELBR 0x89a1 /* remove bridge device */ +#define SIOCBRADDIF 0x89a2 /* add interface to bridge */ +#define SIOCBRDELIF 0x89a3 /* remove interface from bridge */ + /* Device private ioctl calls */ /* diff -Nru a/net/bridge/br_ioctl.c b/net/bridge/br_ioctl.c --- a/net/bridge/br_ioctl.c 2004-05-20 14:46:10 -07:00 +++ b/net/bridge/br_ioctl.c 2004-05-20 14:46:10 -07:00 @@ -78,13 +78,36 @@ return num; } -int br_dev_ioctl(struct net_device *dev, struct ifreq *rq, int cmd) +static int add_del_if(struct net_bridge *br, int ifind...

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

..._do_ioctl(struct net_device *dev, struct ifreq *rq, int cmd) -{ - unsigned long args[4]; - unsigned long *data; - - if (cmd != SIOCDEVPRIVATE) - return -EOPNOTSUPP; - - data = (unsigned long *)rq->ifr_data; - if (copy_from_user(args, data, 4*sizeof(unsigned long))) - return -EFAULT; - - return br_ioctl_device(dev->priv, args[0], args[1], args[2], args[3]); -} - static struct net_device_stats *br_dev_get_stats(struct net_device *dev) { struct net_bridge *br; @@ -115,7 +100,7 @@ ether_setup(dev); - dev->do_ioctl = br_dev_do_ioctl; + dev->do_ioctl = br_dev_ioctl; dev->get_sta...

...frame(struct net_bridge_po } if (p->state == BR_STATE_FORWARDING || p->state == BR_STATE_LEARNING) { + if (br_vlan_input_frame(skb, &p->vlan)) { + return 1; + } + if (br_should_route_hook) { if (br_should_route_hook(pskb)) return 0; Index: wireless-dev/net/bridge/br_ioctl.c =================================================================== --- wireless-dev.orig/net/bridge/br_ioctl.c +++ wireless-dev/net/bridge/br_ioctl.c @@ -302,6 +302,18 @@ static int old_dev_ioctl(struct net_devi case BRCTL_GET_FDB_ENTRIES: return get_fdb_entries(br, (void __user *)args[1],...

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, all, I am a newbie. i wish to add another ioctl into brctl for doing some manipulations. How do i do so?? Please advise on the steps. Regards, Munro

...er removed or is it really stuck? > logic in dev_ioctl, it seems the reference was introduced to ensure > proper access to the bridge device after rtnl_unlock. and the latter > function is necessary to maintain the following lock order in any > bridge related ioctl calls: > > 1) br_ioctl_mutex => 2) rtnl_lock > > Conceptually, though, br_ioctl_mutex could be considered more specific > than rtnl_lock given their usages, hence swapping their order would be > a reasonable proposal. This patch changes all related call sites to > maintain the reversed order of the two...