]> git.karo-electronics.de Git - karo-tx-linux.git/commit
gfp flags for security_inode_alloc()?
authorTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Thu, 29 Mar 2012 07:19:05 +0000 (16:19 +0900)
committerCasey Schaufler <cschaufler@cschaufler-intel.(none)>
Mon, 9 Apr 2012 16:16:23 +0000 (09:16 -0700)
commit78b58ef33773674db755ef8d861d6ff407d1088e
treeeb913346ab11db80b50f5e726b34b86dc8a451b0
parente13e88b2aecf4eacabbbf3ba33797de89bd94054
gfp flags for security_inode_alloc()?

Dave Chinner wrote:
> Yes, because you have no idea what the calling context is except
> for the fact that is from somewhere inside filesystem code and the
> filesystem could be holding locks. Therefore, GFP_NOFS is really the
> only really safe way to allocate memory here.

I see. Thank you.

I'm not sure, but can call trace happen where somewhere inside network
filesystem or stackable filesystem code with locks held invokes operations that
involves GFP_KENREL memory allocation outside that filesystem?
----------
[PATCH] SMACK: Fix incorrect GFP_KERNEL usage.

new_inode_smack() which can be called from smack_inode_alloc_security() needs
to use GFP_NOFS like SELinux's inode_alloc_security() does, for
security_inode_alloc() is called from inode_init_always() and
inode_init_always() is called from xfs_inode_alloc() which is using GFP_NOFS.

smack_inode_init_security() needs to use GFP_NOFS like
selinux_inode_init_security() does, for initxattrs() callback function (e.g.
btrfs_initxattrs()) which is called from security_inode_init_security() is
using GFP_NOFS.

smack_audit_rule_match() needs to use GFP_ATOMIC, for
security_audit_rule_match() can be called from audit_filter_user_rules() and
audit_filter_user_rules() is called from audit_filter_user() with RCU read lock
held.

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Casey Schaufler <cschaufler@cschaufler-intel.(none)>
security/smack/smack_lsm.c