On Fri 09-12-16 06:38:04, Al Viro wrote: > On Fri, Dec 09, 2016 at 07:22:25AM +0100, Michal Hocko wrote: > > > > Easier to handle those in vmalloc() itself. > > > > I think there were some attempts in the past but some of the code paths > > are burried too deep and adding gfp_mask all the way down there seemed > > like a major surgery. > > No need to propagate gfp_mask - the same trick XFS is doing right now can > be done in vmalloc.c in a couple of places and that's it; I'll resurrect the > patches and post them tomorrow after I get some sleep. That would work as an immediate mitigation. No question about that but what I've tried to point out in the reply to Dave is that longerm we shouldn't hide this trickiness inside the vmalloc and rather handle those users who are requesting NOFS/NOIO context from vmalloc. We already have a scope api for NOIO and I want to add the same for NOFS. I believe that much more sane approach is to use the API at those places which really start/stop reclaim recursion dangerous scope (e.g. the transaction context) rather than using GFP_NOFS randomly because this approach has proven to not work properly over years. We have so many place using GFP_NOFS just because nobody bothered to think whether it is needed but it must be safe for sure that it is not funny. -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>