From: Artem Bityutskiy <dedekind@infradead.org>
To: Adrian Hunter <ext-adrian.hunter@nokia.com>
Cc: David Woodhouse <dwmw2@infradead.org>,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: JFFS2: BUG: sleeping function called from invalid context
Date: Tue, 20 Mar 2007 20:01:37 +0200 [thread overview]
Message-ID: <1174413697.17249.126.camel@sauron> (raw)
In-Reply-To: <45FFBCC6.8010800@nokia.com>
On Tue, 2007-03-20 at 12:51 +0200, Adrian Hunter wrote:
> BUG: sleeping function called from invalid context at include/linux/writeback.h:76
> in_atomic():1, irqs_disabled():0
> 2 locks held by jffs2_gcd_mtd0/5710:
> #0: (&c->wbuf_sem){----}, at: [<f8b09814>] jffs2_flash_writev+0x67/0x5c0 [jffs2]
> #1: (&c->erase_completion_lock){--..}, at: [<f8b085f8>] jffs2_wbuf_recover+0xb03/0x11f1 [jffs2]
> [<c01040df>] show_trace_log_lvl+0x1a/0x30
> [<c0104806>] show_trace+0x12/0x14
> [<c01048aa>] dump_stack+0x16/0x18
> [<c011cee4>] __might_sleep+0xb8/0xcb
> [<c0181ed9>] ifind_fast+0x48/0x86
> [<c01821d9>] iget_locked+0x2a/0x133
> [<f8b06713>] jffs2_gc_fetch_inode+0x18e/0x229 [jffs2]
> [<f8b08853>] jffs2_wbuf_recover+0xd5e/0x11f1 [jffs2]
> [<f8b0909c>] __jffs2_flush_wbuf+0x3b6/0x791 [jffs2]
> [<f8b09b14>] jffs2_flash_writev+0x367/0x5c0 [jffs2]
> [<f8afb59f>] jffs2_write_dnode+0x180/0x403 [jffs2]
> [<f8b02626>] jffs2_garbage_collect_dnode+0x7d3/0x8cd [jffs2]
> [<f8b004b8>] jffs2_garbage_collect_live+0x242/0x31e [jffs2]
> [<f8b00148>] jffs2_garbage_collect_pass+0x99b/0xac9 [jffs2]
> [<f8b04ad7>] jffs2_garbage_collect_thread+0x341/0x396 [jffs2]
> [<c0103d53>] kernel_thread_helper+0x7/0x14
> =======================
This function seems to be completely broken. JFF2 calls iget() while
holding c->erase_completion_lock spinlock. This is one problem. Iget can
sleep.
The other one is that JFFS2 calls jffs2_gc_fetch_inode() while holding
c->alloc_sem and c->wbuf_sem semaphores. What happens if JFFS2 races
with pdflush, and pdflush wins, clears inode, then VFS calls
read_inode() to satisfy JFFS2's iget() request. It is a _deadlock_
because the in read_inode JFFS2 will try to lock the above semaphores
again.
The wbuf recovery function has to be re-worked or just disabled -
because returning error is better then fall into a deadlock.
David,
comments, ideas?
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
WARNING: multiple messages have this Message-ID (diff)
From: Artem Bityutskiy <dedekind@infradead.org>
To: Adrian Hunter <ext-adrian.hunter@nokia.com>
Cc: linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
David Woodhouse <dwmw2@infradead.org>
Subject: Re: JFFS2: BUG: sleeping function called from invalid context
Date: Tue, 20 Mar 2007 20:01:37 +0200 [thread overview]
Message-ID: <1174413697.17249.126.camel@sauron> (raw)
In-Reply-To: <45FFBCC6.8010800@nokia.com>
On Tue, 2007-03-20 at 12:51 +0200, Adrian Hunter wrote:
> BUG: sleeping function called from invalid context at include/linux/writeback.h:76
> in_atomic():1, irqs_disabled():0
> 2 locks held by jffs2_gcd_mtd0/5710:
> #0: (&c->wbuf_sem){----}, at: [<f8b09814>] jffs2_flash_writev+0x67/0x5c0 [jffs2]
> #1: (&c->erase_completion_lock){--..}, at: [<f8b085f8>] jffs2_wbuf_recover+0xb03/0x11f1 [jffs2]
> [<c01040df>] show_trace_log_lvl+0x1a/0x30
> [<c0104806>] show_trace+0x12/0x14
> [<c01048aa>] dump_stack+0x16/0x18
> [<c011cee4>] __might_sleep+0xb8/0xcb
> [<c0181ed9>] ifind_fast+0x48/0x86
> [<c01821d9>] iget_locked+0x2a/0x133
> [<f8b06713>] jffs2_gc_fetch_inode+0x18e/0x229 [jffs2]
> [<f8b08853>] jffs2_wbuf_recover+0xd5e/0x11f1 [jffs2]
> [<f8b0909c>] __jffs2_flush_wbuf+0x3b6/0x791 [jffs2]
> [<f8b09b14>] jffs2_flash_writev+0x367/0x5c0 [jffs2]
> [<f8afb59f>] jffs2_write_dnode+0x180/0x403 [jffs2]
> [<f8b02626>] jffs2_garbage_collect_dnode+0x7d3/0x8cd [jffs2]
> [<f8b004b8>] jffs2_garbage_collect_live+0x242/0x31e [jffs2]
> [<f8b00148>] jffs2_garbage_collect_pass+0x99b/0xac9 [jffs2]
> [<f8b04ad7>] jffs2_garbage_collect_thread+0x341/0x396 [jffs2]
> [<c0103d53>] kernel_thread_helper+0x7/0x14
> =======================
This function seems to be completely broken. JFF2 calls iget() while
holding c->erase_completion_lock spinlock. This is one problem. Iget can
sleep.
The other one is that JFFS2 calls jffs2_gc_fetch_inode() while holding
c->alloc_sem and c->wbuf_sem semaphores. What happens if JFFS2 races
with pdflush, and pdflush wins, clears inode, then VFS calls
read_inode() to satisfy JFFS2's iget() request. It is a _deadlock_
because the in read_inode JFFS2 will try to lock the above semaphores
again.
The wbuf recovery function has to be re-worked or just disabled -
because returning error is better then fall into a deadlock.
David,
comments, ideas?
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
next prev parent reply other threads:[~2007-03-20 18:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-20 10:51 JFFS2: BUG: sleeping function called from invalid context Adrian Hunter
2007-03-20 18:01 ` Artem Bityutskiy [this message]
2007-03-20 18:01 ` Artem Bityutskiy
2007-03-23 14:15 ` Adrian Hunter
2007-03-23 14:48 ` David Woodhouse
2007-03-26 11:54 ` Adrian Hunter
2007-03-26 12:01 ` Adrian Hunter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1174413697.17249.126.camel@sauron \
--to=dedekind@infradead.org \
--cc=dwmw2@infradead.org \
--cc=ext-adrian.hunter@nokia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.