linux.git/fs/dcache.c, branch v2.6.28

[PATCH] fs: add a sanity check in d_free

2008-10-23T09:17:12+00:00

Hi Al,

remember that debug session we did at KS? You suggested this patch back
then....

From 7751eaf30474b8cbfaea64795805a17eab05ac53 Mon Sep 17 00:00:00 2001
From: Arjan van de Ven 
Date: Tue, 16 Sep 2008 16:51:17 -0700
Subject: [PATCH] fs: add a sanity check in d_free

we're seeing some corruption in the dentry->d_alias list that
appears like a free of an entry still on the list; this patch
adds a WARN_ON() to catch this scenario, as suggested by Al Viro

Signed-off-by: Arjan van de Ven

[PATCH] fs/dcache.c: update comment of d_validate()

2008-10-23T09:13:24+00:00

Parameters @hash and @len have been removed since 2.4.3,
now just to delete them.

Signed-off-by: Qinghuang Feng

[PATCH vfs-2.6 4/6] vfs: remove unnecessary fsnotify_d_instantiate()

2008-10-23T09:13:18+00:00

This calls d_move(), so fsnotify_d_instantiate() is unnecessary like
rename path.

Signed-off-by: OGAWA Hirofumi

[PATCH vfs-2.6 3/6] vfs: add __d_instantiate() helper

2008-10-23T09:13:17+00:00

This adds __d_instantiate() for users which is already taking
dcache_lock, and replace with it.

The part of d_add_ci() isn't equivalent. But it should be needed
fsnotify_d_instantiate() actually, because the path is to add the
inode to negative dentry.  fsnotify_d_instantiate() should be called
after change from negative to positive.

Signed-off-by: OGAWA Hirofumi

[PATCH vfs-2.6 2/6] vfs: add d_ancestor()

2008-10-23T09:13:16+00:00

This adds d_ancestor() instead of d_isparent(), then use it.

If new_dentry == old_dentry, is_subdir() returns 1, looks strange.
"new_dentry == old_dentry" is not subdir obviously. But I'm not
checking callers for now, so this keeps current behavior.

Signed-off-by: OGAWA Hirofumi

[PATCH vfs-2.6 1/6] vfs: replace parent == dentry->d_parent by IS_ROOT()

2008-10-23T09:13:16+00:00

Signed-off-by: OGAWA Hirofumi

[PATCH] kill d_alloc_anon

2008-10-23T09:13:02+00:00

Remove d_alloc_anon now that no users are left.

Signed-off-by: Christoph Hellwig 
Signed-off-by: Al Viro

[PATCH] switch all filesystems over to d_obtain_alias

2008-10-23T09:13:01+00:00

Switch all users of d_alloc_anon to d_obtain_alias.

Signed-off-by: Christoph Hellwig 
Signed-off-by: Al Viro

[PATCH] new helper: d_obtain_alias

2008-10-23T09:13:00+00:00

The calling conventions of d_alloc_anon are rather unfortunate for all
users, and it's name is not very descriptive either.

Add d_obtain_alias as a new exported helper that drops the inode
reference in the failure case, too and allows to pass-through NULL
pointers and inodes to allow for tail-calls in the export operations.

Incidentally this helper already existed as a private function in
libfs.c as exportfs_d_alloc so kill that one and switch the callers
to d_obtain_alias.

Signed-off-by: Christoph Hellwig 
Signed-off-by: Al Viro

Fix NULL pointer dereference in proc_sys_compare

2008-09-29T14:42:57+00:00

The VFS interface for the 'd_compare()' is a bit special (read: 'odd'),
because it really just essentially replaces a memcmp().  The filesystem
is supposed to just compare the two names with whatever case-independent
or other function.

And when I say 'is supposed to', I obviously mean that 'procfs does odd
things, and actually looks at the dentry that we don't even pass down,
rather than just the name'.  Which results in problems, because we
actually call d_compare before we have even verified that the dentry is
still hashed at all.

And that causes a problm since the inode that procfs looks at may have
been free'd and the d_inode pointer is NULL.  procfs just assumes that
all dentries are positive, since procfs itself never generates a
negative one.  But memory pressure will still result in the dentry
getting torn down, and as it is removed by RCU, it still remains visible
on some lists - and to d_compare.

If the filesystem just did a name comparison, we wouldn't care.  And we
could just fix procfs to know about negative dentries too.  But rather
than have the low-level filesystems know about internal VFS details,
just move the check for a unhashed dentry up a bit, so that we will only
call d_compare on dentries that are still active.

The actual oops this caused didn't look like a NULL pointer dereference
because procfs did a 'container_of(inode, struct proc_inode, vfs_inode)'
to get at its internal proc_inode information from the inode pointer,
and accessed a field below the inode. So the oops would look something
like

	BUG: unable to handle kernel paging request at fffffffffffffff0
	IP: [] proc_sys_compare+0x36/0x50

and was seen on both x86-64 (Alexey Dobriyan and Hugh Dickins) and
ppc64 (Hugh Dickins).

Reported-by: Alexey Dobriyan 
Acked-by: Hugh Dickins 
Cc: Al Viro 
Reviewed-by: "Eric W. Biederman" 
Signed-of-by: Linus Torvalds