[lkml]   [2009]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 5/6] futex: unlock before returning -EFAULT
    Peter Zijlstra wrote:
    > On Thu, 2009-03-12 at 11:47 +0100, Thomas Gleixner wrote:
    >> On Thu, 12 Mar 2009, Peter Zijlstra wrote:
    >>> On Thu, 2009-03-12 at 00:56 -0700, Darren Hart wrote:
    >>>> futex_lock_pi can potentially return -EFAULT with the rt_mutex held. This
    >>>> seems like the wrong thing to do as userspace should assume -EFAULT means the
    >>>> lock was not taken. Even if it could figure this out, we'd be leaving the
    >>>> pi_state->owner in an inconsistent state. This patch unlocks the rt_mutex
    >>>> prior to returning -EFAULT to userspace.
    >>> lockdep would complain, one is not to leave the kernel with locks held.
    >> That would break pi futexes in bits and pieces.
    >> T1 takes F1
    >> T2 blocks on F1
    >> -> T2 sets up rt_mutex and locks it for T1
    >> T2 blocks on rt_mutex and boosts T1
    >> T1 calls a non futex syscall
    >> T1 returns from syscall with the rt_mutex still locked
    >> Thanks,
    > Oh right, raw rt_mutex stuff isn't lockdep annotated, and you use the
    > robust futex infrastructure to ensure stuff gets unlocked when holder
    > dies. That should work out.

    OK, are there any other concerns with this patch?

    Darren Hart
    IBM Linux Technology Center
    Real-Time Linux Team

     \ /
      Last update: 2009-03-12 16:19    [W:2.851 / U:1.000 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site