diff options
author | Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> | 2012-03-29 16:19:05 +0900 |
---|---|---|
committer | Casey Schaufler <cschaufler@vaio-ubuntu.(none)> | 2012-05-14 22:47:44 -0700 |
commit | ceffec5541cc22486d3ff492e3d76a33a68fbfa3 (patch) | |
tree | d1eaebc1b1894ed9391959cc9f5846543a4b4e42 /crypto/gf128mul.c | |
parent | 2267b13a7cad1f9dfe0073c1f902d45953f9faff (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 'crypto/gf128mul.c')
0 files changed, 0 insertions, 0 deletions