Al Viro <viro@xxxxxxxxxxxxxxxxxx> writes: > Dunno... Neither instance actually touches the mark after that > destroy_mark and we have very few of those guys (fortunately). So > removing this BUG_ON() instead might be the right thing to do. So here's a patch doing that. Tested okay. Please apply. Thanks, Miklos --- From: Miklos Szeredi <mszeredi@xxxxxxx> Subject: fsnotify: don't BUG in fsnotify_destroy_mark() Removing the parent of a watched file results in "kernel BUG at fs/notify/mark.c:139". To reproduce add "-w /tmp/audit/dir/watched_file" to audit.rules rm -rf /tmp/audit/dir This is caused by fsnotify_destroy_mark() being called without an extra reference taken by the caller. Reported by Francesco Cosoleto here: https://bugzilla.novell.com/show_bug.cgi?id=689860 Fix by removing the BUG_ON and adding a comment about not accessing mark after the iput. Signed-off-by: Miklos Szeredi <mszeredi@xxxxxxx> CC: stable@xxxxxxxxxxxxxxx --- fs/notify/mark.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) Index: linux-2.6/fs/notify/mark.c =================================================================== --- linux-2.6.orig/fs/notify/mark.c 2011-10-26 14:26:23.000000000 +0200 +++ linux-2.6/fs/notify/mark.c 2012-01-12 14:25:40.000000000 +0100 @@ -135,9 +135,6 @@ void fsnotify_destroy_mark(struct fsnoti mark->flags &= ~FSNOTIFY_MARK_FLAG_ALIVE; - /* 1 from caller and 1 for being on i_list/g_list */ - BUG_ON(atomic_read(&mark->refcnt) < 2); - spin_lock(&group->mark_lock); if (mark->flags & FSNOTIFY_MARK_FLAG_INODE) { @@ -182,6 +179,11 @@ void fsnotify_destroy_mark(struct fsnoti iput(inode); /* + * We don't necessarily have a ref on mark from caller so the above iput + * may have already destroyed it. Don't touch from now on. + */ + + /* * it's possible that this group tried to destroy itself, but this * this mark was simultaneously being freed by inode. If that's the * case, we finish freeing the group here. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
