lkml.org 
[lkml]   [2006]   [Jun]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6.17-rc6-mm1 -- BUG: possible circular locking deadlock detected!

* Anton Altaparmakov <aia21@cam.ac.uk> wrote:

> > &ni->mrec_lock - a spinlock protecting a particular inode's MFT data.
> > (finegrained lock for the MFT record) It is
> > typically taken by map_mft_record() and released by
> > unmap_mft_record().
>
> Correct, except s/spinlock/semaphore/ (that really should become a
> mutex one day).

yeah - it's in fact a mutex already.

> No it is not as explained above. Something has gotten confused
> somewhere because the order of events is the wrong way round...

did my second trace make more sense? The dependency that the validator
recorded can be pretty much taken as granted - it only stores
dependencies that truly trigger runtime. What shouldnt be taken as
granted is my explanation of the events :-)

there is a wide array of methods and APIs available to express locking
semantics to the validator in a natural and non-intrusive way [for cases
where the validator gets it wrong or simply has no way of auto-learning
them] - but for that i'll first have to understand the locking semantics
:-)

Ingo
-
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: 2006-06-08 18:14    [W:0.057 / U:2.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site