[lkml]   [2012]   [Apr]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] situation with fput() locking (was Re: [PULL REQUEST] : ima-appraisal patches)
    On Fri, Apr 20, 2012 at 03:54:38AM +0100, Al Viro wrote:

    > and filp_close() would, if that turns out to be possible, call fput_nodefer()
    > instead of fput(). If we *do* have places where we need deferral in
    > filp_close() (and I'm fairly sure that any such place is a deadlock right
    > now), well, we'll need a variant of filp_close() sans the call of fput...()
    > and those places would call that, followed by full (deferring) fput().

    BTW, some of those filp_close() are simply wrong - e.g. a big pile in
    drivers/media/video/cx25821/*.c should be fput().

    And yes, we have at least some under mutex - binder_lock held by
    binder_ioctl(), which ends up doing binder_transaction() with its
    failure cleanup hitting close_filp(). On an arbitrary struct file.
    It *probably* doesn't deadlock on the spot, since binder_release()
    itself contains a deferral mechanism (perhaps they'd spotted the
    deadlock, perhaps there are other reasons to have it).

     \ /
      Last update: 2012-04-20 05:19    [W:0.035 / U:7.860 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site