lkml.org 
[lkml]   [2005]   [Jan]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6.11-rc2-mm1
On Tue, 25 Jan 2005 15:36:57 +0000
Paulo Marques <pmarques@grupopie.com> wrote:

> Evgeniy Polyakov wrote:
> > [...]
> > No, it is not called lock order reversal.
> >
> > There are no places like
> > lock a
> > lock b
> > unlock a
> > unlock b
>
> This would be perfectly fine. The order of unlocking doesn't really
> matter. It is the actual locking that must be carried out on the same
> order everywhere to guarantee that there are no deadlocks.

It is bad style, and since unlocking changes the order someone
may pass wrong locking.

> > and if they are, then I'm completely wrong.
> >
> > What you see is only following:
> >
> > place 1:
> > lock a
> > lock b
> > unlock b
> > lock c
> > unlock c
> > unlock a
> >
> > place 2:
> > lock b
> > lock a
> > unlock a
> > lock c
> > unlock c
> > unlock b
>
> I haven't look at the code yet, but this is a deadlock waiting to
> happen. "place 1" gets "lock a", then is interrupted and "place 2" gets
> "lock b". "place 2" waits forever for "lock a" and "place 1" waits
> forever for "lock b". Deadlock.

As I said, that pathes are mutually exclusive - common pathes are guarded
by one lock always.

> --
> Paulo Marques - www.grupopie.com
>
> "A journey of a thousand miles begins with a single step."
> Lao-tzu, The Way of Lao-tzu


Evgeniy Polyakov

Only failure makes us experts. -- Theo de Raadt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:09    [W:0.194 / U:11.552 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site