lkml.org 
[lkml]   [2014]   [Jun]   [9]   [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 Sun, Jun 08, 2014 at 03:07:18PM +0200, Oleg Nesterov wrote:
    > On 06/06, Paul E. McKenney wrote:
    > >
    > > On Tue, Jun 03, 2014 at 10:01:25PM +0200, Oleg Nesterov wrote:
    > > >
    > > > I'll try to recheck rt_mutex_unlock() tomorrow. _Perhaps_ rcu_read_unlock()
    > > > should be shifted from lock_task_sighand() to unlock_task_sighand() to
    > > > ensure that rt_mutex_unlock() does nothihg with this memory after it
    > > > makes another lock/unlock possible.
    > > >
    > > > But if we need this (currently I do not think so), this doesn't depend on
    > > > SLAB_DESTROY_BY_RCU. And, at first glance, in this case rcu_read_unlock_special()
    > > > might be wrong too.
    > >
    > > OK, I will bite... What did I mess up in rcu_read_unlock_special()?
    > >
    > > This function does not report leaving the RCU read-side critical section
    > > until after its call to rt_mutex_unlock() has returned, so any RCU
    > > read-side critical sections in rt_mutex_unlock() will be respected.
    >
    > Sorry for confusion.
    >
    > I only meant that afaics rcu_read_unlock_special() equally depends on the
    > fact that rt_mutex_unlock() does nothing with "struct rt_mutex" after it
    > makes another rt_mutex_lock() + rt_mutex_unlock() possible, otherwise this
    > code is wrong (and unlock_task_sighand() would be wrong too).
    >
    > Just to simplify the discussion... suppose we add "atomic_t nr_slow_unlock"
    > into "struct rt_mutex" and change rt_mutex_slowunlock() to do
    > atomic_inc(&lock->nr_slow_unlock) after it drops ->wait_lock. Of course this
    > would be ugly, just for illustration.

    That would indeed be a bad thing, as it could potentially lead to
    use-after-free bugs. Though one could argue that any code that resulted
    in use-after-free would be quite aggressive. But still...

    > In this case atomic_inc() above can write to rcu_boost()'s stack after this
    > functions returns to the caller. And unlock_task_sighand() would be wrong
    > too, atomic_inc() could write to the memory which was already returned to
    > system because "unlock" path runs outside of rcu-protected section.
    >
    > But it seems to me that currently we are safe, rt_mutex_unlock() doesn't do
    > something like this, a concurrent rt_mutex_lock() must always take wait_lock
    > too.
    >
    >
    > And while this is off-topic and I can be easily wrong, it seems that the
    > normal "struct mutex" is not safe in this respect. If nothing else, once
    > __mutex_unlock_common_slowpath()->__mutex_slowpath_needs_to_unlock() sets
    > lock->count = 1, a concurent mutex_lock() can take and then release this
    > mutex before __mutex_unlock_common_slowpath() takes ->wait_lock.
    >
    > So _perhaps_ we should not rely on this property of rt_mutex "too much".

    Well, I could easily move the rt_mutex from rcu_boost()'s stack to the
    rcu_node structure, if that would help. That said, I still have my
    use-after-free concern above.

    Thanx, Paul



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