Messages in this thread |  | | Subject | Re: regulator: deadlock vs memory reclaim | From | Dmitry Osipenko <> | Date | Mon, 10 Aug 2020 03:09:58 +0300 |
| |
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.
|  |