linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nick Piggin <npiggin@suse.de>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: When to use GFP_NOFS rather than GFP_KERNEL?
Date: Tue, 23 Mar 2010 00:02:25 +1100	[thread overview]
Message-ID: <20100322130225.GN17637@laptop> (raw)
In-Reply-To: <201003221515.EJD04125.QtFFMOVOLFOJHS@I-love.SAKURA.ne.jp>

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.


      reply	other threads:[~2010-03-22 13:02 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-22  6:15 When to use GFP_NOFS rather than GFP_KERNEL? Tetsuo Handa
2010-03-22 13:02 ` Nick Piggin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100322130225.GN17637@laptop \
    --to=npiggin@suse.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).