When to use GFP_NOFS rather than GFP_KERNEL?

When to use GFP_NOFS rather than GFP_KERNEL?

[Tetsuo Handa]

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?
For example, functions which are called by filesystems?
For example, after dentry->d_inode->i_mutex held?

Regards.

Re: When to use GFP_NOFS rather than GFP_KERNEL?

[Nick Piggin]

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.