From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: JFFS2 deadlock with alloc_sem From: David Woodhouse To: Roberts Nathan-mcg31137 In-Reply-To: References: Content-Type: text/plain Date: Sat, 05 May 2007 09:23:36 +0100 Message-Id: <1178353416.11851.17.camel@pmac.infradead.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: linux-mtd@lists.infradead.org List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Mon, 2007-04-30 at 15:41 -0400, Roberts Nathan-mcg31137 wrote: > [] (__lock_page+0x0/0x98) from [] (read_cache_page+0x21c/0x324) > r5 = 00000000 r4 = C0336FE0 > [] (read_cache_page+0x0/0x324) from [] (jffs2_gc_fetch_page+0x2c/0x64) > [] (jffs2_gc_fetch_page+0x0/0x64) from [] (jffs2_garbage_collect_pass+0x14a4/0x1c28) > NOTE3: jffs2_gc_fetch_page() attempts to get page_lock This bit confuses me. In jffs2_commit_write() we deliberately mark the page up to date, in order to avoid this situation -- if the page is up to date, read_cache_page() won't attempt to lock it. (Note that we only set it up to date manually there if we're writing the whole page. If we're writing less than a whole page, then jffs2_prepare_write() will have read it and marked it up to date anyway. So it's possible that read_cache_page() will try to lock a page when called from jffs2_gc_fetch_page() -- but it _shouldn't_ be a page which is already locked for writing. It should be a _different_ page. Can you add a WARN_ON(!PageUptodate(pg)) into jffs2_commit_write(), just before the call to jffs2_write_inode_range(). And/or otherwise try to check which page each one is locking? -- dwmw2