JFFS2 gc deadlock
Josh Boyer
jdub at us.ibm.com
Mon Nov 7 16:18:05 EST 2005
Ok, around line 1210 of gc.c, this comment is present (formatted for
better read-ability):
/* First, use readpage() to read the appropriate page into the page cache */
/* Q: What happens if we actually try to GC the _same_ page for which commit_write()
* triggered garbage collection in the first place?
* A: I _think_ it's OK. read_cache_page shouldn't deadlock, we'll write out the
* page OK. We'll actually write it out again in commit_write, which is a little
* suboptimal, but at least we're correct.
*/
Can someone explain to me how read_cache_page won't deadlock in that
case? From what I can see, it will deadlock quite easily. Shouldn't
jffs2_garbage_collect_dnode or an above function check if the page is
being written to already?
I believe I'm currently looking at a failure where this exact thing has
happened. Basically, it seems to require the filesystem being quite low
on space (as in right on the -ENOSPC threshold) and the writing process
to have invoked a gc pass during it's jffs2_reserve_space call.
josh
More information about the linux-mtd
mailing list