On 06/09, Steven Rostedt wrote: > > On Mon, 9 Jun 2014 20:15:53 +0200 > Oleg Nesterov <[email protected]> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
