On Tue, Nov 07, 2006 at 12:28:37PM -0800, Andrew Morton wrote:
> So... what does this have to do with switching from mutex to semaphore?
I should have summarised the discussion, sorry.
This has always been a semaphore, but it got changed it to a mutex as part
of a global switch recently - and this indeed generated bug reports
from people who turn debugging on and report the error messages.
So the quick fix in this patch was to put things back how they were.
Now mutex.h states:
* - only the owner can unlock the mutex
* - task may not exit with mutex held
* These semantics are fully enforced when DEBUG_MUTEXES is
* enabled.
Which begs the question whether the stated semantics are stricter than
is actually necessary.
> If so, it's a bit sad to switch to semaphore just because of some errant
> debugging code. Perhaps it would be better to create a new
> mutex_unlock_stfu() which suppresses the warning?
Ingo?
> > + if (down_trylock(&bdev->bd_mount_sem))
> > + return -EBUSY;
> > +
> This is a functional change which isn't described in the changelog. What's
> happening here?
Srinivasa added it as a precaution.
Device-mapper should never fall foul of it, but confirming that is not
trivial unless you know the code well, so it's a useful check to prevent a
bug creeping back in.
Alasdair
--
[email protected]
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
