<p dir="ltr"><br>
On 15-Mar-2016 7:19 pm, "Cihangir Akturk" <<a href="mailto:cakturk@gmail.com">cakturk@gmail.com</a>> wrote:<br>
><br>
> On Thu, Mar 10, 2016 at 02:59:31PM +0530, Chetan Nanda wrote:<br>
> > Hi,<br>
> ><br>
> > As per book (Linux kernel development)<br>
> ><br>
> > "Whoever locked a mutex must unlock it.That is, you cannot lock a mutex in one<br>
> > context and then unlock it in another<br>
> > "<br>
> > but 'mutex_unlock' code is not checking the owner field at all.<br>
><br>
> If you look at the definition of mutex structure in mutex.h:50,<br>
> you'll see that the owner field will be compiled in if one of<br>
> CONFIG_DEBUG_MUTEXES or CONFIG_MUTEX_SPIN_ON_OWNER is defined.<br>
><br>
> And debug_mutex_unlock function in mutex-debug.c:72 will check<br>
> the owner and emits warning if it finds out that the mutex isn't<br>
> unlocked by its owner.<br>
><br>
> <a href="http://lxr.free-electrons.com/source/include/linux/mutex.h#L50">http://lxr.free-electrons.com/source/include/linux/mutex.h#L50</a><br>
> <a href="http://lxr.free-electrons.com/source/kernel/locking/mutex-debug.c#L72">http://lxr.free-electrons.com/source/kernel/locking/mutex-debug.c#L72</a><br>
><br>
Thanks for your mail, in my kernel CONFIG_MUTEX_SPIN_ON_OWNER is enabled but CONFIG_DEBUG_MUTEX is not enabled. <br>
So there are no warning messages in logs. </p>
<p dir="ltr">Also, it don't seems to be a real performance hit by adding a single check of owner with current in unlock code. <br>
> ><br>
> > Also, I tried with locking the mutex from normal process context and<br>
> > unlocking from separate context (work context) and it is allowed<br>
> > without any error from kernel.<br>
> ><br>
> > Is it the mutex user responsibility to keep track of it? Ideally<br>
> > mutex_unlock should check if owner is same as current?<br>
</p>