lkml.org 
[lkml]   [2006]   [Jun]   [9]   [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:

> 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
-
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-09 09:22    [W:0.076 / U:34.760 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site