On Fri, May 02, 2008 at 12:37:18PM +0100, David Woodhouse wrote: > On Fri, 2008-05-02 at 11:38 +1000, Neil Brown wrote: > > Why is there a deadlock here? > > Many file systems have their own locking, and lookup() can end up trying > to re-take a lock which readdir() is already holding. In the JFFS2 case, > it's the fs-internal inode mutex, which is required because the garbage > collector can't use i_mutex for lock ordering reasons. > > See also the readdir implementation and surrounding comments in > fs/xfs/linux-2.6/xfs_file.c -- and the way GFS2 uses > gfs2_glock_is_locked_by_me() to avoid the deadlock. > > The annoying thing is that JFFS2 doesn't even _implement_ i_generation, > so you get no more useful information out of the lookup() call anyway :) > > > Both readdir and lookup are called with i_mutex held on the directory > > so there should need to do any extra locking (he said, naively). In > > the readdirplus cases, i_mutex is held across both the readdir and the > > lookup.... > > > > One problem with your proposed solution is that filehandles aren't all > > the same length, so you cannot reliably leave space for them. > > Not without moving stuff around during the postprocessing, I suppose. > Which isn't very pretty -- but it's prettier than some of the hacks we > have at the moment to avoid the deadlock. This comes up periodically. It would be great to finally get it fixed. The last conversation I remember started at about: http://marc.info/?l=linux-kernel&m=119506226209056&w=2 Summary: one approach would be to define a ->readdirplus() that passes a dentry to its equivalent of the ->filldir callback. (Christoph points out that returning a stat struct would be simpler. But unfortunately we need to check for mountpoints here, so that's not sufficient.) --b. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
