diff options
| author | Vineeth Vijayan <[email protected]> | 2021-06-09 09:21:08 +0200 |
|---|---|---|
| committer | Vasily Gorbik <[email protected]> | 2021-06-18 16:41:19 +0200 |
| commit | c749d8c018daf5fba6dfac7b6c5c78b27efd7d65 (patch) | |
| tree | 6cdbb4782c6625585b0893b929c416f03116cba0 /tools/perf/scripts/python/bin/stackcollapse-record | |
| parent | 4aca3ab45d725fe8c4d8be6b67c904c3c3cc6a1d (diff) | |
s390/cio: dont call css_wait_for_slow_path() inside a lock
Currently css_wait_for_slow_path() gets called inside the chp->lock.
The path-verification-loop of slowpath inside this lock could lead to
deadlock as reported by the lockdep validator.
The ccw_device_get_chp_desc() during the instance of a device-set-online
would try to acquire the same 'chp->lock' to read the chp->desc.
The instance of this function can get called from multiple scenario,
like probing or setting-device online manually. This could, in some
corner-cases lead to the deadlock.
lockdep validator reported this as,
CPU0 CPU1
---- ----
lock(&chp->lock);
lock(kn->active#43);
lock(&chp->lock);
lock((wq_completion)cio);
The chp->lock was introduced to serialize the access of struct
channel_path. This lock is not needed for the css_wait_for_slow_path()
function, so invoke the slow-path function outside this lock.
Fixes: b730f3a93395 ("[S390] cio: add lock to struct channel_path")
Cc: <[email protected]>
Reviewed-by: Peter Oberparleiter <[email protected]>
Signed-off-by: Vineeth Vijayan <[email protected]>
Signed-off-by: Vasily Gorbik <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python/bin/stackcollapse-record')
0 files changed, 0 insertions, 0 deletions