* [PATCH 3.0-rc3] btrfs: fix oops on failure path
@ 2011-06-19 10:53 Daniel J Blueman
2011-06-23 10:31 ` David Sterba
0 siblings, 1 reply; 5+ messages in thread
From: Daniel J Blueman @ 2011-06-19 10:53 UTC (permalink / raw)
To: Chris Mason; +Cc: Linux BTRFS
I hit this BTRFS oops [1] in 3.0-rc3, clearly due to filesystem corruption.
If lookup_extent_backref fails, path->nodes[0] reasonably could be
null, so look before leaping [2].
Chris, if happy, can you squeeze this into the drop for -rc4 please?
Signed-off-by: Daniel J Blueman <daniel.blueman@gmail.com>
--- [1]
leaf free space ret -1678719553, leaf data size 3995, used 1678723548 nritems 60
parent transid verify failed on 113373184 wanted 31 found 13951
leaf free space ret -1678719553, leaf data size 3995, used 1678723548 nritems 60
leaf free space ret -1678719553, leaf data size 3995, used 1678723548 nritems 60
leaf free space ret -1678719553, leaf data size 3995, used 1678723548 nritems 60
leaf free space ret -1678719553, leaf data size 3995, used 1678723548 nritems 60
BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
IP: [<ffffffff8122d8e8>] btrfs_print_leaf+0x28/0x810
PGD 206386067 PUD 20639e067 PMD 0
Oops: 0000 [#1] SMP
CPU 2
Modules linked in: binfmt_misc kvm_intel kvm microcode arc4 uvcvideo
videodev v4l2_compat_ioctl32 i915 mei(C) iwlagn drm_kms_helper
mac80211 drm i2c_algo_bit video sdhci_pci sdhci mmc_core usb_storage
Pid: 1526, comm: rm Tainted: G C 3.0.0-rc3-340c+ #4 Dell Inc.
Latitude E5420/0H5TG2
RIP: 0010:[<ffffffff8122d8e8>] [<ffffffff8122d8e8>] btrfs_print_leaf+0x28/0x810
RSP: 0018:ffff8802063f7ab8 EFLAGS: 00010286
RAX: 00000000fffffffb RBX: ffff88022dc5de10 RCX: 000000000000af74
RDX: 0000000000000008 RSI: 0000000000000000 RDI: ffff880223f5b000
RBP: ffff8802063f7b48 R08: ffffffff81259152 R09: 0000000000000001
R10: 00000000fffffffb R11: 000000020562a000 R12: 0000000000000005
R13: ffff8802063f7fd8 R14: 0000000000000000 R15: 0000000000001000
FS: 00007f95c55b3720(0000) GS:ffff88022ec40000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000030 CR3: 00000002063ac000 CR4: 00000000000406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process rm (pid: 1526, threadinfo ffff8802063f6000, task ffff880210a15da0)
Stack:
0000000000001000 ffff8802063f7c00 0000000006bb0000 ffffffff8125a124
ffff880223f5b000 0000000000001000 ffff8802063f7b48 ffff88022dc5de10
0000000006bb0000 00000000001000a8 ffff8802063f7b00 ffff880210bb8360
Call Trace:
[<ffffffff8125a124>] ? set_extent_dirty+0x24/0x30
[<ffffffff812261f2>] __btrfs_free_extent+0x672/0x720
[<ffffffff8121bf60>] ? btrfs_del_leaf+0xd0/0x100
[<ffffffff81228ac9>] run_clustered_refs+0x379/0x840
[<ffffffff81279b00>] ? btrfs_find_ref_cluster+0x60/0x190
[<ffffffff81229050>] btrfs_run_delayed_refs+0xc0/0x200
[<ffffffff8123a558>] __btrfs_end_transaction+0x88/0x250
[<ffffffff8123a780>] btrfs_end_transaction+0x10/0x20
[<ffffffff81244420>] btrfs_evict_inode+0x180/0x210
[<ffffffff8110dd2b>] evict+0x7b/0x150
[<ffffffff8110df25>] iput+0xd5/0x1a0
[<ffffffff81103964>] do_unlinkat+0x104/0x1d0
[<ffffffff8112b88b>] ? fsnotify_find_inode_mark+0x2b/0x40
[<ffffffff810f4561>] ? filp_close+0x61/0x90
[<ffffffff81104c5d>] sys_unlinkat+0x1d/0x40
[<ffffffff8165f0fb>] system_call_fastpath+0x16/0x1b
Code: 00 00 00 55 48 89 e5 48 81 ec 90 00 00 00 48 89 5d d8 4c 89 6d
e8 4c 89 65 e0 4c 89 75 f0 4c 89 7d f8 65 4c 8b 2c 25 c8 b5 00 00
8b 46 30 49 81 ed d8 1f 00 00 48 89 f3 41 ff 45 1c 48 ba 00
RIP [<ffffffff8122d8e8>] btrfs_print_leaf+0x28/0x810
RSP <ffff8802063f7ab8>
CR2: 0000000000000030
--- [2]
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index b42efc2..1848f8f 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -4454,7 +4454,8 @@ static int __btrfs_free_extent(struct
btrfs_trans_handle *trans,
extent_slot = path->slots[0];
}
} else {
- btrfs_print_leaf(extent_root, path->nodes[0]);
+ if (path->nodes[0])
+ btrfs_print_leaf(extent_root, path->nodes[0]);
WARN_ON(1);
printk(KERN_ERR "btrfs unable to find ref byte nr %llu "
"parent %llu root %llu owner %llu offset %llu\n",
--
Daniel J Blueman
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH 3.0-rc3] btrfs: fix oops on failure path
2011-06-19 10:53 [PATCH 3.0-rc3] btrfs: fix oops on failure path Daniel J Blueman
@ 2011-06-23 10:31 ` David Sterba
2011-06-23 15:01 ` [PATCH v2] " Daniel J Blueman
0 siblings, 1 reply; 5+ messages in thread
From: David Sterba @ 2011-06-23 10:31 UTC (permalink / raw)
To: Daniel J Blueman; +Cc: Chris Mason, Linux BTRFS
Hi,
On Sun, Jun 19, 2011 at 06:53:28PM +0800, Daniel J Blueman wrote:
> I hit this BTRFS oops [1] in 3.0-rc3, clearly due to filesystem corruption.
>
> If lookup_extent_backref fails, path->nodes[0] reasonably could be
> null, so look before leaping [2].
I think the check should be placed into btrfs_print_leaf, this function
is mostly called before a BUG after some error condition. The
extent_buffer leaf argument could be NULL in more cases (i've seen at
least another 2). Otherwise the if-NULL check would have to be placed
before each call of btrfs_print_leaf.
david
> Chris, if happy, can you squeeze this into the drop for -rc4 please?
>
> Signed-off-by: Daniel J Blueman <daniel.blueman@gmail.com>
>
> --- [1]
>
> leaf free space ret -1678719553, leaf data size 3995, used 1678723548 nritems 60
> parent transid verify failed on 113373184 wanted 31 found 13951
> leaf free space ret -1678719553, leaf data size 3995, used 1678723548 nritems 60
> leaf free space ret -1678719553, leaf data size 3995, used 1678723548 nritems 60
> leaf free space ret -1678719553, leaf data size 3995, used 1678723548 nritems 60
> leaf free space ret -1678719553, leaf data size 3995, used 1678723548 nritems 60
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
> IP: [<ffffffff8122d8e8>] btrfs_print_leaf+0x28/0x810
> PGD 206386067 PUD 20639e067 PMD 0
> Oops: 0000 [#1] SMP
> CPU 2
> Modules linked in: binfmt_misc kvm_intel kvm microcode arc4 uvcvideo
> videodev v4l2_compat_ioctl32 i915 mei(C) iwlagn drm_kms_helper
> mac80211 drm i2c_algo_bit video sdhci_pci sdhci mmc_core usb_storage
>
> Pid: 1526, comm: rm Tainted: G C 3.0.0-rc3-340c+ #4 Dell Inc.
> Latitude E5420/0H5TG2
> RIP: 0010:[<ffffffff8122d8e8>] [<ffffffff8122d8e8>] btrfs_print_leaf+0x28/0x810
> RSP: 0018:ffff8802063f7ab8 EFLAGS: 00010286
> RAX: 00000000fffffffb RBX: ffff88022dc5de10 RCX: 000000000000af74
> RDX: 0000000000000008 RSI: 0000000000000000 RDI: ffff880223f5b000
> RBP: ffff8802063f7b48 R08: ffffffff81259152 R09: 0000000000000001
> R10: 00000000fffffffb R11: 000000020562a000 R12: 0000000000000005
> R13: ffff8802063f7fd8 R14: 0000000000000000 R15: 0000000000001000
> FS: 00007f95c55b3720(0000) GS:ffff88022ec40000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 0000000000000030 CR3: 00000002063ac000 CR4: 00000000000406e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process rm (pid: 1526, threadinfo ffff8802063f6000, task ffff880210a15da0)
> Stack:
> 0000000000001000 ffff8802063f7c00 0000000006bb0000 ffffffff8125a124
> ffff880223f5b000 0000000000001000 ffff8802063f7b48 ffff88022dc5de10
> 0000000006bb0000 00000000001000a8 ffff8802063f7b00 ffff880210bb8360
> Call Trace:
> [<ffffffff8125a124>] ? set_extent_dirty+0x24/0x30
> [<ffffffff812261f2>] __btrfs_free_extent+0x672/0x720
> [<ffffffff8121bf60>] ? btrfs_del_leaf+0xd0/0x100
> [<ffffffff81228ac9>] run_clustered_refs+0x379/0x840
> [<ffffffff81279b00>] ? btrfs_find_ref_cluster+0x60/0x190
> [<ffffffff81229050>] btrfs_run_delayed_refs+0xc0/0x200
> [<ffffffff8123a558>] __btrfs_end_transaction+0x88/0x250
> [<ffffffff8123a780>] btrfs_end_transaction+0x10/0x20
> [<ffffffff81244420>] btrfs_evict_inode+0x180/0x210
> [<ffffffff8110dd2b>] evict+0x7b/0x150
> [<ffffffff8110df25>] iput+0xd5/0x1a0
> [<ffffffff81103964>] do_unlinkat+0x104/0x1d0
> [<ffffffff8112b88b>] ? fsnotify_find_inode_mark+0x2b/0x40
> [<ffffffff810f4561>] ? filp_close+0x61/0x90
> [<ffffffff81104c5d>] sys_unlinkat+0x1d/0x40
> [<ffffffff8165f0fb>] system_call_fastpath+0x16/0x1b
> Code: 00 00 00 55 48 89 e5 48 81 ec 90 00 00 00 48 89 5d d8 4c 89 6d
> e8 4c 89 65 e0 4c 89 75 f0 4c 89 7d f8 65 4c 8b 2c 25 c8 b5 00 00
> 8b 46 30 49 81 ed d8 1f 00 00 48 89 f3 41 ff 45 1c 48 ba 00
> RIP [<ffffffff8122d8e8>] btrfs_print_leaf+0x28/0x810
> RSP <ffff8802063f7ab8>
> CR2: 0000000000000030
>
> --- [2]
>
> diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
> index b42efc2..1848f8f 100644
> --- a/fs/btrfs/extent-tree.c
> +++ b/fs/btrfs/extent-tree.c
> @@ -4454,7 +4454,8 @@ static int __btrfs_free_extent(struct
> btrfs_trans_handle *trans,
> extent_slot = path->slots[0];
> }
> } else {
> - btrfs_print_leaf(extent_root, path->nodes[0]);
> + if (path->nodes[0])
> + btrfs_print_leaf(extent_root, path->nodes[0]);
> WARN_ON(1);
> printk(KERN_ERR "btrfs unable to find ref byte nr %llu "
> "parent %llu root %llu owner %llu offset %llu\n",
> --
> Daniel J Blueman
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH v2] btrfs: fix oops on failure path
2011-06-23 10:31 ` David Sterba
@ 2011-06-23 15:01 ` Daniel J Blueman
2011-06-23 16:36 ` David Sterba
0 siblings, 1 reply; 5+ messages in thread
From: Daniel J Blueman @ 2011-06-23 15:01 UTC (permalink / raw)
To: dave, Chris Mason; +Cc: Linux BTRFS
On 23 June 2011 18:31, David Sterba <dave@jikos.cz> wrote:
> Hi,
>
> On Sun, Jun 19, 2011 at 06:53:28PM +0800, Daniel J Blueman wrote:
>> I hit this BTRFS oops [1] in 3.0-rc3, clearly due to filesystem corruption.
>>
>> If lookup_extent_backref fails, path->nodes[0] reasonably could be
>> null, so look before leaping [2].
> I think the check should be placed into btrfs_print_leaf, this function
> is mostly called before a BUG after some error condition. The
> extent_buffer leaf argument could be NULL in more cases (i've seen at
> least another 2). Otherwise the if-NULL check would have to be placed
> before each call of btrfs_print_leaf.
The other cases where btrfs_print_leaf can be called with NULL are a
good reason. Updated patch:
(how does one follow up an email in git send-email with the message id?)
If lookup_extent_backref fails, path->nodes[0] reasonably could be
null along with other callers of btrfs_print_leaf, so ensure we have a
valid extent buffer before dereferencing.
Signed-off-by: Daniel J Blueman <daniel.blueman@gmail.com>
diff --git a/fs/btrfs/print-tree.c b/fs/btrfs/print-tree.c
index fb2605d..f38e452 100644
--- a/fs/btrfs/print-tree.c
+++ b/fs/btrfs/print-tree.c
@@ -158,8 +158,7 @@ static void print_extent_ref_v0(struct
extent_buffer *eb, int slot)
void btrfs_print_leaf(struct btrfs_root *root, struct extent_buffer *l)
{
int i;
- u32 type;
- u32 nr = btrfs_header_nritems(l);
+ u32 type, nr;
struct btrfs_item *item;
struct btrfs_root_item *ri;
struct btrfs_dir_item *di;
@@ -172,6 +171,11 @@ void btrfs_print_leaf(struct btrfs_root *root,
struct extent_buffer *l)
struct btrfs_key key;
struct btrfs_key found_key;
+ if (!l)
+ return;
+
+ nr = btrfs_header_nritems(l);
+
printk(KERN_INFO "leaf %llu total ptrs %d free space %d\n",
(unsigned long long)btrfs_header_bytenr(l), nr,
btrfs_leaf_free_space(root, l));
--
Daniel J Blueman
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH v2] btrfs: fix oops on failure path
2011-06-23 15:01 ` [PATCH v2] " Daniel J Blueman
@ 2011-06-23 16:36 ` David Sterba
2011-06-27 22:27 ` Mitch Harder
0 siblings, 1 reply; 5+ messages in thread
From: David Sterba @ 2011-06-23 16:36 UTC (permalink / raw)
To: Daniel J Blueman; +Cc: dave, Chris Mason, Linux BTRFS
On Thu, Jun 23, 2011 at 11:01:01PM +0800, Daniel J Blueman wrote:
> On 23 June 2011 18:31, David Sterba <dave@jikos.cz> wrote:
> (how does one follow up an email in git send-email with the message id?)
git-send-email --in-reply-to=<identifier>
(if it does not ask for it) and paste identifier from mail header
In-Reply-To:
> If lookup_extent_backref fails, path->nodes[0] reasonably could be
> null along with other callers of btrfs_print_leaf, so ensure we have a
> valid extent buffer before dereferencing.
ack.
thanks,
david
>
> Signed-off-by: Daniel J Blueman <daniel.blueman@gmail.com>
>
> diff --git a/fs/btrfs/print-tree.c b/fs/btrfs/print-tree.c
> index fb2605d..f38e452 100644
> --- a/fs/btrfs/print-tree.c
> +++ b/fs/btrfs/print-tree.c
> @@ -158,8 +158,7 @@ static void print_extent_ref_v0(struct
> extent_buffer *eb, int slot)
> void btrfs_print_leaf(struct btrfs_root *root, struct extent_buffer *l)
> {
> int i;
> - u32 type;
> - u32 nr = btrfs_header_nritems(l);
> + u32 type, nr;
> struct btrfs_item *item;
> struct btrfs_root_item *ri;
> struct btrfs_dir_item *di;
> @@ -172,6 +171,11 @@ void btrfs_print_leaf(struct btrfs_root *root,
> struct extent_buffer *l)
> struct btrfs_key key;
> struct btrfs_key found_key;
>
> + if (!l)
> + return;
> +
> + nr = btrfs_header_nritems(l);
> +
> printk(KERN_INFO "leaf %llu total ptrs %d free space %d\n",
> (unsigned long long)btrfs_header_bytenr(l), nr,
> btrfs_leaf_free_space(root, l));
> --
> Daniel J Blueman
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v2] btrfs: fix oops on failure path
2011-06-23 16:36 ` David Sterba
@ 2011-06-27 22:27 ` Mitch Harder
0 siblings, 0 replies; 5+ messages in thread
From: Mitch Harder @ 2011-06-27 22:27 UTC (permalink / raw)
To: dave, Daniel J Blueman, Chris Mason, Linux BTRFS
On Thu, Jun 23, 2011 at 11:36 AM, David Sterba <dave@jikos.cz> wrote:
> On Thu, Jun 23, 2011 at 11:01:01PM +0800, Daniel J Blueman wrote:
>> On 23 June 2011 18:31, David Sterba <dave@jikos.cz> wrote:
>> (how does one follow up an email in git send-email with the message =
id?)
>
> git-send-email --in-reply-to=3D<identifier>
>
> (if it does not ask for it) and paste identifier from mail header
> In-Reply-To:
>
>> If lookup_extent_backref fails, path->nodes[0] reasonably could be
>> null along with other callers of btrfs_print_leaf, so ensure we have=
a
>> valid extent buffer before dereferencing.
>
> ack.
>
>
> thanks,
> david
>
>>
>> Signed-off-by: Daniel J Blueman <daniel.blueman@gmail.com>
>>
>> diff --git a/fs/btrfs/print-tree.c b/fs/btrfs/print-tree.c
>> index fb2605d..f38e452 100644
>> --- a/fs/btrfs/print-tree.c
>> +++ b/fs/btrfs/print-tree.c
>> @@ -158,8 +158,7 @@ static void print_extent_ref_v0(struct
>> extent_buffer *eb, int slot)
>> =A0void btrfs_print_leaf(struct btrfs_root *root, struct extent_buff=
er *l)
>> =A0{
>> =A0 =A0 =A0 int i;
>> - =A0 =A0 u32 type;
>> - =A0 =A0 u32 nr =3D btrfs_header_nritems(l);
>> + =A0 =A0 u32 type, nr;
>> =A0 =A0 =A0 struct btrfs_item *item;
>> =A0 =A0 =A0 struct btrfs_root_item *ri;
>> =A0 =A0 =A0 struct btrfs_dir_item *di;
>> @@ -172,6 +171,11 @@ void btrfs_print_leaf(struct btrfs_root *root,
>> struct extent_buffer *l)
>> =A0 =A0 =A0 struct btrfs_key key;
>> =A0 =A0 =A0 struct btrfs_key found_key;
>>
>> + =A0 =A0 if (!l)
>> + =A0 =A0 =A0 =A0 =A0 =A0 return;
>> +
>> + =A0 =A0 nr =3D btrfs_header_nritems(l);
>> +
>> =A0 =A0 =A0 printk(KERN_INFO "leaf %llu total ptrs %d free space %d\=
n",
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 (unsigned long long)btrfs_header_bytenr(=
l), nr,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 btrfs_leaf_free_space(root, l));
>> --
>> Daniel J Blueman
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs=
" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
>
I've also run into a corruption with spots where path->nodes[0] has a
value of NULL.
But, I'm getting the error showing up elsewhere when I try to mount
the partition:
[ 6168.790849] device fsid 7c35237f-d72a-4d65-bd01-b853d853c17a devid
1 transid 507394 /dev/sdb6
[ 6168.832825] attempt to access beyond end of device
[ 6168.832831] sdb6: rw=3D0, want=3D20033720, limit=3D20016927
[ 6168.832843] Failed to read block groups: -5
[ 6168.833663] btrfs: open_ctree failed
In my case, I need to handle the corruption earlier in order to
properly handle the error.
Btrfs-progs also has troubles handling this corruption (debugging
btrfsck was how I discovered I was running into path->nodes[0] =3D=3D
NULL).
=46or reference, I'm using a 2.6.39.1 kernel with Chris' latest
'for-linus' branch merged in.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-06-27 22:27 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-06-19 10:53 [PATCH 3.0-rc3] btrfs: fix oops on failure path Daniel J Blueman
2011-06-23 10:31 ` David Sterba
2011-06-23 15:01 ` [PATCH v2] " Daniel J Blueman
2011-06-23 16:36 ` David Sterba
2011-06-27 22:27 ` Mitch Harder
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).