aboutsummaryrefslogtreecommitdiffstats
path: root/net/switchdev/switchdev.c
diff options
context:
space:
mode:
authorGerald Schaefer <[email protected]>2016-04-08 11:23:52 +0000
committerMartin Schwidefsky <[email protected]>2016-04-15 16:01:44 +0000
commit1378a683443753923eb22d01ce322e92a383ba8a (patch)
tree5ba6d2cf4fb1dc1f83cf4a7946ddedfb163cbfe2 /net/switchdev/switchdev.c
parents390/seccomp: include generic seccomp header file (diff)
downloadkernel-1378a683443753923eb22d01ce322e92a383ba8a.tar.gz
kernel-1378a683443753923eb22d01ce322e92a383ba8a.zip
s390/dcssblk: fix possible deadlock in remove vs. per-device attributes
dcssblk_remove_store() holds the dcssblk_devices_sem semaphore while calling device_unregister(), which in turn tries to acquire the kernfs kn->dev_map rwsem for the device sysfs subtree. The same rwsem is also acquired when using the per-device sysfs attributes in the device sub-tree, and the attribute handlers then also acquire the dcssblk_devices_sem. This can lead to a deadlock when removing a DCSS while concurrently reading from / writing to one of its sysfs attributes. The following lockdep warning hinted towards the issue (CPU0 = dcssblk_remove_store, CPU1 = dcssblk_shared_store): [ 76.496047] Possible unsafe locking scenario: [ 76.496054] CPU0 CPU1 [ 76.496059] ---- ---- [ 76.496087] lock(&dcssblk_devices_sem); [ 76.496090] lock(s_active#175); [ 76.496106] lock(&dcssblk_devices_sem); [ 76.496110] lock(s_active#175); [ 76.496115] *** DEADLOCK *** Fix this by releasing the dcssblk_devices_sem semaphore, which only protects internal DCSS data, before calling device_unregister(). Signed-off-by: Gerald Schaefer <[email protected]> Signed-off-by: Martin Schwidefsky <[email protected]>
Diffstat (limited to 'net/switchdev/switchdev.c')
0 files changed, 0 insertions, 0 deletions