From: Alan Stern <stern@rowland.harvard.edu>
To: Ted Ts'o <tytso@mit.edu>
Cc: bugzilla-daemon@bugzilla.kernel.org, <linux-ext4@vger.kernel.org>,
<rockorequin@hotmail.com>
Subject: Re: [Bug 25832] kernel crashes when a mounted ext3/4 file system is physically removed
Date: Sat, 10 Sep 2011 14:07:01 -0400 (EDT) [thread overview]
Message-ID: <Pine.LNX.4.44L0.1109101403400.3905-100000@netrider.rowland.org> (raw)
In-Reply-To: <20110909191354.GC3818@thunk.org>
On Fri, 9 Sep 2011, Ted Ts'o wrote:
> commit 6e478d46e58181ec4814f25a2fd91c6323e16ad4
> Author: Theodore Ts'o <tytso@mit.edu>
> Date: Fri Sep 9 15:02:54 2011 -0400
>
> ext4: add ext4-specific kludge to avoid an oops after the disk disappears
>
> The del_gendisk() function uninitializes the disk-specific data
> structures, including the bdi structure, without telling anyone
> else. Once this happens, any attempt to call mark_buffer_dirty()
> (for example, by ext4_commit_super), will cause a kernel OOPS.
>
> Fix this for now until we can fix things in an architecturally correct
> way.
>
> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Further testing revealed the following problem. I changed the test
script so that after the USB device is unbound, the script tries to
write a file before unmounting the ext4 filesystem.
There was no drastic failure; the unregistered bdi structure wasn't
accessed. But lockdep complained. This is what I got:
[ 166.932194] end_request: I/O error, dev uba, sector 136
[ 166.940903] EXT4-fs error (device uba): ext4_find_entry:934: inode #2: comm sh: reading directory lblock 0
[ 166.949284] end_request: I/O error, dev uba, sector 164
[ 166.952084] EXT4-fs error (device uba): ext4_read_inode_bitmap:161: comm sh: Cannot read inode bitmap - block_group = 0, inode_bitmap = 82
[ 166.952906] EXT4-fs error (device uba) in ext4_new_inode:1073: IO failure
[ 166.953357]
[ 166.953381] =============================================
[ 166.953624] [ INFO: possible recursive locking detected ]
[ 166.953958] 3.1.0-rc4 #34
[ 166.954099] ---------------------------------------------
[ 166.954295] sh/819 is trying to acquire lock:
[ 166.954613] (&sb->s_type->i_mutex_key#9){+.+.+.}, at: [<c1101290>] ext4_evict_inode+0x17/0x288
[ 166.955947]
[ 166.955969] but task is already holding lock:
[ 166.956281] (&sb->s_type->i_mutex_key#9){+.+.+.}, at: [<c10aeb45>] do_last+0x165/0x4ff
[ 166.956586]
[ 166.956586] other info that might help us debug this:
[ 166.956586] Possible unsafe locking scenario:
[ 166.956586]
[ 166.956586] CPU0
[ 166.956586] ----
[ 166.956586] lock(&sb->s_type->i_mutex_key);
[ 166.956586] lock(&sb->s_type->i_mutex_key);
[ 166.956586]
[ 166.956586] *** DEADLOCK ***
[ 166.956586]
[ 166.956586] May be due to missing lock nesting notation
[ 166.956586]
[ 166.956586] 2 locks held by sh/819:
[ 166.956586] #0: (&sb->s_type->i_mutex_key#9){+.+.+.}, at: [<c10aeb45>] do_last+0x165/0x4ff
[ 166.956586] #1: (jbd2_handle){+.+...}, at: [<c112469f>] start_this_handle+0x3c2/0x41e
[ 166.956586]
[ 166.956586] stack backtrace:
[ 166.956586] Pid: 819, comm: sh Not tainted 3.1.0-rc4 #34
[ 166.956586] Call Trace:
[ 166.956586] [<c135f26e>] ? printk+0xf/0x11
[ 166.956586] [<c105223c>] __lock_acquire+0x875/0xbe7
[ 166.956586] [<c1361600>] ? _raw_spin_unlock_irq+0x2d/0x30
[ 166.956586] [<c105183a>] ? mark_lock+0x26/0x1b3
[ 166.956586] [<c105183a>] ? mark_lock+0x26/0x1b3
[ 166.956586] [<c1052944>] lock_acquire+0x59/0x70
[ 166.956586] [<c1101290>] ? ext4_evict_inode+0x17/0x288
[ 166.956586] [<c13601f9>] __mutex_lock_common+0x38/0x2d4
[ 166.956586] [<c1101290>] ? ext4_evict_inode+0x17/0x288
[ 166.956586] [<c1360573>] mutex_lock_nested+0x32/0x3b
[ 166.956586] [<c1101290>] ? ext4_evict_inode+0x17/0x288
[ 166.956586] [<c1101290>] ext4_evict_inode+0x17/0x288
[ 166.956586] [<c10b5f63>] evict+0x7b/0x11c
[ 166.956586] [<c10b6136>] iput+0x132/0x137
[ 166.956586] [<c10fc467>] ext4_new_inode+0xa53/0xa92
[ 166.956586] [<c1108942>] ? ext4_journal_start_sb+0xdd/0xec
[ 166.956586] [<c10b4afb>] ? d_splice_alias+0xa9/0xb1
[ 166.956586] [<c11045ec>] ext4_create+0xa6/0x10b
[ 166.956586] [<c10ae2d7>] vfs_create+0x61/0x7b
[ 166.956586] [<c10aebd7>] do_last+0x1f7/0x4ff
[ 166.956586] [<c10aefa1>] path_openat+0x9d/0x2b7
[ 166.956586] [<c1052636>] ? lock_release_non_nested+0x88/0x1f7
[ 166.956586] [<c10af1f3>] do_filp_open+0x21/0x5d
[ 166.956586] [<c1361666>] ? _raw_spin_unlock+0x1d/0x2a
[ 166.956586] [<c10b78b1>] ? alloc_fd+0xc0/0xcb
[ 166.956586] [<c10a4207>] do_sys_open+0x54/0xcd
[ 166.956586] [<c10a429e>] sys_open+0x1e/0x26
[ 166.956586] [<c1361820>] syscall_call+0x7/0xb
[ 167.175766] end_request: I/O error, dev uba, sector 16534
[ 167.177204] Aborting journal on device uba-8.
[ 167.179255] end_request: I/O error, dev uba, sector 16516
[ 167.179768] Buffer I/O error on device uba, logical block 8258
[ 167.179983] lost page write due to I/O error on uba
[ 167.180866] JBD2: I/O error detected when updating journal superblock for uba-8.
[ 167.181956] journal commit I/O error
[ 167.195334] EXT4-fs error (device uba): ext4_put_super:817: Couldn't clean up the journal
[ 167.195777] EXT4-fs (uba): Remounting filesystem read-only
It appears to be an unrelated error, but worth looking at.
Alan Stern
next prev parent reply other threads:[~2011-09-10 18:07 UTC|newest]
Thread overview: 111+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <bug-25832-13602@https.bugzilla.kernel.org/>
2011-02-03 17:09 ` [Bug 25832] kernel crashes upon resume if usb devices are removed when suspended bugzilla-daemon
2011-02-03 18:22 ` bugzilla-daemon
2011-02-04 6:28 ` bugzilla-daemon
2011-02-04 6:30 ` bugzilla-daemon
2011-02-04 15:31 ` bugzilla-daemon
2011-02-05 8:31 ` bugzilla-daemon
2011-02-05 8:53 ` bugzilla-daemon
2011-02-05 19:12 ` bugzilla-daemon
2011-02-05 19:56 ` bugzilla-daemon
2011-02-05 19:58 ` bugzilla-daemon
2011-02-05 20:53 ` bugzilla-daemon
2011-02-05 23:10 ` bugzilla-daemon
2011-02-06 2:54 ` bugzilla-daemon
2011-02-06 3:44 ` bugzilla-daemon
2011-02-06 4:26 ` bugzilla-daemon
2011-02-06 6:43 ` bugzilla-daemon
2011-02-06 9:00 ` bugzilla-daemon
2011-02-07 1:20 ` bugzilla-daemon
2011-02-07 3:11 ` bugzilla-daemon
2011-02-07 3:32 ` bugzilla-daemon
2011-02-07 3:33 ` bugzilla-daemon
2011-02-07 4:24 ` bugzilla-daemon
2011-02-07 15:36 ` bugzilla-daemon
2011-02-07 23:49 ` bugzilla-daemon
2011-02-19 12:36 ` bugzilla-daemon
2011-02-19 15:55 ` bugzilla-daemon
2011-02-20 0:16 ` bugzilla-daemon
2011-02-21 4:02 ` bugzilla-daemon
2011-02-21 4:08 ` bugzilla-daemon
2011-02-21 8:59 ` bugzilla-daemon
2011-02-21 16:48 ` bugzilla-daemon
2011-02-22 7:03 ` bugzilla-daemon
2011-03-03 15:23 ` bugzilla-daemon
2011-03-06 10:25 ` bugzilla-daemon
2011-03-06 15:59 ` bugzilla-daemon
2011-03-12 6:03 ` bugzilla-daemon
2011-03-12 12:12 ` bugzilla-daemon
2011-03-12 15:51 ` bugzilla-daemon
2011-03-13 0:41 ` bugzilla-daemon
2011-03-13 2:26 ` bugzilla-daemon
2011-03-13 2:45 ` bugzilla-daemon
2011-03-13 3:01 ` bugzilla-daemon
2011-03-13 21:17 ` bugzilla-daemon
2011-03-14 4:10 ` bugzilla-daemon
2011-03-14 14:18 ` bugzilla-daemon
2011-03-24 23:06 ` bugzilla-daemon
2011-03-31 0:44 ` bugzilla-daemon
2011-03-31 0:49 ` bugzilla-daemon
2011-04-01 15:09 ` bugzilla-daemon
2011-04-01 23:58 ` bugzilla-daemon
2011-04-04 2:32 ` bugzilla-daemon
2011-04-04 14:11 ` bugzilla-daemon
2011-04-05 15:17 ` bugzilla-daemon
2011-04-06 23:01 ` bugzilla-daemon
2011-04-22 6:00 ` bugzilla-daemon
2011-04-22 10:13 ` bugzilla-daemon
2011-04-22 10:37 ` bugzilla-daemon
2011-04-22 11:58 ` bugzilla-daemon
2011-04-22 13:42 ` [Bug 25832] kernel crashes when a mounted ext3/4 file system is physically removed bugzilla-daemon
2011-04-22 15:00 ` bugzilla-daemon
2011-04-23 0:32 ` bugzilla-daemon
2011-04-23 4:12 ` bugzilla-daemon
2011-04-23 19:31 ` bugzilla-daemon
2011-04-24 1:35 ` bugzilla-daemon
2011-04-25 0:36 ` bugzilla-daemon
2011-04-25 0:37 ` bugzilla-daemon
2011-04-25 0:39 ` bugzilla-daemon
2011-04-25 20:28 ` bugzilla-daemon
2011-04-26 0:28 ` bugzilla-daemon
2011-04-26 0:44 ` bugzilla-daemon
2011-04-26 1:22 ` bugzilla-daemon
2011-04-26 3:29 ` bugzilla-daemon
2011-04-26 4:02 ` bugzilla-daemon
2011-04-26 18:15 ` bugzilla-daemon
2011-05-03 2:19 ` bugzilla-daemon
2011-05-04 7:36 ` bugzilla-daemon
2011-05-10 23:27 ` bugzilla-daemon
2011-05-26 6:44 ` bugzilla-daemon
2011-05-26 14:27 ` bugzilla-daemon
2011-07-13 7:52 ` bugzilla-daemon
2011-08-31 5:00 ` bugzilla-daemon
2011-08-31 5:07 ` bugzilla-daemon
2011-08-31 14:36 ` bugzilla-daemon
2011-08-31 23:43 ` bugzilla-daemon
2011-09-01 1:30 ` bugzilla-daemon
2011-09-04 3:53 ` bugzilla-daemon
2011-09-04 13:55 ` bugzilla-daemon
2011-09-04 14:00 ` bugzilla-daemon
2011-09-05 17:44 ` bugzilla-daemon
2011-09-09 19:13 ` Ted Ts'o
2011-09-09 22:10 ` Alan Stern
[not found] ` <BAY151-W6176D929049AA9E2BDBAEBA1000@phx.gbl>
2011-09-10 14:06 ` Ted Ts'o
2011-09-10 18:07 ` Alan Stern [this message]
2011-09-12 1:58 ` Alan Stern
2012-07-02 13:24 ` bugzilla-daemon
[not found] <BAY151-W3498E8491E671BDAE90421A1070@phx.gbl>
2011-09-16 16:28 ` Alan Stern
[not found] <BAY151-W1224E6C1A20D179965A149A1090@phx.gbl>
2011-09-17 13:21 ` Alan Stern
[not found] <BAY151-W32DCB4BAFEC97DD4913A12A1090@phx.gbl>
2011-09-17 17:34 ` Alan Stern
2011-09-18 23:00 ` Ben Hutchings
2011-09-20 7:32 ` Jun'ichi Nomura
2011-09-22 12:26 ` Hannes Reinecke
2011-09-22 12:26 ` Hannes Reinecke
2011-09-22 12:35 ` James Bottomley
2011-09-22 15:16 ` Alan Stern
2011-09-22 15:16 ` Alan Stern
2011-09-22 16:20 ` Thadeu Lima de Souza Cascardo
2011-09-22 16:32 ` Hannes Reinecke
2011-09-22 16:32 ` Hannes Reinecke
[not found] <BAY151-W234D9A977DF076A732C2AAA1080@phx.gbl>
2011-09-18 14:43 ` Alan Stern
[not found] <BAY151-W13DDCCEFEB7B68EE506214A10C0@phx.gbl>
2011-09-23 15:18 ` Alan Stern
2011-09-23 15:18 ` Alan Stern
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=Pine.LNX.4.44L0.1109101403400.3905-100000@netrider.rowland.org \
--to=stern@rowland.harvard.edu \
--cc=bugzilla-daemon@bugzilla.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=rockorequin@hotmail.com \
--cc=tytso@mit.edu \
/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.