Re: 2.6.17-rc6-mm1 -- BUG: possible circular locking deadlock detected!

[Ingo Molnar <mingo@elte.hu>]

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

> This last lookup of physical location in map_mft_record() [actually in 
> readpage as map_mft_record() reads the page cache page containing the 
> record] cannot require us to load an extent mft record because the 
> runlist is complete so we cannot deadlock here.

ah! So basically, the locking sequences the validator observed during 
load_system_files() are a one-time event that can only occur during 
ntfs_fill_super().

if we ignore those dependencies (of the initial reading of the MFT inode 
generating recursive map_mft_record() calls) and take into account that 
the MFT inode will never again trigger map_mft_record() calls, then the 
locking is conflict-free after mounting has finished, right?

so the validator is technically correct that load_system_files() 
generates locking patterns that have dependency conflicts - but that 
code is guaranteed to be single-threaded because it's a one time event 
and because the VFS has no access to the filesystem at that time yet so 
there is zero parallellism.

can you think of any simple and clean solution that would avoid those 
conflicting dependencies within the NTFS code? Perhaps some way to read 
the MFT inode [and perhaps other, always-cached inodes that are later 
used as metadata] without locking? I can code it up and test it, but i 
dont think i can find the best method myself :-)

	Ingo