Message-ID: <41F66799.5050004@grupopie.com>
Date: Tue, 25 Jan 2005 15:36:57 +0000
From: Paulo Marques <pmarques@grupopie.com>
Organization: Grupo PIE
User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040626)
MIME-Version: 1.0
To: johnpol@2ka.mipt.ru
Cc: Christoph Hellwig <hch@infradead.org>, Andrew Morton <akpm@osdl.org>,
       greg@kroah.com, linux-kernel@vger.kernel.org
Subject: Re: 2.6.11-rc2-mm1
References: <20050124021516.5d1ee686.akpm@osdl.org>	 <20050125125323.GA19055@infradead.org> <1106662284.5257.53.camel@uganda>	 <20050125142356.GA20206@infradead.org> <1106666690.5257.97.camel@uganda>
In-Reply-To: <1106666690.5257.97.camel@uganda>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1190
Lines: 50

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.

> 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.

-- 
Paulo Marques - www.grupopie.com

"A journey of a thousand miles begins with a single step."
Lao-tzu, The Way of Lao-tzu

-
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/