crash when mounting

2008-08-02 Thread Ahmed Kamal 
Hi guys,
I was playing on vmware with btrfs on complete disks /dev/sd{b,c,d,e}.
Next I decided to use partitions, so I created /dev/sd{b,c,d,e}1 and
used those, worked fine! Afterward, I mistakenly re-ran an old command
on the full disk ( mount -t btrfs -o subvol=. /dev/sdb /mnt/ ) notice
this is sdb not sdb1, and I got this spectacular kernel freeze. Let me
know if that's some bug.
Thanks

[EMAIL PROTECTED] tests]# mount -t btrfs -o subvol=. /dev/sdb /mnt/

Message from [EMAIL PROTECTED] at Aug  3 05:09:33 ...
 kernel: [ cut here ]

Message from [EMAIL PROTECTED] at Aug  3 05:09:33 ...
 kernel: invalid opcode:  [#1] SMP
Segmentation fault
[EMAIL PROTECTED] tests]#
Message from [EMAIL PROTECTED] at Aug  3 05:09:33 ...
 kernel: Process mount (pid: 18986, ti=dc539000 task=ded4ae70 task.ti=dc539000)

Message from [EMAIL PROTECTED] at Aug  3 05:09:33 ...
 kernel: Stack: e0dc9e73 01c7b000  1000  c1407134
c140a6bc 

Message from [EMAIL PROTECTED] at Aug  3 05:09:33 ...
 kernel:0282 00011220 df436880 00011270  c846e118
c846e120 c0463c6b

Message from [EMAIL PROTECTED] at Aug  3 05:09:33 ...
 kernel:dc539c40 c0463ed0  00011270 dc539c68 dc539c78
e0dc23a6 01c7b000

Message from [EMAIL PROTECTED] at Aug  3 05:09:33 ...
 kernel: Call Trace:

Message from [EMAIL PROTECTED] at Aug  3 05:09:33 ...
 kernel:  [mempool_alloc_slab+14/16] ? mempool_alloc_slab+0xe/0x10

Message from [EMAIL PROTECTED] at Aug  3 05:09:33 ...
 kernel:  [mempool_alloc+66/224] ? mempool_alloc+0x42/0xe0

Message from [EMAIL PROTECTED] at Aug  3 05:09:33 ...
 kernel:  [] ? set_extent_bit+0xa3/0x337 [btrfs]

Message from [EMAIL PROTECTED] at Aug  3 05:09:33 ...
 kernel:  [bio_add_page+39/46] ? bio_add_page+0x27/0x2e

Message from [EMAIL PROTECTED] at Aug  3 05:09:33 ...
 kernel:  [] ? btrfs_map_block+0x19/0x1b [btrfs]

Message from [EMAIL PROTECTED] at Aug  3 05:09:33 ...
 kernel:  [] ? btrfs_map_bio+0x5d/0x1b7 [btrfs]
Message from [EMAIL PROTECTED] at Aug  3 05:09:33 ...
 kernel:  [] ? end_bio_extent_readpage+0x0/0x339 [btrfs]

Message from [EMAIL PROTECTED] at Aug  3 05:09:33 ...
 kernel:  [] ? __btree_submit_bio_hook+0x42/0x4b [btrfs]

Message from [EMAIL PROTECTED] at Aug  3 05:09:33 ...
 kernel:  [] ? btree_submit_bio_hook+0x15/0x3b [btrfs]

Message from [EMAIL PROTECTED] at Aug  3 05:09:33 ...
 kernel:  [] ? btree_submit_bio_hook+0x0/0x3b [btrfs]

Message from [EMAIL PROTECTED] at Aug  3 05:09:33 ...
 kernel:  [] ? submit_one_bio+0xdf/0x10c [btrfs]

Message from [EMAIL PROTECTED] at Aug  3 05:09:33 ...
 kernel:  [] ? read_extent_buffer_pages+0x276/0x3c6 [btrfs]

Message from [EMAIL PROTECTED] at Aug  3 05:09:33 ...
 kernel:  [] ? add_lru+0x22/0x69 [btrfs]

Message from [EMAIL PROTECTED] at Aug  3 05:09:33 ...
 kernel:  [] ? btree_read_extent_buffer_pages+0x3a/0x8e [btrfs]

Message from [EMAIL PROTECTED] at Aug  3 05:09:33 ...
 kernel:  [] ? btree_get_extent+0x0/0x1cd [btrfs]

Message from [EMAIL PROTECTED] at Aug  3 05:09:33 ...
 kernel:  [] ? read_tree_block+0x3e/0x52 [btrfs]

Message from [EMAIL PROTECTED] at Aug  3 05:09:33 ...
 kernel:  [] ? open_ctree+0x6d4/0x825 [btrfs]

Message from [EMAIL PROTECTED] at Aug  3 05:09:33 ...
 kernel:  [] ? btrfs_get_sb_bdev+0x103/0x284 [btrfs]

Message from [EMAIL PROTECTED] at Aug  3 05:09:33 ...
 kernel:  [] ? btrfs_parse_options+0x261/0x26e [btrfs]

Message from [EMAIL PROTECTED] at Aug  3 05:09:33 ...
 kernel:  [] ? btrfs_get_sb+0x44/0x60 [btrfs]

Message from [EMAIL PROTECTED] at Aug  3 05:09:33 ...
 kernel:  [vfs_kern_mount+130/245] ? vfs_kern_mount+0x82/0xf5
Message from [EMAIL PROTECTED] at Aug  3 05:09:33 ...
 kernel:  [do_kern_mount+50/186] ? do_kern_mount+0x32/0xba

Message from [EMAIL PROTECTED] at Aug  3 05:09:33 ...
 kernel:  [do_new_mount+66/108] ? do_new_mount+0x42/0x6c

Message from [EMAIL PROTECTED] at Aug  3 05:09:33 ...
 kernel:  [do_mount+420/450] ? do_mount+0x1a4/0x1c2

Message from [EMAIL PROTECTED] at Aug  3 05:09:33 ...
 kernel:  [__get_free_pages+72/79] ? __get_free_pages+0x48/0x4f

Message from [EMAIL PROTECTED] at Aug  3 05:09:33 ...
 kernel:  [copy_mount_options+42/249] ? copy_mount_options+0x2a/0xf9

Message from [EMAIL PROTECTED] at Aug  3 05:09:33 ...
 kernel:  [sys_mount+102/158] ? sys_mount+0x66/0x9e

Message from [EMAIL PROTECTED] at Aug  3 05:09:33 ...
 kernel:  [syscall_call+7/11] ? syscall_call+0x7/0xb

Message from [EMAIL PROTECTED] at Aug  3 05:09:33 ...
 kernel:  ===

Message from [EMAIL PROTECTED] at Aug  3 05:09:33 ...
 kernel: Code: 7d 1c 00 0f 95 45 93 84 c0 74 27 31 c0 80 7d 93 00 0f
85 0c 04 00 00 8b 55 10 ff 72 04 ff 32 57 56 68 73 9e dc e0 e8 38 91
86 df <0f> 0b 83 c4 14 eb fe 8b 4d ac 8b 51 10 8b 41 0c 39 fa 77 23 72

Message from [EMAIL PROTECTED] at Aug  3 05:09:33 ...
 kernel: EIP: [] __btrfs_map_block+0xe1/0x4e1 [btrfs] SS:ESP
0068:dc539bd0
ls /
bin  boot  dev  etc  home  lib  lost+found  media  mnt  opt  proc
root  sbin  selinux  srv  sys  tmp

Re: crash when mounting

2008-08-04 Thread Chris Mason 
On Sun, 2008-08-03 at 02:12 +0300, Ahmed Kamal wrote:
> Hi guys,
> I was playing on vmware with btrfs on complete disks /dev/sd{b,c,d,e}.
> Next I decided to use partitions, so I created /dev/sd{b,c,d,e}1 and
> used those, worked fine! Afterward, I mistakenly re-ran an old command
> on the full disk ( mount -t btrfs -o subvol=. /dev/sdb /mnt/ ) notice
> this is sdb not sdb1, and I got this spectacular kernel freeze. Let me
> know if that's some bug.

It would be nice if we didn't oops, there is clearly some hardening to
do in the failure paths for corrupt filesystems.

-chris


--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: crash when mounting

2008-08-04 Thread Ahmed Kamal 
Well, yeah sure. But I was kind of hoping my playing/testing is going
to help you guys fix it. So, does that traceback help you pin point
the problem ? If not, is there anything I can do, to help with that ?
I believe this crash should be re-producible .. haven't tested that
though

Regards

On Mon, Aug 4, 2008 at 3:47 PM, Chris Mason <[EMAIL PROTECTED]> wrote:
> On Sun, 2008-08-03 at 02:12 +0300, Ahmed Kamal wrote:
>> Hi guys,
>> I was playing on vmware with btrfs on complete disks /dev/sd{b,c,d,e}.
>> Next I decided to use partitions, so I created /dev/sd{b,c,d,e}1 and
>> used those, worked fine! Afterward, I mistakenly re-ran an old command
>> on the full disk ( mount -t btrfs -o subvol=. /dev/sdb /mnt/ ) notice
>> this is sdb not sdb1, and I got this spectacular kernel freeze. Let me
>> know if that's some bug.
>
> It would be nice if we didn't oops, there is clearly some hardening to
> do in the failure paths for corrupt filesystems.
>
> -chris
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: crash when mounting

2008-08-04 Thread Chris Mason 
On Mon, 2008-08-04 at 15:59 +0300, Ahmed Kamal wrote:
> Well, yeah sure. But I was kind of hoping my playing/testing is going
> to help you guys fix it. So, does that traceback help you pin point
> the problem ? If not, is there anything I can do, to help with that ?
> I believe this crash should be re-producible .. haven't tested that
> though
> 

Yes, it shows which part is broken ;)  This one won't be hard to trigger
or fix, it is just part of a larger effort to fixup handling bad data on
disk.

-chris


--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

crash when mounting subvolume in a subdirectory

2010-12-06 Thread Michael Niederle 
Hi!

I'm not sure whether this *should* be possible, but I think it *shouldn't*
crash:

I created a snapshot of the root directory within a subdirectory:

# mount /dev/sde2 /mnt
# cd /mnt
# mkdir save
# btrfs subvolume snapshot . save/snap1
# umount /mnt

Then I tried to mount the snapshot:

# mount -o subvol=save/snap1 /dev/sde2 /mnt

This inevitably leads to a segfault in the btrfs-driver crashing the whole
system. I tried this with kernel versions 2.6.32 and 2.6.37.rc4.

If I create the subvolume within the root directory of the btrfs volume
everything works fine.

I'm using btrfs for nearly a year by now (since the release of 2.6.32) and am
using subvolumes within subdirectories since then but never tried to directly
mount one until today, when my main btrfs volume crashed (by a hardware failure
or due to a bug in 2.6.36 - I don't know).

If you cannot reproduce this behaviour I can try to send you the kernel log
(not so easy, because the system crashes and I will have to write it down by
hand).

Greetings, Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: crash when mounting subvolume in a subdirectory

2010-12-06 Thread Li Zefan 
Michael Niederle wrote:
> Hi!
> 
> I'm not sure whether this *should* be possible, but I think it *shouldn't*
> crash:
> 
> I created a snapshot of the root directory within a subdirectory:
> 
> # mount /dev/sde2 /mnt
> # cd /mnt
> # mkdir save
> # btrfs subvolume snapshot . save/snap1
> # umount /mnt
> 
> Then I tried to mount the snapshot:
> 
> # mount -o subvol=save/snap1 /dev/sde2 /mnt
> 
> This inevitably leads to a segfault in the btrfs-driver crashing the whole
> system. I tried this with kernel versions 2.6.32 and 2.6.37.rc4.
> 
> If I create the subvolume within the root directory of the btrfs volume
> everything works fine.
> 
> I'm using btrfs for nearly a year by now (since the release of 2.6.32) and am
> using subvolumes within subdirectories since then but never tried to directly
> mount one until today, when my main btrfs volume crashed (by a hardware 
> failure
> or due to a bug in 2.6.36 - I don't know).
> 
> If you cannot reproduce this behaviour I can try to send you the kernel log
> (not so easy, because the system crashes and I will have to write it down by
> hand).

It's currently not allowed to mount a subvolume which is not created in
the root directory of the default subvolume, so you should have failed
to mount, but you hit a bug..

I've fixed it, and will send out the patch in minutes.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: crash when mounting subvolume in a subdirectory

2010-12-06 Thread C Anthony Risinger 
On Mon, Dec 6, 2010 at 7:40 PM, Li Zefan  wrote:
> Michael Niederle wrote:
>> Hi!
>>
>> I'm not sure whether this *should* be possible, but I think it *shouldn't*
>> crash:
>
> It's currently not allowed to mount a subvolume which is not created in
> the root directory of the default subvolume, so you should have failed
> to mount, but you hit a bug..
>
> I've fixed it, and will send out the patch in minutes.

i did the same thing, except for a slightly different reason and
slightly more accidentally on purpose:

http://www.spinics.net/lists/linux-btrfs/msg07190.html

but, i ended up with a corrupted FS (that i still have a dump of,
happily waiting for a way to mount it... *hint* :-) so if your are
still up and running then luck is on your side, and don't do it again
;-)

C Anthony
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Btrfs: Fix a crash when mounting a subvolume

2010-12-06 Thread Li Zefan 
We should drop dentry before deactivating the superblock, otherwise
we can hit this bug:

BUG: Dentry f349a690{i=100,n=/} still in use (1) [unmount of btrfs loop1]
...

Steps to reproduce the bug:

  # mount /dev/loop1 /mnt
  # mkdir save
  # btrfs subvolume snapshot /mnt save/snap1
  # umount /mnt
  # mount -o subvol=save/snap1 /dev/loop1 /mnt
  (crash)

Reported-by: Michael Niederle 
Signed-off-by: Li Zefan 
---
 fs/btrfs/super.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 47bf67c..61bd79a 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -685,9 +685,9 @@ static int btrfs_get_sb(struct file_system_type *fs_type, 
int flags,
mutex_unlock(&root->d_inode->i_mutex);
 
if (IS_ERR(new_root)) {
+   dput(root);
deactivate_locked_super(s);
error = PTR_ERR(new_root);
-   dput(root);
goto error_free_subvol_name;
}
if (!new_root->d_inode) {
-- 
1.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Btrfs: Fix a crash when mounting a subvolume

2010-12-06 Thread C Anthony Risinger 
On Mon, Dec 6, 2010 at 7:51 PM, Li Zefan  wrote:
> We should drop dentry before deactivating the superblock, otherwise
> we can hit this bug:
>
> BUG: Dentry f349a690{i=100,n=/} still in use (1) [unmount of btrfs loop1]
> ...
>
> Steps to reproduce the bug:
>
>  # mount /dev/loop1 /mnt
>  # mkdir save
>  # btrfs subvolume snapshot /mnt save/snap1
>  # umount /mnt
>  # mount -o subvol=save/snap1 /dev/loop1 /mnt
>  (crash)
>
> Reported-by: Michael Niederle 
> Signed-off-by: Li Zefan 
> ---
>  fs/btrfs/super.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
> index 47bf67c..61bd79a 100644
> --- a/fs/btrfs/super.c
> +++ b/fs/btrfs/super.c
> @@ -685,9 +685,9 @@ static int btrfs_get_sb(struct file_system_type *fs_type, 
> int flags,
>                mutex_unlock(&root->d_inode->i_mutex);
>
>                if (IS_ERR(new_root)) {
> +                       dput(root);
>                        deactivate_locked_super(s);
>                        error = PTR_ERR(new_root);
> -                       dput(root);
>                        goto error_free_subvol_name;
>                }
>                if (!new_root->d_inode) {
> --

this seems very reasonable to me... more than once i have wanted to be
able to mount in this way (while working out system rollback schemes
in particular; mount by name doesn't care what the ID is).  what's the
possibility of a patch to mount an arbitrarily nested subvol?

btw, patch posted regarding the above:

http://www.spinics.net/lists/linux-btrfs/msg07191.html

though as author noted, needs overview by more experienced eyes.

C Anthony
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Btrfs: Fix a crash when mounting a subvolume

2010-12-06 Thread Li Zefan 
C Anthony Risinger wrote:
> On Mon, Dec 6, 2010 at 7:51 PM, Li Zefan  wrote:
>> We should drop dentry before deactivating the superblock, otherwise
>> we can hit this bug:
>>
>> BUG: Dentry f349a690{i=100,n=/} still in use (1) [unmount of btrfs loop1]
>> ...
>>
>> Steps to reproduce the bug:
>>
>>  # mount /dev/loop1 /mnt
>>  # mkdir save
>>  # btrfs subvolume snapshot /mnt save/snap1
>>  # umount /mnt
>>  # mount -o subvol=save/snap1 /dev/loop1 /mnt
>>  (crash)
>>
>> Reported-by: Michael Niederle 
>> Signed-off-by: Li Zefan 
>> ---
>>  fs/btrfs/super.c |2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
>> index 47bf67c..61bd79a 100644
>> --- a/fs/btrfs/super.c
>> +++ b/fs/btrfs/super.c
>> @@ -685,9 +685,9 @@ static int btrfs_get_sb(struct file_system_type 
>> *fs_type, int flags,
>>mutex_unlock(&root->d_inode->i_mutex);
>>
>>if (IS_ERR(new_root)) {
>> +   dput(root);
>>deactivate_locked_super(s);
>>error = PTR_ERR(new_root);
>> -   dput(root);
>>goto error_free_subvol_name;
>>}
>>if (!new_root->d_inode) {
>> --
> 
> this seems very reasonable to me... more than once i have wanted to be
> able to mount in this way (while working out system rollback schemes
> in particular; mount by name doesn't care what the ID is).  what's the
> possibility of a patch to mount an arbitrarily nested subvol?
> 

I guess it's just because not many people cared much about this, and
no one coded it up?

> btw, patch posted regarding the above:
> 
> http://www.spinics.net/lists/linux-btrfs/msg07191.html
> 
> though as author noted, needs overview by more experienced eyes.
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Btrfs: fix crash when mounting raid5 btrfs with missing disks

2014-06-24 Thread Liu Bo 
The reproducer is

$ mkfs.btrfs D1 D2 D3 -mraid5
$ mkfs.ext4 D2 && mkfs.ext4 D3
$ mount D1 /btrfs -odegraded

---

[   87.672992] [ cut here ]
[   87.673845] kernel BUG at fs/btrfs/raid56.c:1828!
...
[   87.673845] RIP: 0010:[]  [] 
__raid_recover_end_io+0x4ae/0x4d0
...
[   87.673845] Call Trace:
[   87.673845]  [] ? mempool_free+0x36/0xa0
[   87.673845]  [] raid_recover_end_io+0x75/0xa0
[   87.673845]  [] bio_endio+0x5b/0xa0
[   87.673845]  [] bio_endio_nodec+0x12/0x20
[   87.673845]  [] end_workqueue_fn+0x41/0x50
[   87.673845]  [] normal_work_helper+0xca/0x2c0
[   87.673845]  [] process_one_work+0x1eb/0x530
[   87.673845]  [] ? process_one_work+0x189/0x530
[   87.673845]  [] worker_thread+0x11b/0x4f0
[   87.673845]  [] ? rescuer_thread+0x290/0x290
[   87.673845]  [] kthread+0xe4/0x100
[   87.673845]  [] ? kthread_create_on_node+0x220/0x220
[   87.673845]  [] ret_from_fork+0x7c/0xb0
[   87.673845]  [] ? kthread_create_on_node+0x220/0x220

---

It's because that we miscalculate @rbio->bbio->error so that it doesn't
reach maximum of tolerable errors while it should have.

Signed-off-by: Liu Bo 
---
 fs/btrfs/raid56.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/raid56.c b/fs/btrfs/raid56.c
index 4055291..4a88f07 100644
--- a/fs/btrfs/raid56.c
+++ b/fs/btrfs/raid56.c
@@ -1956,9 +1956,10 @@ static int __raid56_parity_recover(struct btrfs_raid_bio 
*rbio)
 * pages are going to be uptodate.
 */
for (stripe = 0; stripe < bbio->num_stripes; stripe++) {
-   if (rbio->faila == stripe ||
-   rbio->failb == stripe)
+   if (rbio->faila == stripe || rbio->failb == stripe) {
+   atomic_inc(&rbio->bbio->error);
continue;
+   }
 
for (pagenr = 0; pagenr < nr_pages; pagenr++) {
struct page *p;
-- 
1.8.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Btrfs: fix crash when mounting raid5 btrfs with missing disks

2014-06-25 Thread Satoru Takeuchi 
Hi Liu,

(2014/06/24 16:39), Liu Bo wrote:
> The reproducer is
> 
> $ mkfs.btrfs D1 D2 D3 -mraid5
> $ mkfs.ext4 D2 && mkfs.ext4 D3
> $ mount D1 /btrfs -odegraded

Tested-by: Satoru Takeuchi

Here is the result of the last mount.

===
...
mount: wrong fs type, bad option, bad superblock on /dev/vdb1,
   missing codepage or helper program, or other error

   In some cases useful info is found in syslog - try
   dmesg | tail or so.
===

It "correctly" failed :-)

Thanks,
Satoru

> 
> ---
> 
> [   87.672992] [ cut here ]
> [   87.673845] kernel BUG at fs/btrfs/raid56.c:1828!
> ...
> [   87.673845] RIP: 0010:[]  [] 
> __raid_recover_end_io+0x4ae/0x4d0
> ...
> [   87.673845] Call Trace:
> [   87.673845]  [] ? mempool_free+0x36/0xa0
> [   87.673845]  [] raid_recover_end_io+0x75/0xa0
> [   87.673845]  [] bio_endio+0x5b/0xa0
> [   87.673845]  [] bio_endio_nodec+0x12/0x20
> [   87.673845]  [] end_workqueue_fn+0x41/0x50
> [   87.673845]  [] normal_work_helper+0xca/0x2c0
> [   87.673845]  [] process_one_work+0x1eb/0x530
> [   87.673845]  [] ? process_one_work+0x189/0x530
> [   87.673845]  [] worker_thread+0x11b/0x4f0
> [   87.673845]  [] ? rescuer_thread+0x290/0x290
> [   87.673845]  [] kthread+0xe4/0x100
> [   87.673845]  [] ? kthread_create_on_node+0x220/0x220
> [   87.673845]  [] ret_from_fork+0x7c/0xb0
> [   87.673845]  [] ? kthread_create_on_node+0x220/0x220
> 
> ---
> 
> It's because that we miscalculate @rbio->bbio->error so that it doesn't
> reach maximum of tolerable errors while it should have.
> 
> Signed-off-by: Liu Bo 
> ---
>   fs/btrfs/raid56.c | 5 +++--
>   1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/btrfs/raid56.c b/fs/btrfs/raid56.c
> index 4055291..4a88f07 100644
> --- a/fs/btrfs/raid56.c
> +++ b/fs/btrfs/raid56.c
> @@ -1956,9 +1956,10 @@ static int __raid56_parity_recover(struct 
> btrfs_raid_bio *rbio)
>* pages are going to be uptodate.
>*/
>   for (stripe = 0; stripe < bbio->num_stripes; stripe++) {
> - if (rbio->faila == stripe ||
> - rbio->failb == stripe)
> + if (rbio->faila == stripe || rbio->failb == stripe) {
> + atomic_inc(&rbio->bbio->error);
>   continue;
> + }
>   
>   for (pagenr = 0; pagenr < nr_pages; pagenr++) {
>   struct page *p;
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Btrfs: fix crash when mounting raid5 btrfs with missing disks

2014-06-25 Thread Liu Bo 
Hi Satoru,

On Wed, Jun 25, 2014 at 04:25:01PM +0900, Satoru Takeuchi wrote:
> Hi Liu,
> 
> (2014/06/24 16:39), Liu Bo wrote:
> > The reproducer is
> > 
> > $ mkfs.btrfs D1 D2 D3 -mraid5
> > $ mkfs.ext4 D2 && mkfs.ext4 D3
> > $ mount D1 /btrfs -odegraded
> 
> Tested-by: Satoru Takeuchi
> 
> Here is the result of the last mount.
> 
> ===
> ...
> mount: wrong fs type, bad option, bad superblock on /dev/vdb1,
>missing codepage or helper program, or other error
> 
>In some cases useful info is found in syslog - try
>dmesg | tail or so.
> ===
> 
> It "correctly" failed :-)

Thanks for testing it :)

thanks,
-liubo

> 
> Thanks,
> Satoru
> 
> > 
> > ---
> > 
> > [   87.672992] [ cut here ]
> > [   87.673845] kernel BUG at fs/btrfs/raid56.c:1828!
> > ...
> > [   87.673845] RIP: 0010:[]  [] 
> > __raid_recover_end_io+0x4ae/0x4d0
> > ...
> > [   87.673845] Call Trace:
> > [   87.673845]  [] ? mempool_free+0x36/0xa0
> > [   87.673845]  [] raid_recover_end_io+0x75/0xa0
> > [   87.673845]  [] bio_endio+0x5b/0xa0
> > [   87.673845]  [] bio_endio_nodec+0x12/0x20
> > [   87.673845]  [] end_workqueue_fn+0x41/0x50
> > [   87.673845]  [] normal_work_helper+0xca/0x2c0
> > [   87.673845]  [] process_one_work+0x1eb/0x530
> > [   87.673845]  [] ? process_one_work+0x189/0x530
> > [   87.673845]  [] worker_thread+0x11b/0x4f0
> > [   87.673845]  [] ? rescuer_thread+0x290/0x290
> > [   87.673845]  [] kthread+0xe4/0x100
> > [   87.673845]  [] ? kthread_create_on_node+0x220/0x220
> > [   87.673845]  [] ret_from_fork+0x7c/0xb0
> > [   87.673845]  [] ? kthread_create_on_node+0x220/0x220
> > 
> > ---
> > 
> > It's because that we miscalculate @rbio->bbio->error so that it doesn't
> > reach maximum of tolerable errors while it should have.
> > 
> > Signed-off-by: Liu Bo 
> > ---
> >   fs/btrfs/raid56.c | 5 +++--
> >   1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/fs/btrfs/raid56.c b/fs/btrfs/raid56.c
> > index 4055291..4a88f07 100644
> > --- a/fs/btrfs/raid56.c
> > +++ b/fs/btrfs/raid56.c
> > @@ -1956,9 +1956,10 @@ static int __raid56_parity_recover(struct 
> > btrfs_raid_bio *rbio)
> >  * pages are going to be uptodate.
> >  */
> > for (stripe = 0; stripe < bbio->num_stripes; stripe++) {
> > -   if (rbio->faila == stripe ||
> > -   rbio->failb == stripe)
> > +   if (rbio->faila == stripe || rbio->failb == stripe) {
> > +   atomic_inc(&rbio->bbio->error);
> > continue;
> > +   }
> >   
> > for (pagenr = 0; pagenr < nr_pages; pagenr++) {
> > struct page *p;
> > 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html