lkml.org 
[lkml]   [2012]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] situation with fput() locking (was Re: [PULL REQUEST] : ima-appraisal patches)
    On Fri, Apr 20, 2012 at 08:04:18PM +0100, Al Viro wrote:

    > Deferring the final pass after dropping ->mmap_sem is going to be
    > interesting; what would protect ->vm_next on those suckers? Locking
    > rules are already bloody complicated in mm/*; this will only add more
    > subtle fun. Note that right now both the dissolution of ->vm_next
    > list and freeing of VMAs happen under ->mmap_sem; changing that might
    > cost us a lot of headache...

    BTW, even leaving that aside, we have at least one definite deadlock
    (mainline, not on ->mmap_sem - see the mess in drivers/video/msm/mdp.c)
    and a possibility of other fun (e.g. any network filesystem that
    ends up triggering rtnl_lock() during umount is going to deadlock if
    you combine it with sch_atm.c mess where we do fget()/check/fput()
    in netlink message handling, close() from another thread racing with
    it and descriptor being the only thing that keeps that network fs
    alive past lazy umount or namespace dissolution). And then there's
    SCM_RIGHTS vs. drivers/vhost/net.c, which might or might not be
    deadlockable - I'm not familiar enough with that driver to tell
    right now.

    _If_ it had been ->mmap_sem alone, the things would be much simpler.
    There wouldn't be a problem, to start with - IMA stuff is not in the
    mainline and that's the only thing that really wants ->i_mutex in
    fput(); the few existing places that grab it in ->release() are racy
    anyway and need to be fixed with proper locking.


    \
     
     \ /
      Last update: 2012-04-20 21:39    [W:2.442 / U:0.068 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site