Messages in this thread | | | From | Linus Torvalds <> | Date | Thu, 15 Dec 2011 08:48:30 -0800 | Subject | Re: [PATCH resend] audit: fix mark refcounting |
| |
On Thu, Dec 15, 2011 at 12:40 AM, Al Viro <viro@zeniv.linux.org.uk> wrote: >> >> In particular, a quick grep shows that there are destroy_mark users still in: >> >> - fs/notify/fanotify/fanotify_user.c >> >> - fs/notify/dnotify/dnotify.c (2 of them) >> >> - fs/notify/inotify/inotify_fsnotify.c >> >> that don't do "put_mark()" after the destroy. Why is it ok there? > > Um? dnotify has fsnotify_put_mark() called in both cases...
Ok, that didn't show up in my grep, the "put_mark()" was more than three lines away in the other case. As mentioned, I simply grepped without looking at much context at all.
> I don't like it; it's called from ->handle_event() and parent->mark is > exactly the inode_mark argument of that method. It ought to be pinned > by caller. In other places we *do* need get/put around that destroy > and we generally do that.
Presumably *parent* is pinned by caller, but not ->mark. So when the parent directory is deleted, the parent data structure stays around, but mark is cleanred, and you get the oops that was reported. See the simple two-liner example to trigger it. I didn't test it myself, but it looks obvious.
Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |