search for: br_ioctl_mutex

The bridge code doesn't need a separate ioctl, mutex it can just use the existing RTNL mechanism. This avoids some races and deadlocks on shutdown. This is for 2.4; a similar mechanism has been in 2.6 for some time. diff -Nru a/net/bridge/br.c b/net/bridge/br.c --- a/net/bridge/br.c 2004-06-21 07:46:49 -07:00 +++ b/net/bridge/br.c 2004-06-21 07:46:49 -07:00 @@ -22,6 +22,7 @@ #include

...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 => 2)...

...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 locks...

...ase SIOCBRADDIF: + case SIOCBRDELIF: if (!capable(CAP_NET_ADMIN)) return -EPERM; dev_load(ifr.ifr_name); diff -Nru a/net/socket.c b/net/socket.c --- a/net/socket.c 2004-05-20 14:46:10 -07:00 +++ b/net/socket.c 2004-05-20 14:46:10 -07:00 @@ -727,9 +727,9 @@ */ static DECLARE_MUTEX(br_ioctl_mutex); -static int (*br_ioctl_hook)(unsigned long arg) = NULL; +static int (*br_ioctl_hook)(unsigned int cmd, unsigned long arg) = NULL; -void brioctl_set(int (*hook)(unsigned long)) +void brioctl_set(int (*hook)(unsigned int, unsigned long)) { down(&br_ioctl_mutex); br_ioctl_hook = hook; @@...

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

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

...d deletion were all within > a couple of milliseconds? > > So I let the system run for a bit longer with the reproducer, and after > ~200 seconds, the kernel crashed and complained that some tasks had > been waiting for too long (more than 143 seconds) trying to get hold of > the br_ioctl_mutex. This was also quite strange to me, since on the > surface it definitely looked like a deadlock, but the strict locking > order as I described previously should prevent any deadlocks from > happening. > > Anyways, I decided to test switching up the lock order, since both the > re...

...f the bridge's creation and deletion were all within a couple of milliseconds? So I let the system run for a bit longer with the reproducer, and after ~200 seconds, the kernel crashed and complained that some tasks had been waiting for too long (more than 143 seconds) trying to get hold of the br_ioctl_mutex. This was also quite strange to me, since on the surface it definitely looked like a deadlock, but the strict locking order as I described previously should prevent any deadlocks from happening. Anyways, I decided to test switching up the lock order, since both the refcnt warning and the task stal...