From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Piggin Subject: Re: When to use GFP_NOFS rather than GFP_KERNEL? Date: Tue, 23 Mar 2010 00:02:25 +1100 Message-ID: <20100322130225.GN17637@laptop> References: <201003221515.EJD04125.QtFFMOVOLFOJHS@I-love.SAKURA.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org To: Tetsuo Handa Return-path: Received: from cantor.suse.de ([195.135.220.2]:52161 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752767Ab0CVNC3 (ORCPT ); Mon, 22 Mar 2010 09:02:29 -0400 Content-Disposition: inline In-Reply-To: <201003221515.EJD04125.QtFFMOVOLFOJHS@I-love.SAKURA.ne.jp> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, Mar 22, 2010 at 03:15:10PM +0900, Tetsuo Handa wrote: > Hello. > > I want to know whether security_path_*() users need to use GFP_NOFS or not. > I couldn't understand what "Can call down to low-level FS?" (__GFP_FS) means. > When do we need to use GFP_NOFS rather than GFP_KERNEL? Yes it's a bit tricky to know. We have some support in lockdep for checking this now. That doesn't check page lock yet, and it's generally unsafe to allocate with __GFP_FS with page lock held. > For example, functions which are called by filesystems? > For example, after dentry->d_inode->i_mutex held? page lock, or any lock which can be blocked upon inside a ->writepage call, or icache/dcache/etc shrinking. i_mutex is most likely OK. We already allow it in some core code (buffered write path) although that could _potentially_ be overridden by a filesystem. However we always call ->writepage with page locked from reclaim, so any lock which nests outside page_lock (including i_mutex) must not block in writepage for reclaim. That leaves the shrinker callbacks. I don't think anybody will take i_mutex from shrinkers although I don't know if that's a rule.