Messages in this thread | | | Date | Fri, 9 Jun 2006 09:19:00 +0200 | From | Ingo Molnar <> | Subject | Re: 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/
| |