lkml.org 
[lkml]   [2012]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [RFC] situation with fput() locking (was Re: [PULL REQUEST] : ima-appraisal patches)
    On Fri, Apr 20, 2012 at 1:09 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
    >
    > Note that we do *not* need to bother with fput_light() - even if it does
    > fput(), that fput() won't usually be the final one.

    Ack. Most of the time the fput_light()->fput will just decrement the use count.

    > We also get something else out of that - AFAICS, the kludge in __scm_destroy()
    > can be killed after that.  We did it to prevent recursion on fput(), right?
    > Now that recursion will be gone...

    Hmm.. That points out that we may have a *lot* of these pending final
    fput's, though. So the deferral queueing should be fairly light. What
    were your particular plans for it?

    This actually sounds like a fairly good usage-case for Oleg's new
    task_work_add() thing. That would defer the final fput, but at the
    same time guarantee that it gets done before returning to user space -
    in case there are any issues with synchronous actions. Have you looked
    at Oleg's series? You weren't cc'd because it didn't affect you, but
    look at lkml for "task_work_add()" to find it.

    NOTE! If pure kernel threads do fput() deferral (and maybe they do -
    I'm thinking nfsd etc), then the task-work thing might need some extra
    thought.

    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/

    \
     
     \ /
      Last update: 2012-04-20 17:59    [W:0.030 / U:60.736 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site