lkml.org 
[lkml]   [2014]   [Jun]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: safety of *mutex_unlock() (Was: [BUG] signal: sighand unprotected when accessed by /proc)
    On Tue, 10 Jun 2014, Steven Rostedt wrote:
    > On Tue, 10 Jun 2014 20:08:37 +0200 (CEST)
    > Thomas Gleixner <tglx@linutronix.de> wrote:
    >
    >
    > > > Perhaps it could simply do ->owner = RT_MUTEX_HAS_WAITERS to make this more
    > > > clear...
    > >
    > > Good point. The new owner can cleanup the mess.
    > >
    >
    > I thought about this too. It should work with the added overhead that
    > every time we go into the unlock slow path, we guarantee that the next
    > lock will go into the lock slowpath.
    >
    > As long as the new acquired lock does a fast unlock, then we get out of
    > this spiral.

    The alternative solution is to document WHY this is safe. I think I
    prefer that one :)

    Thanks,

    tglx




    \
     
     \ /
      Last update: 2014-06-10 23:01    [W:4.004 / U:0.184 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site