lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 10 Aug 2020 03:09:58 +0300 From: Dmitry Osipenko <digetx@...il.com> To: Michał Mirosław <mirq-linux@...e.qmqm.pl>, Liam Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org> Cc: linux-kernel@...r.kernel.org Subject: Re: regulator: deadlock vs memory reclaim 10.08.2020 01:25, Michał Mirosław пишет: > Hi guys, > > Commit f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking") > from Nov 2018 tried to fix possible deadlocks when handling coupled > regulators. Unfortunately it introduced another possible deadlock, > as discovered by lockdep (see below), instead. > > regulator_lock_dependent() starts by taking regulator_list_mutex, The > same mutex covers eg. regulator initialization, including memory allocations > that happen there. This will deadlock when you have filesystem on eg. eMMC > (which uses a regulator to control module voltages) and you register > a new regulator (hotplug a device?) when under memory pressure. > > There is also another problem with regulator_lock_dependent(): all the > w/w rollback stuff is useless: because of the outer lock, there can only > be one contendant doing multiple-lock-grabbing procedure. In this setup, > the procedure cannot detect other processes waiting on > regulator_lock_dependent() and it cannot signal (wound a transaction of) > current holders of locks taken by regulator_lock(). > > Basically, we have a BKL for regulator_enable() and we're using ww_mutex > as a recursive mutex with no deadlock prevention whatsoever. The locks > also seem to cover way to much (eg. initialization even before making the > regulator visible to the system). > > To fix the regulator vs memory reclaim path I tried pushing all allocations > out of protected sections. After doing a few patches, though, I'm not sure > I'm going in the right direction. Your thoughts? IIRC, taking the regulator_list_mutex within regulator_lock_dependent() is needed in order to protect the case of decoupling regulators. Perhaps moving out allocations or making them GFP_NOWAIT should be the easiest solution.
Powered by blists - more mailing lists