On Mon 19-03-18 13:45:02, Kirill A. Shutemov wrote: > On Mon, Mar 19, 2018 at 11:33:36AM +0100, Michal Hocko wrote: > > On Mon 19-03-18 13:14:40, Kirill A. Shutemov wrote: > > > On Mon, Mar 19, 2018 at 10:04:19AM +0100, Michal Hocko wrote: > > > > On Sun 18-03-18 10:22:49, Tetsuo Handa wrote: > > > > > >From f43b8ca61b76f9a19c13f6bf42b27fad9554afc0 Mon Sep 17 00:00:00 2001 > > > > > From: Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> > > > > > Date: Sun, 18 Mar 2018 10:18:01 +0900 > > > > > Subject: [PATCH v2] mm: Warn on lock_page() from reclaim context. > > > > > > > > > > Kirill A. Shutemov noticed that calling lock_page[_killable]() from > > > > > reclaim context might cause deadlock. In order to help finding such > > > > > lock_page[_killable]() users (including out of tree users), this patch > > > > > emits warning messages when CONFIG_PROVE_LOCKING is enabled. > > > > > > > > So how do you ensure that this won't cause false possitives? E.g. do we > > > > ever allocate while holding the page lock and not having the page on the > > > > LRU list? > > > > > > Hm. Do we even have a reason to lock such pages? > > > Probably we do, but I cannot come up with an example. > > > > Page lock is way too obscure to be sure :/ > > Anyway, maybe we want to be more conservative and only warn about LRU > > pages... > > I would rather see what we actually step onto. Sometimes false-positive > warning may bring useful insight. > > Maybe keep in in mm- tree for few cycles? (If it wouldn't blow up > immediately) I would be OK to keep it in mmotm for some time. But I am not yet convinced this is a mainline material yet. Please also note that we have some PF_MEMALLOC (ab)users outside of the MM proper and thy use the flag to break into reserves and I wouldn't be all that surprised if they id lock_page as well. -- Michal Hocko SUSE Labs
