On Fri, Aug 16, 2019 at 10:10:29AM +0200, Michal Hocko wrote: > On Thu 15-08-19 17:13:23, Jason Gunthorpe wrote: > > On Thu, Aug 15, 2019 at 09:35:26PM +0200, Michal Hocko wrote: > > > > > > The last detail is I'm still unclear what a GFP flags a blockable > > > > invalidate_range_start() should use. Is GFP_KERNEL OK? > > > > > > I hope I will not make this muddy again ;) > > > invalidate_range_start in the blockable mode can use/depend on any sleepable > > > allocation allowed in the context it is called from. > > > > 'in the context is is called from' is the magic phrase, as > > invalidate_range_start is called while holding several different mm > > related locks. I know at least write mmap_sem and i_mmap_rwsem > > (write?) > > > > Can GFP_KERNEL be called while holding those locks? > > i_mmap_rwsem would be problematic because it is taken during the > reclaim. Okay.. So the fs_reclaim debugging does catch errors. Do you have any reference for what a false positive looks like? 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. This is just more bugs to fix :( Jason
