search for: dev_ioctl

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 to ensure proper acces...

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 shown in the periodic unregister_netdevice call, which throws a > warning and...

...: bridge: move bridge ioctls out of .ndo_do_ioctl") unregister_netdevice: waiting for bridge0 to become free. Usage count = 2 leaked reference. __netdev_tracker_alloc include/linux/netdevice.h:4070 [inline] netdev_hold include/linux/netdevice.h:4099 [inline] dev_ifsioc+0xbc0/0xeb0 net/core/dev_ioctl.c:408 dev_ioctl+0x250/0x1090 net/core/dev_ioctl.c:605 sock_do_ioctl+0x15a/0x230 net/socket.c:1215 sock_ioctl+0x1f8/0x680 net/socket.c:1318 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856...

On 8/20/23 01:50, Ziqi Zhao wrote: > On Sat, Aug 19, 2023 at 12:25:15PM +0300, Nikolay Aleksandrov wrote: > Hi Nik, > > Thank you so much for reviewing the patch and getting back to me! > >> IIRC there was no bug, it was a false-positive. The reference is held a bit >> longer but then released, so the device is deleted later. > >> If you reproduced it, is the

On Sat, Aug 19, 2023 at 12:25:15PM +0300, Nikolay Aleksandrov wrote: Hi Nik, Thank you so much for reviewing the patch and getting back to me! > IIRC there was no bug, it was a false-positive. The reference is held a bit > longer but then released, so the device is deleted later. > If you reproduced it, is the device later removed or is it really stuck? I ran the reproducer again

...x1ac0 May 26 09:18:59 servername kernel: [31526.938009] [<ffffffff814039a6>] ? ___sys_recvmsg+0x136/0x2a0 May 26 09:18:59 servername kernel: [31526.938014] [<ffffffff81420455>] ? netdev_run_todo+0x55/0x2f0 May 26 09:18:59 servername kernel: [31526.938020] [<ffffffff8143310f>] ? dev_ioctl+0x19f/0x590 May 26 09:18:59 servername kernel: [31526.938026] [<ffffffff8118e148>] ? kfree+0x118/0x220 May 26 09:18:59 servername kernel: [31526.938033] [<ffffffff811e330a>] ? fsnotify_clear_marks_by_inode+0x2a/0x110 May 26 09:18:59 servername kernel: [31526.938038] [<ffffffff8140...

...8c0c>] virtnet_set_queues+0x9c/0x110 [ 33.534747] [<0000000000619928>] virtnet_set_channels+0x78/0xe0 [ 33.534748] [<00000000006f63ea>] ethtool_set_channels+0x62/0x88 [ 33.534750] [<00000000006f8900>] dev_ethtool+0x10d8/0x1a48 [ 33.534752] [<000000000070c540>] dev_ioctl+0x190/0x510 [ 33.534754] [<00000000006cf2da>] sock_do_ioctl+0x7a/0x90 [ 33.534755] [<00000000006cf840>] sock_ioctl+0x1e8/0x2d0 [ 33.534758] [<00000000002e6c78>] do_vfs_ioctl+0x3a8/0x508 [ 33.534759] [<00000000002e6e7c>] SyS_ioctl+0xa4/0xb8 [ 33.534762] [<00...

This switches virtio to use the DMA API unconditionally. I'm sure it breaks things, but it seems to work on x86 using virtio-pci, with and without Xen, and using both the modern 1.0 variant and the legacy variant. This appears to work on native and Xen x86_64 using both modern and legacy virtio-pci. It also appears to work on arm and arm64. It definitely won't work as-is on s390x, and

This switches virtio to use the DMA API unconditionally. I'm sure it breaks things, but it seems to work on x86 using virtio-pci, with and without Xen, and using both the modern 1.0 variant and the legacy variant. This appears to work on native and Xen x86_64 using both modern and legacy virtio-pci. It also appears to work on arm and arm64. It definitely won't work as-is on s390x, and

...| 20 +-- net/ceph/crush/mapper.c | 2 +- net/ceph/messenger.c | 4 +- net/ceph/mon_client.c | 2 +- net/ceph/osd_client.c | 6 +- net/core/dev.c | 4 +- net/core/dev_ioctl.c | 2 +- net/core/devlink.c | 2 +- net/core/drop_monitor.c | 2 +- net/core/filter.c | 2 +- net/core/pktgen.c | 2 +- net/core/skmsg.c...

...| 20 +-- net/ceph/crush/mapper.c | 2 +- net/ceph/messenger.c | 4 +- net/ceph/mon_client.c | 2 +- net/ceph/osd_client.c | 6 +- net/core/dev.c | 4 +- net/core/dev_ioctl.c | 2 +- net/core/devlink.c | 2 +- net/core/drop_monitor.c | 2 +- net/core/filter.c | 2 +- net/core/pktgen.c | 2 +- net/core/skmsg.c...

...| 20 +-- net/ceph/crush/mapper.c | 2 +- net/ceph/messenger.c | 4 +- net/ceph/mon_client.c | 2 +- net/ceph/osd_client.c | 6 +- net/core/dev.c | 4 +- net/core/dev_ioctl.c | 2 +- net/core/devlink.c | 2 +- net/core/drop_monitor.c | 2 +- net/core/filter.c | 2 +- net/core/pktgen.c | 2 +- net/core/skmsg.c...

...| 20 +-- net/ceph/crush/mapper.c | 2 +- net/ceph/messenger.c | 4 +- net/ceph/mon_client.c | 2 +- net/ceph/osd_client.c | 6 +- net/core/dev.c | 4 +- net/core/dev_ioctl.c | 2 +- net/core/devlink.c | 2 +- net/core/drop_monitor.c | 2 +- net/core/filter.c | 2 +- net/core/pktgen.c | 2 +- net/core/skmsg.c...

...| 20 +-- net/ceph/crush/mapper.c | 2 +- net/ceph/messenger.c | 4 +- net/ceph/mon_client.c | 2 +- net/ceph/osd_client.c | 6 +- net/core/dev.c | 4 +- net/core/dev_ioctl.c | 2 +- net/core/devlink.c | 2 +- net/core/drop_monitor.c | 2 +- net/core/filter.c | 2 +- net/core/pktgen.c | 2 +- net/core/skmsg.c...