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