Messages in this thread | | | Date | Mon, 9 Jun 2014 21:04:02 +0200 | From | Oleg Nesterov <> | Subject | Re: safety of *mutex_unlock() (Was: [BUG] signal: sighand unprotected when accessed by /proc) |
| |
On 06/09, Steven Rostedt wrote: > > On Mon, 9 Jun 2014 20:15:53 +0200 > Oleg Nesterov <oleg@redhat.com> wrote: > > > > 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). > > Is it unsafe?
Only in a sense that UNLOCK is not atomic.
IOW, you can't, say, declare a mutex or semaphore on stack, and use lock/unlock to serialize with another thread.
But rt_mutex seems fine in this case, and for example rcu_boost() does this. I do not know if this is by design or not, and can we rely on this or not.
> This thread was started because of a bug we triggered in -rt, which > ended up being a change specific to -rt that modified the way slub > handled SLAB_DESTROY_BY_RCU. What else was wrong with it?
And I specially changed the subject to avoid the confusion with SLAB_DESTROY_BY_RCU bug we discussed before, but apparently I need to apologize for confusion again ;)
But. Note that if rt_mutex is changed so that UNLOCK becomes non-atomic in a sense above, then lock_task_sighand()/unlock_task_sighand() will be buggy in -rt.
Oleg.
| |