[lkml]   [2011]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH resend] audit: fix mark refcounting
    On Thu, Dec 15, 2011 at 12:40 AM, Al Viro <> 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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2011-12-15 17:51    [W:0.021 / U:8.652 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site