user/sven/linux.git/drivers/uio, branch v5.15.185

Drivers: hv: vmbus: Fix rescind handling in uio_hv_generic

2024-09-12T09:07:51Z

commit 6fd28941447bf2c8ca0f26fda612a1cabc41663f upstream. Rescind offer handling relies on rescind callbacks for some of the resources cleanup, if they are registered. It does not unregister vmbus device for the primary channel closure, when callback is registered. Without it, next onoffer does not come, rescind flag remains set and device goes to unusable state. Add logic to unregister vmbus for the primary channel in rescind callback to ensure channel removal and relid release, and to ensure that next onoffer can be received and handled properly. Cc: stable@vger.kernel.org Fixes: ca3cda6fcf1e ("uio_hv_generic: add rescind support") Signed-off-by: Naman Jain Reviewed-by: Saurabh Sengar Link: https://lore.kernel.org/r/20240829071312.1595-3-namjain@linux.microsoft.com Signed-off-by: Greg Kroah-Hartman

uio_hv_generic: Fix kernel NULL pointer dereference in hv_uio_rescind

2024-09-12T09:07:51Z

commit fb1adbd7e50f3d2de56d0a2bb0700e2e819a329e upstream. For primary VM Bus channels, primary_channel pointer is always NULL. This pointer is valid only for the secondary channels. Also, rescind callback is meant for primary channels only. Fix NULL pointer dereference by retrieving the device_obj from the parent for the primary channel. Cc: stable@vger.kernel.org Fixes: ca3cda6fcf1e ("uio_hv_generic: add rescind support") Signed-off-by: Saurabh Sengar Signed-off-by: Naman Jain Link: https://lore.kernel.org/r/20240829071312.1595-2-namjain@linux.microsoft.com Signed-off-by: Greg Kroah-Hartman

uio: Fix use-after-free in uio_open

2024-01-25T22:52:31Z

commit 0c9ae0b8605078eafc3bea053cc78791e97ba2e2 upstream. core-1 core-2 ------------------------------------------------------- uio_unregister_device uio_open idev = idr_find() device_unregister(&idev->dev) put_device(&idev->dev) uio_device_release get_device(&idev->dev) kfree(idev) uio_free_minor(minor) uio_release put_device(&idev->dev) kfree(idev) ------------------------------------------------------- In the core-1 uio_unregister_device(), the device_unregister will kfree idev when the idev->dev kobject ref is 1. But after core-1 device_unregister, put_device and before doing kfree, the core-2 may get_device. Then: 1. After core-1 kfree idev, the core-2 will do use-after-free for idev. 2. When core-2 do uio_release and put_device, the idev will be double freed. To address this issue, we can get idev atomic & inc idev reference with minor_lock. Fixes: 57c5f4df0a5a ("uio: fix crash after the device is unregistered") Cc: stable Signed-off-by: Guanghui Feng Reviewed-by: Baolin Wang Link: https://lore.kernel.org/r/1703152663-59949-1-git-send-email-guanghuifeng@linux.alibaba.com Signed-off-by: Greg Kroah-Hartman

uio: uio_dmem_genirq: Fix deadlock between irq config and handling

2022-12-31T12:14:27Z

[ Upstream commit 118b918018175d9fcd8db667f905012e986cc2c9 ] This fixes a concurrency issue addressed in commit 34cb27528398 ("UIO: Fix concurrency issue"): "In a SMP case there was a race condition issue between Uio_pdrv_genirq_irqcontrol() running on one CPU and irq handler on another CPU. Fix it by spin_locking shared resources access inside irq handler." The implementation of "uio_dmem_genirq" was based on "uio_pdrv_genirq" and it is used in a similar manner to the "uio_pdrv_genirq" driver with respect to interrupt configuration and handling. At the time "uio_dmem_genirq" was merged, both had the same implementation of the 'uio_info' handlers irqcontrol() and handler(), thus, both had the same concurrency issue mentioned by the above commit. However, the above patch was only applied to the "uio_pdrv_genirq" driver. Split out from commit 34cb27528398 ("UIO: Fix concurrency issue"). Fixes: 0a0c3b5a24bd ("Add new uio device for dynamic memory allocation") Signed-off-by: Rafael Mendonca Link: https://lore.kernel.org/r/20220930224100.816175-3-rafaelmendsr@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

uio: uio_dmem_genirq: Fix missing unlock in irq configuration

2022-12-31T12:14:27Z

[ Upstream commit 9de255c461d1b3f0242b3ad1450c3323a3e00b34 ] Commit b74351287d4b ("uio: fix a sleep-in-atomic-context bug in uio_dmem_genirq_irqcontrol()") started calling disable_irq() without holding the spinlock because it can sleep. However, that fix introduced another bug: if interrupt is already disabled and a new disable request comes in, then the spinlock is not unlocked: root@localhost:~# printf '\x00\x00\x00\x00' > /dev/uio0 root@localhost:~# printf '\x00\x00\x00\x00' > /dev/uio0 root@localhost:~# [ 14.851538] BUG: scheduling while atomic: bash/223/0x00000002 [ 14.851991] Modules linked in: uio_dmem_genirq uio myfpga(OE) bochs drm_vram_helper drm_ttm_helper ttm drm_kms_helper drm snd_pcm ppdev joydev psmouse snd_timer snd e1000fb_sys_fops syscopyarea parport sysfillrect soundcore sysimgblt input_leds pcspkr i2c_piix4 serio_raw floppy evbug qemu_fw_cfg mac_hid pata_acpi ip_tables x_tables autofs4 [last unloaded: parport_pc] [ 14.854206] CPU: 0 PID: 223 Comm: bash Tainted: G OE 6.0.0-rc7 #21 [ 14.854786] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 14.855664] Call Trace: [ 14.855861] [ 14.856025] dump_stack_lvl+0x4d/0x67 [ 14.856325] dump_stack+0x14/0x1a [ 14.856583] __schedule_bug.cold+0x4b/0x5c [ 14.856915] __schedule+0xe81/0x13d0 [ 14.857199] ? idr_find+0x13/0x20 [ 14.857456] ? get_work_pool+0x2d/0x50 [ 14.857756] ? __flush_work+0x233/0x280 [ 14.858068] ? __schedule+0xa95/0x13d0 [ 14.858307] ? idr_find+0x13/0x20 [ 14.858519] ? get_work_pool+0x2d/0x50 [ 14.858798] schedule+0x6c/0x100 [ 14.859009] schedule_hrtimeout_range_clock+0xff/0x110 [ 14.859335] ? tty_write_room+0x1f/0x30 [ 14.859598] ? n_tty_poll+0x1ec/0x220 [ 14.859830] ? tty_ldisc_deref+0x1a/0x20 [ 14.860090] schedule_hrtimeout_range+0x17/0x20 [ 14.860373] do_select+0x596/0x840 [ 14.860627] ? __kernel_text_address+0x16/0x50 [ 14.860954] ? poll_freewait+0xb0/0xb0 [ 14.861235] ? poll_freewait+0xb0/0xb0 [ 14.861517] ? rpm_resume+0x49d/0x780 [ 14.861798] ? common_interrupt+0x59/0xa0 [ 14.862127] ? asm_common_interrupt+0x2b/0x40 [ 14.862511] ? __uart_start.isra.0+0x61/0x70 [ 14.862902] ? __check_object_size+0x61/0x280 [ 14.863255] core_sys_select+0x1c6/0x400 [ 14.863575] ? vfs_write+0x1c9/0x3d0 [ 14.863853] ? vfs_write+0x1c9/0x3d0 [ 14.864121] ? _copy_from_user+0x45/0x70 [ 14.864526] do_pselect.constprop.0+0xb3/0xf0 [ 14.864893] ? do_syscall_64+0x6d/0x90 [ 14.865228] ? do_syscall_64+0x6d/0x90 [ 14.865556] __x64_sys_pselect6+0x76/0xa0 [ 14.865906] do_syscall_64+0x60/0x90 [ 14.866214] ? syscall_exit_to_user_mode+0x2a/0x50 [ 14.866640] ? do_syscall_64+0x6d/0x90 [ 14.866972] ? do_syscall_64+0x6d/0x90 [ 14.867286] ? do_syscall_64+0x6d/0x90 [ 14.867626] entry_SYSCALL_64_after_hwframe+0x63/0xcd [...] stripped [ 14.872959] ('myfpga' is a simple 'uio_dmem_genirq' driver I wrote to test this) The implementation of "uio_dmem_genirq" was based on "uio_pdrv_genirq" and it is used in a similar manner to the "uio_pdrv_genirq" driver with respect to interrupt configuration and handling. At the time "uio_dmem_genirq" was introduced, both had the same implementation of the 'uio_info' handlers irqcontrol() and handler(). Then commit 34cb27528398 ("UIO: Fix concurrency issue"), which was only applied to "uio_pdrv_genirq", ended up making them a little different. That commit, among other things, changed disable_irq() to disable_irq_nosync() in the implementation of irqcontrol(). The motivation there was to avoid a deadlock between irqcontrol() and handler(), since it added a spinlock in the irq handler, and disable_irq() waits for the completion of the irq handler. By changing disable_irq() to disable_irq_nosync() in irqcontrol(), we also avoid the sleeping-while-atomic bug that commit b74351287d4b ("uio: fix a sleep-in-atomic-context bug in uio_dmem_genirq_irqcontrol()") was trying to fix. Thus, this fixes the missing unlock in irqcontrol() by importing the implementation of irqcontrol() handler from the "uio_pdrv_genirq" driver. In the end, it reverts commit b74351287d4b ("uio: fix a sleep-in-atomic-context bug in uio_dmem_genirq_irqcontrol()") and change disable_irq() to disable_irq_nosync(). It is worth noting that this still does not address the concurrency issue fixed by commit 34cb27528398 ("UIO: Fix concurrency issue"). It will be addressed separately in the next commits. Split out from commit 34cb27528398 ("UIO: Fix concurrency issue"). Fixes: b74351287d4b ("uio: fix a sleep-in-atomic-context bug in uio_dmem_genirq_irqcontrol()") Signed-off-by: Rafael Mendonca Link: https://lore.kernel.org/r/20220930224100.816175-2-rafaelmendsr@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

uio: Remove leading spaces in Kconfig

2021-05-21T12:52:37Z

Remove leading spaces before tabs in Kconfig file(s) by running the following command: $ find drivers/uio -name 'Kconfig*' | xargs sed -r -i 's/^[ ]+\t/\t/' Signed-off-by: Juerg Haefliger Link: https://lore.kernel.org/r/20210517095837.81783-1-juergh@canonical.com Signed-off-by: Greg Kroah-Hartman

Merge 50f09a3dd587 ("Merge tag 'char-misc-5.13-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc") into char-misc-next

2021-05-21T07:48:31Z

We want the char/misc driver fixes in here as well Signed-off-by: Greg Kroah-Hartman

uio: uio_pci_generic: add memory resource mappings

2021-05-14T11:42:11Z

import memory resources from underlying pci device, thus allowing userspace applications to memory map those resources. without this change, current implementation, does not populate the memory maps and are not shown under the corresponding sysfs uio entry: root@apalis-imx8:~# echo "ad00 0122" > \ /sys/bus/pci/drivers/uio_pci_generic/new_id [ 55.736433] uio_pci_generic 0000:01:00.0: enabling device (0000 -> 0002) root@apalis-imx8:~# ls -lsrt /sys/class/uio/uio0/ 0 -rw-r--r-- 1 root root 4096 Apr 27 18:52 uevent 0 -r--r--r-- 1 root root 4096 Apr 27 18:52 version 0 -r--r--r-- 1 root root 4096 Apr 27 18:52 suppliers 0 lrwxrwxrwx 1 root root 0 Apr 27 18:52 subsystem -> ../../../../../../../../../class/uio 0 drwxr-xr-x 2 root root 0 Apr 27 18:52 power 0 -r--r--r-- 1 root root 4096 Apr 27 18:52 name 0 -r--r--r-- 1 root root 4096 Apr 27 18:52 event 0 lrwxrwxrwx 1 root root 0 Apr 27 18:52 device -> ../../../0000:01:00.0 0 -r--r--r-- 1 root root 4096 Apr 27 18:52 dev 0 -r--r--r-- 1 root root 4096 Apr 27 18:52 consumers root@apalis-imx8:~# with the proposed changed, have following instead: root@apalis-imx8:~# ls -lsrt /sys/class/uio/uio0/ 0 -rw-r--r-- 1 root root 4096 Apr 27 19:06 uevent 0 -r--r--r-- 1 root root 4096 Apr 27 19:06 version 0 -r--r--r-- 1 root root 4096 Apr 27 19:06 suppliers 0 lrwxrwxrwx 1 root root 0 Apr 27 19:06 subsystem -> ../../../../../../../../../class/uio 0 drwxr-xr-x 2 root root 0 Apr 27 19:06 power 0 -r--r--r-- 1 root root 4096 Apr 27 19:06 name 0 drwxr-xr-x 4 root root 0 Apr 27 19:06 maps 0 -r--r--r-- 1 root root 4096 Apr 27 19:06 event 0 lrwxrwxrwx 1 root root 0 Apr 27 19:06 device -> ../../../0000:01:00.0 0 -r--r--r-- 1 root root 4096 Apr 27 19:06 dev 0 -r--r--r-- 1 root root 4096 Apr 27 19:06 consumers root@apalis-imx8:~# root@apalis-imx8:~# ls -lsrt /sys/class/uio/uio0/maps/ 0 drwxr-xr-x 2 root root 0 Apr 27 19:07 map1 0 drwxr-xr-x 2 root root 0 Apr 27 19:07 map0 root@apalis-imx8:~# root@apalis-imx8:~# cat /sys/class/uio/uio0/maps/map1/addr 0x0000000062000000 root@apalis-imx8:~# root@apalis-imx8:~# cat /sys/class/uio/uio0/maps/map1/size 0x0000000000200000 root@apalis-imx8:~# tested on AltaData ARINC 429 MiniPCIE module on imx8qm-apalis-ixora-v1.2 Signed-off-by: Firas Ashkar Link: https://lore.kernel.org/r/20210427201046.4005820-1-firas.ashkar@savoirfairelinux.com Signed-off-by: Greg Kroah-Hartman

uio: uio_aec: Use pci_iounmap instead of iounmap

2021-05-14T11:39:47Z

'pci_iomap()' is used in the probe and 'pci_iounmap()' in the error handling path of the probe. So keep things consistent and use 'pci_iounmap()' also in the remove function. Fixes: 1bafeb378e91 ("uio: add the uio_aec driver") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/f6b2a09a45658e8ef552aa34f0b8615dc1c35838.1620546705.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman

uio_hv_generic: Fix another memory leak in error handling paths

2021-05-14T11:26:04Z

Memory allocated by 'vmbus_alloc_ring()' at the beginning of the probe function is never freed in the error handling path. Add the missing 'vmbus_free_ring()' call. Note that it is already freed in the .remove function. Fixes: cdfa835c6e5e ("uio_hv_generic: defer opening vmbus until first use") Cc: stable Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/0d86027b8eeed8e6360bc3d52bcdb328ff9bdca1.1620544055.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman