From c73bbaa4ec3eb225ffe468f80d45724d0496bf03 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Thu, 11 Feb 2016 10:33:31 -0200 Subject: [media] rc-core: don't lock device at rc_register_device() The mutex lock at rc_register_device() was added by commit 08aeb7c9a42a ("[media] rc: add locking to fix register/show race"). It is meant to avoid race issues when trying to open a sysfs file while the RC register didn't complete. Adding a lock there causes troubles, as detected by the Kernel lock debug instrumentation at the Kernel: ====================================================== [ INFO: possible circular locking dependency detected ] 4.5.0-rc3+ #46 Not tainted ------------------------------------------------------- systemd-udevd/2681 is trying to acquire lock: (s_active#171){++++.+}, at: [] kernfs_remove_by_name_ns+0x45/0xa0 but task is already holding lock: (&dev->lock){+.+.+.}, at: [] rc_register_device+0xb2f/0x1450 [rc_core] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&dev->lock){+.+.+.}: [] lock_acquire+0x13d/0x320 [] mutex_lock_nested+0xb6/0x860 [] show_protocols+0x3b/0x3f0 [rc_core] [] dev_attr_show+0x45/0xc0 [] sysfs_kf_seq_show+0x203/0x3c0 [] kernfs_seq_show+0x121/0x1b0 [] seq_read+0x2f1/0x1160 [] kernfs_fop_read+0x321/0x460 [] __vfs_read+0xe0/0x3d0 [] vfs_read+0xde/0x2d0 [] SyS_read+0x111/0x230 [] entry_SYSCALL_64_fastpath+0x16/0x76 -> #0 (s_active#171){++++.+}: [] __lock_acquire+0x4304/0x5990 [] lock_acquire+0x13d/0x320 [] __kernfs_remove+0x58a/0x810 [] kernfs_remove_by_name_ns+0x45/0xa0 [] remove_files.isra.0+0x72/0x190 [] sysfs_remove_group+0x9b/0x150 [] sysfs_remove_groups+0x54/0xa0 [] device_remove_attrs+0xb0/0x140 [] device_del+0x38c/0x6b0 [] rc_register_device+0x8cb/0x1450 [rc_core] [] dvb_usb_remote_init+0x66b/0x14d0 [dvb_usb] [] dvb_usb_device_init+0xf21/0x1860 [dvb_usb] [] dib0700_probe+0x14c/0x410 [dvb_usb_dib0700] [] usb_probe_interface+0x45d/0x940 [] driver_probe_device+0x21a/0xc30 [] __driver_attach+0x121/0x160 [] bus_for_each_dev+0x11f/0x1a0 [] driver_attach+0x3d/0x50 [] bus_add_driver+0x4c9/0x770 [] driver_register+0x18c/0x3b0 [] usb_register_driver+0x1f8/0x440 [] dib0700_driver_init+0x1e/0x1000 [dvb_usb_dib0700] [] do_one_initcall+0x141/0x300 [] do_init_module+0x1d0/0x5ad [] load_module+0x6666/0x9ba0 [] SyS_finit_module+0x108/0x130 [] entry_SYSCALL_64_fastpath+0x16/0x76 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&dev->lock); lock(s_active#171); lock(&dev->lock); lock(s_active#171); *** DEADLOCK *** 3 locks held by systemd-udevd/2681: #0: (&dev->mutex){......}, at: [] __driver_attach+0xa3/0x160 #1: (&dev->mutex){......}, at: [] __driver_attach+0xb1/0x160 #2: (&dev->lock){+.+.+.}, at: [] rc_register_device+0xb2f/0x1450 [rc_core] In this specific case, some error happened during device init, causing IR to be disabled. Let's fix it by adding a var that will tell when the device is initialized. Any calls before that will return a -EINVAL. That should prevent the race issues. Signed-off-by: Mauro Carvalho Chehab --- include/media/rc-core.h | 2 ++ 1 file changed, 2 insertions(+) (limited to 'include') diff --git a/include/media/rc-core.h b/include/media/rc-core.h index f6494709e230..c41dd7018fa8 100644 --- a/include/media/rc-core.h +++ b/include/media/rc-core.h @@ -60,6 +60,7 @@ enum rc_filter_type { /** * struct rc_dev - represents a remote control device * @dev: driver model's view of this device + * @initialized: true if the device init has completed * @sysfs_groups: sysfs attribute groups * @input_name: name of the input child device * @input_phys: physical path to the input child device @@ -121,6 +122,7 @@ enum rc_filter_type { */ struct rc_dev { struct device dev; + bool initialized; const struct attribute_group *sysfs_groups[5]; const char *input_name; const char *input_phys; -- cgit v1.2.3