Messages in this thread | | | Date | Mon, 9 Jun 2014 20:15:53 +0200 | From | Oleg Nesterov <> | Subject | Re: safety of *mutex_unlock() (Was: [BUG] signal: sighand unprotected when accessed by /proc) |
| |
On 06/09, Paul E. McKenney wrote: > > On Sun, Jun 08, 2014 at 03:07:18PM +0200, Oleg Nesterov wrote: > > > > 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...
And once again, note that the normal mutex is already unsafe (unless I missed something).
> > 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.
Or we can document that rt_mutex is special and rt_mutex_unlock() should be "atomic" and safe as spin_unlock() or complete().
Oleg.
| |