summaryrefslogtreecommitdiff
path: root/security/smack/smack_access.c
diff options
context:
space:
mode:
authorTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>2012-03-29 16:19:05 +0900
committerCasey Schaufler <cschaufler@vaio-ubuntu.(none)>2012-05-14 22:47:44 -0700
commitceffec5541cc22486d3ff492e3d76a33a68fbfa3 (patch)
treed1eaebc1b1894ed9391959cc9f5846543a4b4e42 /security/smack/smack_access.c
parent2267b13a7cad1f9dfe0073c1f902d45953f9faff (diff)
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)>
Diffstat (limited to 'security/smack/smack_access.c')
0 files changed, 0 insertions, 0 deletions