diff options
author | Al Viro <viro@zeniv.linux.org.uk> | 2011-03-08 01:25:28 -0500 |
---|---|---|
committer | Al Viro <viro@zeniv.linux.org.uk> | 2011-03-08 02:22:27 -0500 |
commit | dfef6dcd35cb4a251f6322ca9b2c06f0bb1aa1f4 (patch) | |
tree | 65e8a25d4ed913658db35c4b97ab0a021c2124eb /REPORTING-BUGS | |
parent | 1858efd471624ecb37e6b5462cab8076f47d1cee (diff) | |
download | op-kernel-dev-dfef6dcd35cb4a251f6322ca9b2c06f0bb1aa1f4.zip op-kernel-dev-dfef6dcd35cb4a251f6322ca9b2c06f0bb1aa1f4.tar.gz |
unfuck proc_sysctl ->d_compare()
a) struct inode is not going to be freed under ->d_compare();
however, the thing PROC_I(inode)->sysctl points to just might.
Fortunately, it's enough to make freeing that sucker delayed,
provided that we don't step on its ->unregistering, clear
the pointer to it in PROC_I(inode) before dropping the reference
and check if it's NULL in ->d_compare().
b) I'm not sure that we *can* walk into NULL inode here (we recheck
dentry->seq between verifying that it's still hashed / fetching
dentry->d_inode and passing it to ->d_compare() and there's no
negative hashed dentries in /proc/sys/*), but if we can walk into
that, we really should not have ->d_compare() return 0 on it!
Said that, I really suspect that this check can be simply killed.
Nick?
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Diffstat (limited to 'REPORTING-BUGS')
0 files changed, 0 insertions, 0 deletions