Re: When to use GFP_NOFS rather than GFP_KERNEL?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux