misc/serio_raw: Avoid circular locking.
PATCH 1/1 misc/serio_raw: Avoid circular locking.
While debugging an unrelated bug in cdc-acm, PROVE_LOCKING found a circular locking dependency between the misc and serio_raw:
<5>[ 4.311231] =======================================================
<5>[ 4.311242] [ INFO: possible circular locking dependency detected ]
<5>[ 4.311251] 3.0.3 #1
<5>[ 4.311257] -------------------------------------------------------
<5>[ 4.311264] X/394 is trying to acquire lock:
<5>[ 4.311273] (serio_raw_mutex){+.+.+.}, at: [<812be42c>] serio_raw_open+0x1b/0xb3
<5>[ 4.311301]
<5>[ 4.311303] but task is already holding lock:
<5>[ 4.311311] (misc_mtx){+.+.+.}, at: [<8120913d>] misc_open+0x25/0x137
<5>[ 4.311331]
<5>[ 4.311333] which lock already depends on the new lock.
<5>[ 4.311337]
<5>[ 4.311343]
<5>[ 4.311345] the existing dependency chain (in reverse order) is:
<5>[ 4.311353]
<5>[ 4.311355] -> #1 (misc_mtx){+.+.+.}:
<5>[ 4.311369] [<8105f177>] lock_acquire+0x8e/0xad
<5>[ 4.311383] [<8138b82d>] __mutex_lock_common+0x33/0x2a6
<5>[ 4.311399] [<8138bb92>] mutex_lock_nested+0x37/0x40
<5>[ 4.311412] [<812093af>] misc_register+0x21/0xee
<5>[ 4.311426] [<812be5cb>] serio_raw_connect+0x107/0x1a0
<5>[ 4.311440] [<812bbb46>] serio_connect_driver+0x25/0x35
<5>[ 4.311454] [<812bc6dc>] serio_rebind_driver+0x15a/0x1dd
<5>[ 4.311466] [<8125b1a0>] dev_attr_store+0x20/0x28
<5>[ 4.311479] [<810ffb7b>] sysfs_write_file+0xc5/0xf0
<5>[ 4.311491] [<810bd048>] vfs_write+0x8f/0x101
<5>[ 4.311501] [<810bd15b>] sys_write+0x40/0x65
<5>[ 4.311510] [<8138d697>] sysenter_do_call+0x12/0x36
<5>[ 4.311520]
<5>[ 4.311522] -> #0 (serio_raw_mutex){+.+.+.}:
<5>[ 4.311534] [<8105eb42>] __lock_acquire+0x92d/0xb92
<5>[ 4.311546] [<8105f177>] lock_acquire+0x8e/0xad
<5>[ 4.311558] [<8138b82d>] __mutex_lock_common+0x33/0x2a6
<5>[ 4.311572] [<8138bad7>] mutex_lock_interruptible_nested+0x37/0x3e
<5>[ 4.311586] [<812be42c>] serio_raw_open+0x1b/0xb3
<5>[ 4.311598] [<812091fb>] misc_open+0xe3/0x137
<5>[ 4.311612] [<810bf952>] chrdev_open+0x171/0x192
<5>[ 4.311625] [<810bb1fc>] __dentry_open+0x162/0x243
<5>[ 4.311635] [<810bb37b>] nameidata_to_filp+0x4a/0x58
<5>[ 4.311644] [<810c6d32>] do_last+0x3ea/0x4b6
<5>[ 4.311653] [<810c8053>] path_openat+0x9a/0x2cf
<5>[ 4.311662] [<810c833c>] do_filp_open+0x26/0x62
<5>[ 4.311671] [<810baf0f>] do_sys_open+0x61/0x10a
<5>[ 4.311682] [<810bb004>] sys_open+0x23/0x2b
<5>[ 4.311695] [<8138d697>] sysenter_do_call+0x12/0x36
<5>[ 4.311709]
<5>[ 4.311711] other info that might help us debug this:
<5>[ 4.311714]
<5>[ 4.311721] Possible unsafe locking scenario:
<5>[ 4.311724]
<5>[ 4.311730] CPU0 CPU1
<5>[ 4.311736] ---- ----
<5>[ 4.311741] lock(misc_mtx);
<5>[ 4.311752] lock(serio_raw_mutex);
<5>[ 4.311764] lock(misc_mtx);
<5>[ 4.311776] lock(serio_raw_mutex);
<5>[ 4.311786]
<5>[ 4.311788] *** DEADLOCK ***
<5>[ 4.311791]
<5>[ 4.311799] 1 lock held by X/394:
<5>[ 4.311805] #0: (misc_mtx){+.+.+.}, at: [<8120913d>] misc_open+0x25/0x137
<5>[ 4.311827]
<5>[ 4.311830] stack backtrace:
<5>[ 4.311839] Pid: 394, comm: X Not tainted 3.0.3 #1
<5>[ 4.311846] Call Trace:
<5>[ 4.311862] [<8105e17a>] print_circular_bug+0x18d/0x19a
<5>[ 4.311877] [<8105eb42>] __lock_acquire+0x92d/0xb92
<5>[ 4.311892] [<8105f177>] lock_acquire+0x8e/0xad
<5>[ 4.311906] [<812be42c>] ? serio_raw_open+0x1b/0xb3
<5>[ 4.311920] [<8138b82d>] __mutex_lock_common+0x33/0x2a6
<5>[ 4.311935] [<812be42c>] ? serio_raw_open+0x1b/0xb3
<5>[ 4.311949] [<8138bad7>] mutex_lock_interruptible_nested+0x37/0x3e
<5>[ 4.311962] [<812be42c>] ? serio_raw_open+0x1b/0xb3
<5>[ 4.311975] [<812be42c>] serio_raw_open+0x1b/0xb3
<5>[ 4.311989] [<812091fb>] misc_open+0xe3/0x137
<5>[ 4.312004] [<810bf952>] chrdev_open+0x171/0x192
<5>[ 4.312017] [<810bb1fc>] __dentry_open+0x162/0x243
<5>[ 4.312019] [<810bb37b>] nameidata_to_filp+0x4a/0x58
<5>[ 4.312019] [<810bf7e1>] ? cdev_put+0x1f/0x1f
<5>[ 4.312019] [<810c6d32>] do_last+0x3ea/0x4b6
<5>[ 4.312019] [<810c8053>] path_openat+0x9a/0x2cf
<5>[ 4.312019] [<8105ee2d>] ? lock_release_non_nested+0x86/0x1d8
<5>[ 4.312019] [<810c833c>] do_filp_open+0x26/0x62
<5>[ 4.312019] [<8138cc4f>] ? _raw_spin_unlock+0x22/0x25
<5>[ 4.312019] [<810d149d>] ? alloc_fd+0xc2/0xcf
<5>[ 4.312019] [<810baf0f>] do_sys_open+0x61/0x10a
<5>[ 4.312019] [<810bd0a6>] ? vfs_write+0xed/0x101
<5>[ 4.312019] [<810bb004>] sys_open+0x23/0x2b
<5>[ 4.312019] [<8138d697>] sysenter_do_call+0x12/0x36This patch rearranges serio_raw_connect so that it takes the mutex once to allocate a device number and open the serio device, drops it to call misc_register, then takes it again to add the serio_raw device to the list.
BUG=chromium-os:21113
TEST=Adhoc: PROVE_LOCKING no longer finds circular locking dependency
---
I think this works, but I'm not familiar enough with the misc and serio subsystems to know if this is completely correct, nor if it is the best way to break the circular dependency. Feedback would be appreciated.
drivers/input/serio/serio_raw.c | 14 +++++++++----- 1 files changed, 9 insertions(+), 5 deletions(-)
drivers/input/serio/serio_raw.c +9 -5
@@ -294,13 +294,13 @@ static int serio_raw_connect(struct serio *serio, struct serio_driver *drv)if (err) goto out_free; -list_add_tail (&serio_raw->node, &serio_raw_list); - serio_raw->dev.minor =PSMOUSE_MINOR ; serio_raw->dev.name = serio_raw->name; serio_raw->dev.parent = &serio->dev; serio_raw->dev.fops = &serio_raw_fops; +mutex_unlock (&serio_raw_mutex); + err =misc_register (&serio_raw->dev);if (err) { serio_raw->dev.minor =MISC_DYNAMIC_MINOR ;
@@ -313,18 +313,22 @@ static int serio_raw_connect(struct serio *serio, struct serio_driver *drv) goto out_close; } +mutex_lock (&serio_raw_mutex); +list_add_tail (&serio_raw->node, &serio_raw_list); +mutex_unlock (&serio_raw_mutex); +printk (KERN_INFO "serio_raw: raw access enabled on %s (%s, minor %d)\n" , serio->phys, serio_raw->name, serio_raw->dev.minor); - goto out; +return 0 ; out_close: +mutex_lock (&serio_raw_mutex);serio_close (serio); -list_del_init (&serio_raw->node); out_free:serio_set_drvdata (serio,NULL ); +mutex_unlock (&serio_raw_mutex);kfree (serio_raw); out: -mutex_unlock (&serio_raw_mutex);return err; }
Signature · 1 line
1.7.3.1
Dmitry Torokhov
maintainerHi Thomas,
Quoted 9 lines · Thomas Tuttle
This patch rearranges
serio_raw_connectso that it takes the mutex once to allocate a device number and open the serio device, drops it to callmisc_register, then takes it again to add theserio_rawdevice to the list.BUG=chromium-os:21113
TEST=Adhoc:PROVE_LOCKINGno longer finds circular locking dependency
Quoted 6 lines
Change-Id I414c5a3d606c28c81e42dcf989e5c55918eb4ea3Signed-off-by Thomas Tuttle <[email protected]>---
I think this works, but I'm not familiar enough with the misc and serio subsystems to know if this is completely correct, nor if it is the best way to break the circular dependency. Feedback would be appreciated.
Thank you for your report; I looked at the driver and (to my embarrassment) is is quite broken and requires a bit more extensive fixing. I'll be posting a few patches shortly and would appreciate if you could look them over and/or test.
Thanks.
Signature · 1 line
Dmitry