Messages in this thread | | | Subject | Re: [PATCH] mm, oom: distinguish blockable mode for mmu notifiers | From | Tetsuo Handa <> | Date | Fri, 24 Aug 2018 22:02:23 +0900 |
| |
On 2018/08/24 20:36, Michal Hocko wrote: >> That is, this API seems to be currently used by only out-of-tree users. Since >> we can't check that nobody has memory allocation dependency, I think that >> hmm_invalidate_range_start() should return -EAGAIN if blockable == false for now. > > The code expects that the invalidate_range_end doesn't block if > invalidate_range_start hasn't blocked. That is the reason why the end > callback doesn't have blockable parameter. If this doesn't hold then the > whole scheme is just fragile because those two calls should pair. > That is
More worrisome part in that patch is that I don't know whether using trylock if blockable == false at entry is really sufficient.
. Since those two calls should pair, I think that we need to determine whether we need to return -EAGAIN at start call by evaluating both calls.
Like mn_invl_range_start() involves schedule_delayed_work() which could be blocked on memory allocation under OOM situation, I worry that (currently out-of-tree) users of this API are involving work / recursion. And hmm_release() says that
/* * Drop mirrors_sem so callback can wait on any pending * work that might itself trigger mmu_notifier callback * and thus would deadlock with us. */
and keeps "all operations protected by hmm->mirrors_sem held for write are atomic". This suggests that "some operations protected by hmm->mirrors_sem held for read will sleep (and in the worst case involves memory allocation dependency)".
| |