From: Jann Horn > Sent: 01 December 2023 16:41 > > mutex_unlock() has a different API contract compared to spin_unlock(). > spin_unlock() can be used to release ownership of an object, so that > as soon as the spinlock is unlocked, another task is allowed to free > the object containing the spinlock. > mutex_unlock() does not support this kind of usage: The caller of > mutex_unlock() must ensure that the mutex stays alive until > mutex_unlock() has returned. The problem sequence might be: Thread A Thread B mutex_lock() code to stop mutex being requested ... mutex_lock() - sleeps mutex_unlock()... Waiters woken... isr and/or pre-empted - wakes up mutex_unlock() free() ... more kernel code access the mutex BOOOM What happens in a PREEMPT_RT kernel where most of the spin_unlock() get replaced by mutex_unlock(). Seems like they can potentially access a freed mutex? David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
