summaryrefslogtreecommitdiff
path: root/drivers/uio/uio.c
AgeCommit message (Collapse)AuthorFilesLines
2021-12-29UIO: use default_groups in kobj_typeGreg Kroah-Hartman1-3/+5
There are currently 2 ways to create a set of sysfs files for a kobj_type, through the default_attrs field, and the default_groups field. Move the UIO code to use default_groups field which has been the preferred way since aa30f47cf666 ("kobject: Add support for default attribute groups to kobj_type") so that we can soon get rid of the obsolete default_attrs field. Link: https://lore.kernel.org/r/20211228131319.249324-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-16Merge 5.10-rc4 into char-misc-nextGreg Kroah-Hartman1-4/+6
We need the char/misc fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-09uio: Fix use-after-free in uio_unregister_device()Shin'ichiro Kawasaki1-4/+6
Commit 8fd0e2a6df26 ("uio: free uio id after uio file node is freed") triggered KASAN use-after-free failure at deletion of TCM-user backstores [1]. In uio_unregister_device(), struct uio_device *idev is passed to uio_free_minor() to refer idev->minor. However, before uio_free_minor() call, idev is already freed by uio_device_release() during call to device_unregister(). To avoid reference to idev->minor after idev free, keep idev->minor value in a local variable. Also modify uio_free_minor() argument to receive the value. [1] BUG: KASAN: use-after-free in uio_unregister_device+0x166/0x190 Read of size 4 at addr ffff888105196508 by task targetcli/49158 CPU: 3 PID: 49158 Comm: targetcli Not tainted 5.10.0-rc1 #1 Hardware name: Supermicro Super Server/X10SRL-F, BIOS 2.0 12/17/2015 Call Trace: dump_stack+0xae/0xe5 ? uio_unregister_device+0x166/0x190 print_address_description.constprop.0+0x1c/0x210 ? uio_unregister_device+0x166/0x190 ? uio_unregister_device+0x166/0x190 kasan_report.cold+0x37/0x7c ? kobject_put+0x80/0x410 ? uio_unregister_device+0x166/0x190 uio_unregister_device+0x166/0x190 tcmu_destroy_device+0x1c4/0x280 [target_core_user] ? tcmu_release+0x90/0x90 [target_core_user] ? __mutex_unlock_slowpath+0xd6/0x5d0 target_free_device+0xf3/0x2e0 [target_core_mod] config_item_cleanup+0xea/0x210 configfs_rmdir+0x651/0x860 ? detach_groups.isra.0+0x380/0x380 vfs_rmdir.part.0+0xec/0x3a0 ? __lookup_hash+0x20/0x150 do_rmdir+0x252/0x320 ? do_file_open_root+0x420/0x420 ? strncpy_from_user+0xbc/0x2f0 ? getname_flags.part.0+0x8e/0x450 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f9e2bfc91fb Code: 73 01 c3 48 8b 0d 9d ec 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 54 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 6d ec 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffdd2baafe8 EFLAGS: 00000246 ORIG_RAX: 0000000000000054 RAX: ffffffffffffffda RBX: 00007f9e2beb44a0 RCX: 00007f9e2bfc91fb RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00007f9e1c20be90 RBP: 00007ffdd2bab000 R08: 0000000000000000 R09: 00007f9e2bdf2440 R10: 00007ffdd2baaf37 R11: 0000000000000246 R12: 00000000ffffff9c R13: 000055f9abb7e390 R14: 000055f9abcf9558 R15: 00007f9e2be7a780 Allocated by task 34735: kasan_save_stack+0x1b/0x40 __kasan_kmalloc.constprop.0+0xc2/0xd0 __uio_register_device+0xeb/0xd40 tcmu_configure_device+0x5a0/0xbc0 [target_core_user] target_configure_device+0x12f/0x760 [target_core_mod] target_dev_enable_store+0x32/0x50 [target_core_mod] configfs_write_file+0x2bb/0x450 vfs_write+0x1ce/0x610 ksys_write+0xe9/0x1b0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Freed by task 49158: kasan_save_stack+0x1b/0x40 kasan_set_track+0x1c/0x30 kasan_set_free_info+0x1b/0x30 __kasan_slab_free+0x110/0x150 slab_free_freelist_hook+0x5a/0x170 kfree+0xc6/0x560 device_release+0x9b/0x210 kobject_put+0x13e/0x410 uio_unregister_device+0xf9/0x190 tcmu_destroy_device+0x1c4/0x280 [target_core_user] target_free_device+0xf3/0x2e0 [target_core_mod] config_item_cleanup+0xea/0x210 configfs_rmdir+0x651/0x860 vfs_rmdir.part.0+0xec/0x3a0 do_rmdir+0x252/0x320 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 The buggy address belongs to the object at ffff888105196000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 1288 bytes inside of 2048-byte region [ffff888105196000, ffff888105196800) The buggy address belongs to the page: page:0000000098e6ca81 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x105190 head:0000000098e6ca81 order:3 compound_mapcount:0 compound_pincount:0 flags: 0x17ffffc0010200(slab|head) raw: 0017ffffc0010200 dead000000000100 dead000000000122 ffff888100043040 raw: 0000000000000000 0000000000080008 00000001ffffffff ffff88810eb55c01 page dumped because: kasan: bad access detected page->mem_cgroup:ffff88810eb55c01 Memory state around the buggy address: ffff888105196400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888105196480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888105196500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888105196580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888105196600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb Fixes: 8fd0e2a6df26 ("uio: free uio id after uio file node is freed") Cc: stable <stable@vger.kernel.org> Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com> Link: https://lore.kernel.org/r/20201102122819.2346270-1-shinichiro.kawasaki@wdc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-09uio: fix some kernel-doc markupsMauro Carvalho Chehab1-2/+2
The definitions for (devm_)uio_register_device should be at the header file, as the macros are there. The ones inside uio.c refer, instead, to __(devm_)uio_register_device. Update them and add new kernel-doc markups for the macros. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/82ab7b68d271aeda7396e369ff8a629491b9d628.1603469755.git.mchehab+huawei@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-17uio: free uio id after uio file node is freedLang Dai1-2/+2
uio_register_device() do two things. 1) get an uio id from a global pool, e.g. the id is <A> 2) create file nodes like /sys/class/uio/uio<A> uio_unregister_device() do two things. 1) free the uio id <A> and return it to the global pool 2) free the file node /sys/class/uio/uio<A> There is a situation is that one worker is calling uio_unregister_device(), and another worker is calling uio_register_device(). If the two workers are X and Y, they go as below sequence, 1) X free the uio id <AAA> 2) Y get an uio id <AAA> 3) Y create file node /sys/class/uio/uio<AAA> 4) X free the file note /sys/class/uio/uio<AAA> Then it will failed at the 3rd step and cause the phenomenon we saw as it is creating a duplicated file node. Failure reports as follows: sysfs: cannot create duplicate filename '/class/uio/uio10' Call Trace: sysfs_do_create_link_sd.isra.2+0x9e/0xb0 sysfs_create_link+0x25/0x40 device_add+0x2c4/0x640 __uio_register_device+0x1c5/0x576 [uio] adf_uio_init_bundle_dev+0x231/0x280 [intel_qat] adf_uio_register+0x1c0/0x340 [intel_qat] adf_dev_start+0x202/0x370 [intel_qat] adf_dev_start_async+0x40/0xa0 [intel_qat] process_one_work+0x14d/0x410 worker_thread+0x4b/0x460 kthread+0x105/0x140 ? process_one_work+0x410/0x410 ? kthread_bind+0x40/0x40 ret_from_fork+0x1f/0x40 Code: 85 c0 48 89 c3 74 12 b9 00 10 00 00 48 89 c2 31 f6 4c 89 ef e8 ec c4 ff ff 4c 89 e2 48 89 de 48 c7 c7 e8 b4 ee b4 e8 6a d4 d7 ff <0f> 0b 48 89 df e8 20 fa f3 ff 5b 41 5c 41 5d 5d c3 66 0f 1f 84 ---[ end trace a7531c1ed5269e84 ]--- c6xxvf b002:00:00.0: Failed to register UIO devices c6xxvf b002:00:00.0: Failed to register UIO devices Signed-off-by: Lang Dai <lang.dai@intel.com> Link: https://lore.kernel.org/r/1600054002-17722-1-git-send-email-lang.dai@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-28drivers: uio: remove redundant assignment to variable retvalColin Ian King1-1/+1
The variable retval is being initialized with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20200425124448.139532-1-colin.king@canonical.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-18uio: add resource managed devm_uio_register_device() functionAlexandru Ardelean1-0/+38
This change adds a resource managed equivalent of uio_register_device(). Not adding devm_uio_unregister_device(), since the intent is to discourage it's usage. Having such a function may allow some bad driver designs. Most users of devm_*register*() functions rarely use the unregister equivalents. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20200306161853.25368-1-alexandru.ardelean@analog.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-31driver: uio: fix possible use-after-free in __uio_register_deviceLiu Jian1-2/+4
In uio_dev_add_attributes() error handing case, idev is used after device_unregister(), in which 'idev' has been released, touch idev cause use-after-free. Fixes: a93e7b331568 ("uio: Prevent device destruction while fds are open") Signed-off-by: Liu Jian <liujian56@huawei.com> Reviewed-by: Hamish Martin <hamish.martin@alliedtelesis.co.nz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-31driver: uio: fix possible memory leak in __uio_register_deviceLiu Jian1-1/+3
'idev' is malloced in __uio_register_device() and leak free it before leaving from the uio_get_minor() error handing case, it will cause memory leak. Fixes: a93e7b331568 ("uio: Prevent device destruction while fds are open") Signed-off-by: Liu Jian <liujian56@huawei.com> Reviewed-by: Hamish Martin <hamish.martin@alliedtelesis.co.nz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-22uio: remove redundant checkChengguang Xu1-2/+2
It is not necessary to check idev->info several times under mutex lock, so just remove redundant check. Signed-off-by: Chengguang Xu <cgxu519@gmx.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-22uio: fix potential memory leak in error caseChengguang Xu1-1/+1
Should jump to lable err_infoopen when idev->info is NULL in uio_open(). Signed-off-by: Chengguang Xu <cgxu519@gmx.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-11-27uio: dismiss waiters on device unregistrationZhaolong Zhang1-8/+11
When the device is unregistered, it should wake up the blocking waiters. Otherwise, they will sleep forever. Signed-off-by: Zhaolong Zhang <zhangzl2013@126.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-11-11uio: Fix an Oops on loadDan Carpenter1-2/+5
I was trying to solve a double free but I introduced a more serious NULL dereference bug. The problem is that if there is an IRQ which triggers immediately, then we need "info->uio_dev" but it's not set yet. This patch puts the original initialization back to how it was and just sets info->uio_dev to NULL on the error path so it should solve both the Oops and the double free. Fixes: f019f07ecf6a ("uio: potential double frees if __uio_register_device() fails") Reported-by: Mathias Thore <Mathias.Thore@infinera.com> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: stable <stable@vger.kernel.org> Tested-by: Mathias Thore <Mathias.Thore@infinera.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-10-03uio: make symbol 'uio_class_registered' staticWei Yongjun1-1/+1
Fixes the following sparse warning: drivers/uio/uio.c:277:6: warning: symbol 'uio_class_registered' was not declared. Should it be static? Fixes: ae61cf5b9913 ("uio: ensure class is registered before devices") Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-25uio: introduce UIO_MEM_IOVAStephen Hemminger1-11/+13
Introduce the concept of mapping physical memory locations that are normal memory. The new type UIO_MEM_IOVA are similar to existing UIO_MEM_PHYS but the backing memory is not marked as uncached. Also, indent related switch to the currently used style. Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-12uio: convert to vm_fault_tSouptick Joarder1-1/+1
As part of commit 9b85e95a3080 ("uio: Change return type to vm_fault_t") in 4.19-rc1, this conversion was missed. Now converted 'ret' to vm_fault_t type. Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-12uio: ensure class is registered before devicesAlexandre Belloni1-0/+9
When both uio and the uio drivers are built in the kernel, it is possible for a driver to register devices before the uio class is registered. This may result in a NULL pointer dereference later on in get_device_parent() when accessing the class glue_dirs spinlock. The trace looks like that: Unable to handle kernel NULL pointer dereference at virtual address 00000140 [...] [<ffff0000089cc234>] _raw_spin_lock+0x14/0x48 [<ffff0000084f56bc>] device_add+0x154/0x6a0 [<ffff0000084f5e48>] device_create_groups_vargs+0x120/0x128 [<ffff0000084f5edc>] device_create+0x54/0x60 [<ffff0000086e72c0>] __uio_register_device+0x120/0x4a8 [<ffff000008528b7c>] jaguar2_pci_probe+0x2d4/0x558 [<ffff0000083fc18c>] local_pci_probe+0x3c/0xb8 [<ffff0000083fd81c>] pci_device_probe+0x11c/0x180 [<ffff0000084f88bc>] driver_probe_device+0x22c/0x2d8 [<ffff0000084f8a24>] __driver_attach+0xbc/0xc0 [<ffff0000084f69fc>] bus_for_each_dev+0x4c/0x98 [<ffff0000084f81b8>] driver_attach+0x20/0x28 [<ffff0000084f7d08>] bus_add_driver+0x1b8/0x228 [<ffff0000084f93c0>] driver_register+0x60/0xf8 [<ffff0000083fb918>] __pci_register_driver+0x40/0x48 Return EPROBE_DEFER in that case so the driver can register the device later. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-19Merge tag 'char-misc-4.19-rc1' of ↵Linus Torvalds1-6/+2
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull UIO fix from Greg KH: "Here is a single UIO fix that I forgot to send before 4.18-final came out. It reverts a UIO patch that went in the 4.18 development window that was causing problems. This patch has been in linux-next for a while with no problems, I just forgot to send it earlier, or as part of the larger char/misc patch series from yesterday, my fault" * tag 'char-misc-4.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: Revert "uio: use request_threaded_irq instead"
2018-08-12Revert "uio: use request_threaded_irq instead"Xiubo Li1-6/+2
Since mutex lock in irq hanler is useless currently, here will remove it together with it. This reverts commit 9421e45f5ff3d558cf8b75a8cc0824530caf3453. Reported-by: james.r.harris@intel.com CC: Ahsan Atta <ahsan.atta@intel.com> Signed-off-by: Xiubo Li <xiubli@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-02uio: potential double frees if __uio_register_device() failsDan Carpenter1-2/+1
The uio_unregister_device() function assumes that if "info->uio_dev" is non-NULL that means "info" is fully allocated. Setting info->uio_de has to be the last thing in the function. In the current code, if request_threaded_irq() fails then we return with info->uio_dev set to non-NULL but info is not fully allocated and it can lead to double frees. Fixes: beafc54c4e2f ("UIO: Add the User IO core code") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-02uio: fix possible circular locking dependencyXiubo Li1-10/+6
The call trace: XXX/1910 is trying to acquire lock: (&mm->mmap_sem){++++++}, at: [<ffffffff97008c87>] might_fault+0x57/0xb0 but task is already holding lock: (&idev->info_lock){+.+...}, at: [<ffffffffc0638a06>] uio_write+0x46/0x130 [uio] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&idev->info_lock){+.+...}: [<ffffffff96f31fc9>] lock_acquire+0x99/0x1e0 [<ffffffff975edad3>] mutex_lock_nested+0x93/0x410 [<ffffffffc063873d>] uio_mmap+0x2d/0x170 [uio] [<ffffffff97016b58>] mmap_region+0x428/0x650 [<ffffffff97017138>] do_mmap+0x3b8/0x4e0 [<ffffffff96ffaba3>] vm_mmap_pgoff+0xd3/0x120 [<ffffffff97015261>] SyS_mmap_pgoff+0x1f1/0x270 [<ffffffff96e387c2>] SyS_mmap+0x22/0x30 [<ffffffff975ff315>] system_call_fastpath+0x1c/0x21 -> #0 (&mm->mmap_sem){++++++}: [<ffffffff96f30e9c>] __lock_acquire+0xdac/0x15f0 [<ffffffff96f31fc9>] lock_acquire+0x99/0x1e0 [<ffffffff97008cb4>] might_fault+0x84/0xb0 [<ffffffffc0638a74>] uio_write+0xb4/0x130 [uio] [<ffffffff9706ffa3>] vfs_write+0xc3/0x1f0 [<ffffffff97070e2a>] SyS_write+0x8a/0x100 [<ffffffff975ff315>] system_call_fastpath+0x1c/0x21 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&idev->info_lock); lock(&mm->mmap_sem); lock(&idev->info_lock); lock(&mm->mmap_sem); *** DEADLOCK *** 1 lock held by XXX/1910: #0: (&idev->info_lock){+.+...}, at: [<ffffffffc0638a06>] uio_write+0x46/0x130 [uio] stack backtrace: CPU: 0 PID: 1910 Comm: XXX Kdump: loaded Not tainted #1 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017 Call Trace: [<ffffffff975e9211>] dump_stack+0x19/0x1b [<ffffffff975e260a>] print_circular_bug+0x1f9/0x207 [<ffffffff96f2f6a7>] check_prevs_add+0x957/0x960 [<ffffffff96f30e9c>] __lock_acquire+0xdac/0x15f0 [<ffffffff96f2fb19>] ? mark_held_locks+0xb9/0x140 [<ffffffff96f31fc9>] lock_acquire+0x99/0x1e0 [<ffffffff97008c87>] ? might_fault+0x57/0xb0 [<ffffffff97008cb4>] might_fault+0x84/0xb0 [<ffffffff97008c87>] ? might_fault+0x57/0xb0 [<ffffffffc0638a74>] uio_write+0xb4/0x130 [uio] [<ffffffff9706ffa3>] vfs_write+0xc3/0x1f0 [<ffffffff9709349c>] ? fget_light+0xfc/0x510 [<ffffffff97070e2a>] SyS_write+0x8a/0x100 [<ffffffff975ff315>] system_call_fastpath+0x1c/0x21 Signed-off-by: Xiubo Li <xiubli@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-07-21uio: fix wrong return value from uio_mmap()Hailong Liu1-1/+1
uio_mmap has multiple fail paths to set return value to nonzero then goto out. However, it always returns *0* from the *out* at end, and this will mislead callers who check the return value of this function. Fixes: 57c5f4df0a5a0ee ("uio: fix crash after the device is unregistered") CC: Xiubo Li <xiubli@redhat.com> Signed-off-by: Hailong Liu <liu.hailong6@zte.com.cn> Cc: stable <stable@vger.kernel.org> Signed-off-by: Jiang Biao <jiang.biao2@zte.com.cn> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-07-21uio: add SPDX license tagStephen Hemminger1-2/+1
Replace short statement in comment with proper SPDX license tag. Signed-off-by: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-07-07uio: fix crash after the device is unregisteredXiubo Li1-16/+88
For the target_core_user use case, after the device is unregistered it maybe still opened in user space, then the kernel will crash, like: [ 251.163692] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 [ 251.163820] IP: [<ffffffffc0736213>] show_name+0x23/0x40 [uio] [ 251.163965] PGD 8000000062694067 PUD 62696067 PMD 0 [ 251.164097] Oops: 0000 [#1] SMP ... [ 251.165605] e1000 mptscsih mptbase drm_panel_orientation_quirks dm_mirror dm_region_hash dm_log dm_mod [ 251.166014] CPU: 0 PID: 13380 Comm: tcmu-runner Kdump: loaded Not tainted 3.10.0-916.el7.test.x86_64 #1 [ 251.166381] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017 [ 251.166747] task: ffff971eb91db0c0 ti: ffff971e9e384000 task.ti: ffff971e9e384000 [ 251.167137] RIP: 0010:[<ffffffffc0736213>] [<ffffffffc0736213>] show_name+0x23/0x40 [uio] [ 251.167563] RSP: 0018:ffff971e9e387dc8 EFLAGS: 00010282 [ 251.167978] RAX: 0000000000000000 RBX: ffff971e9e3f8000 RCX: ffff971eb8368d98 [ 251.168408] RDX: ffff971e9e3f8000 RSI: ffffffffc0738084 RDI: ffff971e9e3f8000 [ 251.168856] RBP: ffff971e9e387dd0 R08: ffff971eb8bc0018 R09: 0000000000000000 [ 251.169296] R10: 0000000000001000 R11: ffffffffa09d444d R12: ffffffffa1076e80 [ 251.169750] R13: ffff971e9e387f18 R14: 0000000000000001 R15: ffff971e9cfb1c80 [ 251.170213] FS: 00007ff37d175880(0000) GS:ffff971ebb600000(0000) knlGS:0000000000000000 [ 251.170693] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 251.171248] CR2: 0000000000000008 CR3: 00000000001f6000 CR4: 00000000003607f0 [ 251.172071] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 251.172640] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 251.173236] Call Trace: [ 251.173789] [<ffffffffa0c9b2d3>] dev_attr_show+0x23/0x60 [ 251.174356] [<ffffffffa0f561b2>] ? mutex_lock+0x12/0x2f [ 251.174892] [<ffffffffa0ac6d9f>] sysfs_kf_seq_show+0xcf/0x1f0 [ 251.175433] [<ffffffffa0ac54e6>] kernfs_seq_show+0x26/0x30 [ 251.175981] [<ffffffffa0a63be0>] seq_read+0x110/0x3f0 [ 251.176609] [<ffffffffa0ac5d45>] kernfs_fop_read+0xf5/0x160 [ 251.177158] [<ffffffffa0a3d3af>] vfs_read+0x9f/0x170 [ 251.177707] [<ffffffffa0a3e27f>] SyS_read+0x7f/0xf0 [ 251.178268] [<ffffffffa0f648af>] system_call_fastpath+0x1c/0x21 [ 251.178823] Code: 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 53 48 89 d3 e8 7e 96 56 e0 48 8b 80 d8 02 00 00 48 89 df 48 c7 c6 84 80 73 c0 <48> 8b 50 08 31 c0 e8 e2 67 44 e0 5b 48 98 5d c3 0f 1f 00 66 2e [ 251.180115] RIP [<ffffffffc0736213>] show_name+0x23/0x40 [uio] [ 251.180820] RSP <ffff971e9e387dc8> [ 251.181473] CR2: 0000000000000008 CC: Hamish Martin <hamish.martin@alliedtelesis.co.nz> CC: Mike Christie <mchristi@redhat.com> Reviewed-by: Hamish Martin <hamish.martin@alliedtelesis.co.nz> Signed-off-by: Xiubo Li <xiubli@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-07-07uio: change to use the mutex lock instead of the spin lockXiubo Li1-19/+13
We are hitting a regression with the following commit: commit a93e7b331568227500186a465fee3c2cb5dffd1f Author: Hamish Martin <hamish.martin@alliedtelesis.co.nz> Date: Mon May 14 13:32:23 2018 +1200 uio: Prevent device destruction while fds are open The problem is the addition of spin_lock_irqsave in uio_write. This leads to hitting uio_write -> copy_from_user -> _copy_from_user -> might_fault and the logs filling up with sleeping warnings. I also noticed some uio drivers allocate memory, sleep, grab mutexes from callouts like open() and release and uio is now doing spin_lock_irqsave while calling them. Reported-by: Mike Christie <mchristi@redhat.com> CC: Hamish Martin <hamish.martin@alliedtelesis.co.nz> Reviewed-by: Hamish Martin <hamish.martin@alliedtelesis.co.nz> Signed-off-by: Xiubo Li <xiubli@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-07-07uio: use request_threaded_irq insteadXiubo Li1-2/+3
Prepraing for changing to use mutex lock. Signed-off-by: Xiubo Li <xiubli@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-14uio: Prevent device destruction while fds are openHamish Martin1-26/+72
Prevent destruction of a uio_device while user space apps hold open file descriptors to that device. Further, access to the 'info' member of the struct uio_device is protected by spinlock. This is to ensure stale pointers to data not under control of the UIO subsystem are not dereferenced. Signed-off-by: Hamish Martin <hamish.martin@alliedtelesis.co.nz> Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-14uio: Reduce return paths from uio_write()Hamish Martin1-8/+17
Drive all return paths for uio_write() through a single block at the end of the function. Signed-off-by: Hamish Martin <hamish.martin@alliedtelesis.co.nz> Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-04-23uio: Change return type to vm_fault_tSouptick Joarder1-1/+1
Use new return type vm_fault_t for fault handler in struct vm_operations_struct. For now, this is just documenting that the function returns a VM_ FAULT value rather than an errno. Once all inst ances are converted, vm_fault_t will become a di stinct type. Reference - 1c8f422059ae ("mm: change return type to vm_fault_t") Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com> Reviewed-by: Matthew Wilcox <mawilcox@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-02-12vfs: do bulk POLL* -> EPOLL* replacementLinus Torvalds1-1/+1
This is the mindless scripted replacement of kernel use of POLL* variables as described by Al, done by this script: for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'` for f in $L; do sed -i "-es/^\([^\"]*\)\(\<POLL$V\>\)/\\1E\\2/" $f; done done with de-mangling cleanups yet to come. NOTE! On almost all architectures, the EPOLL* constants have the same values as the POLL* constants do. But they keyword here is "almost". For various bad reasons they aren't the same, and epoll() doesn't actually work quite correctly in some cases due to this on Sparc et al. The next patch from Al will sort out the final differences, and we should be all done. Scripted-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-11-28the rest of drivers/*: annotate ->poll() instancesAl Viro1-1/+1
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2017-05-17uio: fix incorrect memory leak cleanupSuman Anna1-4/+4
Commit 75f0aef6220d ("uio: fix memory leak") has fixed up some memory leaks during the failure paths of the addition of uio attributes, but still is not correct entirely. A kobject_uevent() failure still needs a kobject_put() and the kobject container structure allocation failure before the kobject_init() doesn't need a kobject_put(). Fix this properly. Fixes: 75f0aef6220d ("uio: fix memory leak") Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-04-08uio: Allow handling of non page-aligned memory regionsMichal Sojka1-1/+1
Since commit b65502879556 ("uio: we cannot mmap unaligned page contents") addresses and sizes of UIO memory regions must be page-aligned. If the address in the BAR register is not page-aligned (which is the case of the mf264 card), the mentioned commit forces the UIO driver to round the address down to the page size. Then, there is no easy way for user-space to learn the offset of the actual memory region within the page, because the offset seen in /sys/class/uio/uio?/maps/map?/offset is calculated from the rounded address and thus it is always zero. Fix that problem by including the offset in struct uio_mem. UIO drivers can set this field and userspace can read its value from /sys/class/uio/uio?/maps/map?/offset. The following commits update the uio_mf264 driver to set this new offs field. Drivers for hardware with page-aligned BARs need not to be modified provided that they initialize struct uio_info (which contains uio_mem) with zeros. Signed-off-by: Michal Sojka <sojkam1@fel.cvut.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-02sched/headers: Prepare to move signal wakeup & sigpending methods from ↵Ingo Molnar1-1/+1
<linux/sched.h> into <linux/sched/signal.h> Fix up affected files that include this signal functionality via sched.h. Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-02-25mm, fs: reduce fault, page_mkwrite, and pfn_mkwrite to take only vmfDave Jiang1-3/+3
->fault(), ->page_mkwrite(), and ->pfn_mkwrite() calls do not need to take a vma and vmf parameter when the vma already resides in vmf. Remove the vma parameter to simplify things. [arnd@arndb.de: fix ARM build] Link: http://lkml.kernel.org/r/20170125223558.1451224-1-arnd@arndb.de Link: http://lkml.kernel.org/r/148521301778.19116.10840599906674778980.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Ross Zwisler <ross.zwisler@linux.intel.com> Cc: Theodore Ts'o <tytso@mit.edu> Cc: Darrick J. Wong <darrick.wong@oracle.com> Cc: Matthew Wilcox <mawilcox@microsoft.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Jan Kara <jack@suse.com> Cc: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-05-02uio: add missing error codesDan Carpenter1-4/+12
My static checker complains that "ret" could be uninitialized at the end, which is true but it's more likely that it would be set to zero. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-10-04uio: fix false positive __might_sleep warning splatMichal Hocko1-0/+1
Andy has reported a __might_sleep warning [ 5174.883617] WARNING: CPU: 0 PID: 1532 at /home/agrover/git/kernel/kernel/sched/core.c:7389 __might_sleep+0x7d/0x90() [ 5174.884407] do not call blocking ops when !TASK_RUNNING; state=1 set at [<ffffffffa02a5821>] uio_read+0x91/0x170 [uio] [ 5174.885198] Modules linked in: tcm_loop target_core_user uio target_core_pscsi target_core_file target_core_iblock iscsi_target_mod target_core_mod uinput fuse nfsv3 nfs_acl nfs lockd grace fscache sunrpc microcode i2c_piix4 virtio_balloon i2c_core xfs libcrc32c crc32c_intel virtio_net virtio_blk [ 5174.887351] CPU: 0 PID: 1532 Comm: tcmu-runner Not tainted 4.2.0-rc7+ [ 5174.887853] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.8.1-20150318_183358- 04/01/2014 [ 5174.888633] ffffffff81a3b870 ffff880045393ca8 ffffffff817afaae 0000000000000000 [ 5174.889224] ffff880045393cf8 ffff880045393ce8 ffffffff8109a846 ffff880045393cd8 [ 5174.889793] ffffffffa02a7150 00000000000002dc 0000000000000000 ffff880045008000 [ 5174.890375] Call Trace: [ 5174.890562] [<ffffffff817afaae>] dump_stack+0x4c/0x65 [ 5174.890938] [<ffffffff8109a846>] warn_slowpath_common+0x86/0xc0 [ 5174.891388] [<ffffffff8109a8c6>] warn_slowpath_fmt+0x46/0x50 [ 5174.891808] [<ffffffffa02a5821>] ? uio_read+0x91/0x170 [uio] [ 5174.892237] [<ffffffffa02a5821>] ? uio_read+0x91/0x170 [uio] [ 5174.892653] [<ffffffff810c584d>] __might_sleep+0x7d/0x90 [ 5174.893055] [<ffffffff811ea023>] __might_fault+0x43/0xa0 [ 5174.893448] [<ffffffff817b31ce>] ? schedule+0x3e/0x90 [ 5174.893820] [<ffffffffa02a58c2>] uio_read+0x132/0x170 [uio] [ 5174.894240] [<ffffffff810cbb80>] ? wake_up_q+0x70/0x70 [ 5174.894620] [<ffffffff81236168>] __vfs_read+0x28/0xe0 [ 5174.894993] [<ffffffff81353233>] ? security_file_permission+0xa3/0xc0 [ 5174.895541] [<ffffffff8123678f>] ? rw_verify_area+0x4f/0xf0 [ 5174.896006] [<ffffffff812368ba>] vfs_read+0x8a/0x140 [ 5174.896391] [<ffffffff817b28f5>] ? __schedule+0x425/0xcc0 [ 5174.896788] [<ffffffff812375d9>] SyS_read+0x49/0xb0 The warning is a false positive because uio_read doesn't depent on TASK_INTERRUPTIBLE after copy_to_user so it is safe to silence the warning by an explicit setting the state to TASK_RUNNING in the path which might call into TASK_RUNNING. Reported-by: Andy Grover <agrover@redhat.com> Signed-off-by: Michal Hocko <mhocko@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-05uio: Destroy uio_idr on module exitJohannes Thumshirn1-0/+1
Destroy uio_idr on module exit, reclaiming the allocated memory. This was detected by the following semantic patch (written by Luis Rodriguez <mcgrof@suse.com>) <SmPL> @ defines_module_init @ declarer name module_init, module_exit; declarer name DEFINE_IDR; identifier init; @@ module_init(init); @ defines_module_exit @ identifier exit; @@ module_exit(exit); @ declares_idr depends on defines_module_init && defines_module_exit @ identifier idr; @@ DEFINE_IDR(idr); @ on_exit_calls_destroy depends on declares_idr && defines_module_exit @ identifier declares_idr.idr, defines_module_exit.exit; @@ exit(void) { ... idr_destroy(&idr); ... } @ missing_module_idr_destroy depends on declares_idr && defines_module_exit && !on_exit_calls_destroy @ identifier declares_idr.idr, defines_module_exit.exit; @@ exit(void) { ... +idr_destroy(&idr); } </SmPL> Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-05-24uio: don't free irq that was not requestedStephen Hemminger1-1/+2
UIO base driver should only free_irq that it has requested. UIO supports drivers without interrupts (irq == 0) or custom handlers. This fixes warnings like: WARNING: CPU: 1 PID: 5478 at kernel/irq/manage.c:1244 __free_irq+0xa9/0x1e0() Trying to free already-free IRQ 0 Signed-off-by: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-20uio: Request/free irq separate from dev lifecycleBrian Russell1-1/+11
Separate irq request/free from the device lifecycle. After device unregister the parent module can call pci_disable_msi. >From the PCI MSI how to: "Before calling this function, a device driver must always call free_irq() on any interrupt for which it previously called request_irq(). Failure to do so results in a BUG_ON(), leaving the device with MSI enabled and thus leaking its vector." So we need to separately free the irq at unregister to allow the device to be kept around in the case of it still having open FDs. Signed-off-by: Brian Russell <brussell@brocade.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-07uio: support memory sizes larger than 32 bitsCristian Stoica1-2/+2
This is a completion to 27a90700a4275c5178b883b65927affdafa5185c The size field is also increased to allow values larger than 32 bits on platforms that have more than 32 bit physical addresses. Signed-off-by: Cristian Stoica <cristian.stoica@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-03uio: Export definition of struct uio_deviceAndy Grover1-12/+0
In order to prevent a O(n) search of the filesystem to link up its uio node with its target configuration, TCMU needs to know the minor number that UIO assigned. Expose the definition of this struct so TCMU can access this field. Signed-off-by: Andy Grover <agrover@redhat.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
2014-06-18Revert "uio: fix vma io range check in mmap"Greg Kroah-Hartman1-1/+1
This reverts commit ddb09754e6c7239e302c7b675df9bbd415f8de5d. Linus objected to this originally, I can see why it might be needed, but given that no one spoke up defending this patch, I'm going to revert it. If you have hardware that requires this change, please speak up in the future and defend the patch. Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Cc: Bin Wang <binw@marvell.com> Cc: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> Cc: Norbert Ciosek <norbertciosek@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-28uio: fix vma io range check in mmapBin Wang1-1/+1
the vma range size is always page size aligned in mmap, while the real io space range may not be page aligned, thus leading to range check failure in the uio_mmap_physical(). for example, in a case of io range size "mem->size == 1KB", and we have (vma->vm_end - vma->vm_start) == 4KB, due to "len" is aligned to page size in do_mmap_pgoff(). now fix this issue by align mem->size to page size in the check. Signed-off-by: Bin Wang <binw@marvell.com> Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-12-20uio: fix devm_request_irq usageAaro Koskinen1-1/+1
Commit e6789cd3dfb553077606ccafeb05e0043f072481 (uio: Simplify uio error path by using devres functions) converted uio to use devm_request_irq(). This introduced a change in behaviour since the IRQ is associated with the parent device instead of the created UIO device. The IRQ will remain active after uio_unregister_device() is called, and some drivers will crash because of this. The patch fixes this. Signed-off-by: Aaro Koskinen <aaro.koskinen@nsn.com> Cc: stable <stable@vger.kernel.org> # 3.13 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-12-02uio: we cannot mmap unaligned page contentsLinus Torvalds1-0/+2
In commit 7314e613d5ff ("Fix a few incorrectly checked [io_]remap_pfn_range() calls") the uio driver started more properly checking the passed-in user mapping arguments against the size of the actual uio driver data. That in turn exposed that some driver authors apparently didn't realize that mmap can only work on a page granularity, and had tried to use it with smaller mappings, with the new size check catching that out. So since it's not just the user mmap() arguments that can be confused, make the uio mmap code also verify that the uio driver has the memory allocated at page boundaries in order for mmap to work. If the device memory isn't properly aligned, we return [ENODEV] The fildes argument refers to a file whose type is not supported by mmap(). as per the open group documentation on mmap. Reported-by: Holger Brunck <holger.brunck@keymile.com> Acked-by: Greg KH <gregkh@linuxfoundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-11-07Merge tag 'char-misc-3.13-rc1' of ↵Linus Torvalds1-20/+18
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull char/misc patches from Greg KH: "Here's the big char/misc driver patchset for 3.13-rc1. Lots of stuff in here, including some new drivers for Intel's "MIC" co-processor devices, and a new eeprom driver. Other things include the driver attribute cleanups, extcon driver updates, hyperv updates, and a raft of other miscellaneous driver fixes. All of these have been in linux-next for a while" * tag 'char-misc-3.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (121 commits) misc: mic: Fixes for randconfig build errors and warnings. tifm: fix error return code in tifm_7xx1_probe() w1-gpio: Use devm_* functions w1-gpio: Detect of_gpio_error for first gpio uio: Pass pointers to virt_to_page(), not integers uio: fix memory leak misc/at24: avoid infinite loop on write() misc/93xx46: avoid infinite loop on write() misc: atmel_pwm: add deferred-probing support mei: wd: host_init propagate error codes from called functions mei: replace stray pr_debug with dev_dbg mei: bus: propagate error code returned by mei_me_cl_by_id mei: mei_cl_link remove duplicated check for open_handle_count mei: print correct device state during unexpected reset mei: nfc: fix memory leak in error path lkdtm: add tests for additional page permissions lkdtm: adjust recursion size to avoid warnings lkdtm: isolate stack corruption test mei: move host_clients_map cleanup to device init mei: me: downgrade two errors to debug level ...
2013-10-30uio: Pass pointers to virt_to_page(), not integersBen Hutchings1-2/+4
Most architectures define virt_to_page() as a macro that casts its argument such that an argument of type unsigned long will be accepted without complaint. However, the proper type is void *, and passing unsigned long results in a warning on MIPS. Compile-tested only. Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-30uio: fix memory leakCong Ding1-6/+10
we have to call kobject_put() to clean up the kobject after function kobject_init(), kobject_add(), or kobject_uevent() is called. Signed-off-by: Cong Ding <dinggnu@gmail.com> Acked-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-29Fix a few incorrectly checked [io_]remap_pfn_range() callsLinus Torvalds1-2/+15
Nico Golde reports a few straggling uses of [io_]remap_pfn_range() that really should use the vm_iomap_memory() helper. This trivially converts two of them to the helper, and comments about why the third one really needs to continue to use remap_pfn_range(), and adds the missing size check. Reported-by: Nico Golde <nico@ngolde.de> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org.
generated by cgit v1.2.3 (git 2.39.0) at 2024-11-21 18:25:53 +0300