Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754971AbbFCN2p (ORCPT ); Wed, 3 Jun 2015 09:28:45 -0400 Received: from cantor2.suse.de ([195.135.220.15]:49125 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752888AbbFCN2k (ORCPT ); Wed, 3 Jun 2015 09:28:40 -0400 Date: Wed, 3 Jun 2015 15:28:37 +0200 From: Michal Hocko To: Andrew Morton Cc: linux-mm@kvack.org, Dave Chinner , Neil Brown , Johannes Weiner , Al Viro , Mel Gorman , Rik van Riel , Tetsuo Handa , LKML , linux-fsdevel@vger.kernel.org Subject: Re: [RFC 0/2] mapping_gfp_mask from the page fault path Message-ID: <20150603132837.GB16201@dhcp22.suse.cz> References: <1433163603-13229-1-git-send-email-mhocko@suse.cz> <20150602132241.26fbbc98be71920da8485b73@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150602132241.26fbbc98be71920da8485b73@linux-foundation.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1673 Lines: 34 On Tue 02-06-15 13:22:41, Andrew Morton wrote: > On Mon, 1 Jun 2015 15:00:01 +0200 Michal Hocko 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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/