* Anton Altaparmakov <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
