On Tue 02-06-15 13:22:41, Andrew Morton wrote: > On Mon, 1 Jun 2015 15:00:01 +0200 Michal Hocko <mhocko@xxxxxxx> wrote: > > > I somehow forgot about these patches. The previous version was > > posted here: http://marc.info/?l=linux-mm&m=142668784122763&w=2. The > > first attempt was broken but even when fixed it seems like ignoring > > mapping_gfp_mask in page_cache_read is too fragile because > > filesystems might use locks in their filemap_fault handlers > > which could trigger recursion problems as pointed out by Dave > > http://marc.info/?l=linux-mm&m=142682332032293&w=2. > > > > The first patch should be straightforward fix to obey mapping_gfp_mask > > when allocating for mapping. It can be applied even without the second > > one. > > I'm not so sure about that. If only [1/2] is applied then those > filesystems which are setting mapping_gfp_mask to GFP_NOFS will now > actually start using GFP_NOFS from within page_cache_read() etc. The > weaker allocation mode might cause problems. They are using the weaker allocation mode in this context already because page_cache_alloc_cold is obeying mapping gfp mask. So all this patch does is to make sure that add_to_page_cache_lru gfp_maks is in sync with other allocations. So I do not see why this would be a problem. Quite opposite if the function was called from a real GFP_NOFS context we could deadlock with the current code. -- 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>