On Fri 16-08-19 11:31:45, Jason Gunthorpe wrote: > On Fri, Aug 16, 2019 at 02:26:25PM +0200, Michal Hocko wrote: [...] > > I believe I have given some examples when introducing __GFP_NOLOCKDEP. > > Okay, I think that is 7e7844226f10 ("lockdep: allow to disable reclaim > lockup detection") Hmm, sadly the lkml link in the commit is broken. > > Hum. There are no users of __GFP_NOLOCKDEP today?? Could all the false > positives have been fixed??
I would be more than surprised. Those false possitives were usually papered over by using GFP_NOFS. And the original plan was to convert those back to GFP_KERNEL like allocations and use __GFP_NOLOCKDEP. > Keep in mind that this fs_reclaim was reworked away from the hacky > interrupt context flag to a fairly elegant real lock map. I am glad to hear that because that was just too ugly to live. > Based on my read of the commit message, my first reaction would be to > suggest lockdep_set_class() to solve the problem described, ie > different classes for 'inside transaction' and 'outside transaction' > on xfs_refcountbt_init_cursor() No this just turned out to be unmaintainable. The number of lock classes was growing high. I recommend on of the Dave Chinner's rant. Sorry not link handy. > I understood that generally that is the way to handle lockdep false > positives. > > Anyhow, if you are willing to consider that lockdep isn't broken, I > have some ideas on how to make this clearer and increase > coverage. Would you be willing to look at patches on this topic? (not > soon, I have to finish my mmu notifier stuff) I haven't claimed that the lockdep is broken. It just had problems to capture some code paths and generated false positives. I would recommend talking to lockdep maintainers much more than to me because I would have to dive into the code much more to be useful. I can still comment on the MM side of the thing of course if that is helpful. > > > I would like to inject it into the notifier path as this is very > > > difficult for driver authors to discover and know about, but I'm > > > worried about your false positive remark. > > > > > > I think I understand we can use only GFP_ATOMIC in the notifiers, but > > > we need a strategy to handle OOM to guarentee forward progress. > > > > Your example is from the notifier registration IIUC. > > Yes, that is where this commit hit it.. Triggering this under an > actual notifier to get a lockdep report is hard. All you need is to generate a memory pressure. That shouldn't be that hard. -- Michal Hocko SUSE Labs