summaryrefslogtreecommitdiffstats
path: root/security/apparmor/task.c
diff options
context:
space:
mode:
authorColy Li <colyli@suse.de>2019-06-28 19:59:46 +0800
committerJens Axboe <axboe@kernel.dk>2019-06-28 07:39:16 -0600
commita59ff6ccc2bf2e2934b31bbf734f0bc04b5ec78a (patch)
tree9b9d5241775b33d1b188984046f15a19b0da4eb3 /security/apparmor/task.c
parent5c2a634cbfaf1971cb6453fe5f86d83585257790 (diff)
downloadtalos-op-linux-a59ff6ccc2bf2e2934b31bbf734f0bc04b5ec78a.tar.gz
talos-op-linux-a59ff6ccc2bf2e2934b31bbf734f0bc04b5ec78a.zip
bcache: avoid a deadlock in bcache_reboot()
It is quite frequently to observe deadlock in bcache_reboot() happens and hang the system reboot process. The reason is, in bcache_reboot() when calling bch_cache_set_stop() and bcache_device_stop() the mutex bch_register_lock is held. But in the process to stop cache set and bcache device, bch_register_lock will be acquired again. If this mutex is held here, deadlock will happen inside the stopping process. The aftermath of the deadlock is, whole system reboot gets hung. The fix is to avoid holding bch_register_lock for the following loops in bcache_reboot(), list_for_each_entry_safe(c, tc, &bch_cache_sets, list) bch_cache_set_stop(c); list_for_each_entry_safe(dc, tdc, &uncached_devices, list) bcache_device_stop(&dc->disk); A module range variable 'bcache_is_reboot' is added, it sets to true in bcache_reboot(). In register_bcache(), if bcache_is_reboot is checked to be true, reject the registration by returning -EBUSY immediately. Signed-off-by: Coly Li <colyli@suse.de> Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'security/apparmor/task.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud