new integration-danger branch pushed out (kernel)

new integration-danger branch pushed out (kernel)

[Chris Mason]

Hi everyone,

I've pushed out a new integration branch, but it is not for general use.

I'm still going through and hammering on the new logging code code to
make sure it is properly backwards compatible with older kernels and
that it hasn't introduced any new bugs.

*** Please do not use this code on anything other than test filesystems that
can easily be reformatted. ***

In testing the new sub-transid logging code, I've spent a lot of time
hunting logging bugs, and writing new tests to try and make sure the
logging code is working correctly in general.  Between that and some new
tests from Arne, I've had to make some pretty big changes to the code.

This meant collapsing Fujitsu's original nicely broken out patches into
a larger patch so that I could be sure later kernel bisections wouldn't
run into problems.  All credit to Liu Bo and Fujitsu for getting the
sub-transid work going, any bugs in the pushed patch are probably ones
I introduced.

integration-danger merges in the new sub-transid logging code along with
all of the fixes Dave Sterba has been tracking, and Josef's code.

I'm still merging in trees from Arne and Jan Schmidt, those should get
pushed out tomorrow afternoon.

-chris

Re: new integration-danger branch pushed out (kernel)

[Liu Bo]

Hi, 

On 11/01/2011 10:49 AM, Chris Mason wrote:
> Hi everyone,
> 
> I've pushed out a new integration branch, but it is not for general use.
> 
> I'm still going through and hammering on the new logging code code to
> make sure it is properly backwards compatible with older kernels and
> that it hasn't introduced any new bugs.
> 
> *** Please do not use this code on anything other than test filesystems that
> can easily be reformatted. ***
> 
> In testing the new sub-transid logging code, I've spent a lot of time
> hunting logging bugs, and writing new tests to try and make sure the
> logging code is working correctly in general.  Between that and some new
> tests from Arne, I've had to make some pretty big changes to the code.
> 

I'm giving a hard read on the new code, and I notice a slight change:
@@ -3006,14 +3179,11 @@ out:
 static int inode_in_log(struct btrfs_trans_handle *trans,
                 struct inode *inode)
 {
-       struct btrfs_root *root = BTRFS_I(inode)->root;
        int ret = 0;
 
-       mutex_lock(&root->log_mutex);
-       if (BTRFS_I(inode)->logged_trans == trans->transid &&
-           BTRFS_I(inode)->last_sub_trans <= root->last_log_commit)
+       if (BTRFS_I(inode)->logged_trans >= trans->transaction->transid &&
+           BTRFS_I(inode)->last_trans < BTRFS_I(inode)->logged_trans)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                ret = 1;
-       mutex_unlock(&root->log_mutex);
        return ret;
 }

since we've moved the "sub_transid++" update to btrfs_sync_log(), the ending of log,
say there is a case like this:

transaction ------------------------------------------ start
                 |
    sub_trans A  | --- start
                 |
                 | --- modify inode X, and set X's last_trans to sub_transid
 |               |
 |               | --- fsync inode X, and set X's logged_trans to sub_transid
 |               |
 |               | --- in btrfs_sync_log(), sub_transid++
 |               |
\|/              | --- end
                 |
   sub_trans A+1 | --- start
                 |
                 | --- no change to inode X
                 |
                 | --- fsync inode X
                 |
                 | --- in inode_in_log(), X's last_trans is equal to X's logged_trans,
                       unchanged X is just in the log, but we need to log X again.

    ......             ......

transaction ------------------------------------------ end

we do not want this, does we?  Or am I missing something?

thanks,
liubo

> This meant collapsing Fujitsu's original nicely broken out patches into
> a larger patch so that I could be sure later kernel bisections wouldn't
> run into problems.  All credit to Liu Bo and Fujitsu for getting the
> sub-transid work going, any bugs in the pushed patch are probably ones
> I introduced.
> 
> integration-danger merges in the new sub-transid logging code along with
> all of the fixes Dave Sterba has been tracking, and Josef's code.
> 
> I'm still merging in trees from Arne and Jan Schmidt, those should get
> pushed out tomorrow afternoon.
> 
> -chris
> 
> --
> 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
> 

Re: new integration-danger branch pushed out (kernel)

[Chris Mason]

On Tue, Nov 01, 2011 at 05:22:20PM +0800, Liu Bo wrote:
> Hi, 
> 
> On 11/01/2011 10:49 AM, Chris Mason wrote:
> > Hi everyone,
> > 
> > I've pushed out a new integration branch, but it is not for general use.
> > 
> > I'm still going through and hammering on the new logging code code to
> > make sure it is properly backwards compatible with older kernels and
> > that it hasn't introduced any new bugs.
> > 
> > *** Please do not use this code on anything other than test filesystems that
> > can easily be reformatted. ***
> > 
> > In testing the new sub-transid logging code, I've spent a lot of time
> > hunting logging bugs, and writing new tests to try and make sure the
> > logging code is working correctly in general.  Between that and some new
> > tests from Arne, I've had to make some pretty big changes to the code.
> > 
> 
> I'm giving a hard read on the new code, and I notice a slight change:

Thanks a lot for reading it carefully.

> @@ -3006,14 +3179,11 @@ out:
>  static int inode_in_log(struct btrfs_trans_handle *trans,
>                  struct inode *inode)
>  {
> -       struct btrfs_root *root = BTRFS_I(inode)->root;
>         int ret = 0;
>  
> -       mutex_lock(&root->log_mutex);
> -       if (BTRFS_I(inode)->logged_trans == trans->transid &&
> -           BTRFS_I(inode)->last_sub_trans <= root->last_log_commit)
> +       if (BTRFS_I(inode)->logged_trans >= trans->transaction->transid &&
> +           BTRFS_I(inode)->last_trans < BTRFS_I(inode)->logged_trans)
>            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>                 ret = 1;
> -       mutex_unlock(&root->log_mutex);
>         return ret;
>  }
> 
> since we've moved the "sub_transid++" update to btrfs_sync_log(), the ending of log,
> say there is a case like this:
> 
> transaction ------------------------------------------ start
>                  |
>     sub_trans A  | --- start
>                  |
>                  | --- modify inode X, and set X's last_trans to sub_transid
>  |               |
>  |               | --- fsync inode X, and set X's logged_trans to sub_transid
>  |               |
>  |               | --- in btrfs_sync_log(), sub_transid++
>  |               |
> \|/              | --- end
>                  |
>    sub_trans A+1 | --- start
>                  |
>                  | --- no change to inode X
>                  |
>                  | --- fsync inode X
>                  |
>                  | --- in inode_in_log(), X's last_trans is equal to X's logged_trans,
>                        unchanged X is just in the log, but we need to log X again.
> 
>     ......             ......
> 
> transaction ------------------------------------------ end
> 
> we do not want this, does we?  Or am I missing something?

Correct, this is less optimal.  I was finding races where the transid
increasing at the start of the log trans would lead to one process
missing file and directory updates done by another process.

So I made the patch slightly more conservative.  We're still logging
about 75% less than we used to in every workload I've tried, but we can
definitely refine this in future commits.

Along the way I fixed an old bug in directory logging that meant we
almost always force a full commit for directory fsyncs.  The fix means
we use the directory log more often now, which is faster in some cases
and slower in others.

It also means a bug with delayed metadata insertion triggers more easily
during log replay (we need to flush the delayed ops during log replay).
The bug was hidden before because the directory log wasn't being used
much.

-chris

Re: new integration-danger branch pushed out (kernel)

[Liu Bo]

On 11/01/2011 06:55 PM, Chris Mason wrote:
> On Tue, Nov 01, 2011 at 05:22:20PM +0800, Liu Bo wrote:
>> Hi, 
>>
>> On 11/01/2011 10:49 AM, Chris Mason wrote:
>>> Hi everyone,
>>>
>>> I've pushed out a new integration branch, but it is not for general use.
>>>
>>> I'm still going through and hammering on the new logging code code to
>>> make sure it is properly backwards compatible with older kernels and
>>> that it hasn't introduced any new bugs.
>>>
>>> *** Please do not use this code on anything other than test filesystems that
>>> can easily be reformatted. ***
>>>
>>> In testing the new sub-transid logging code, I've spent a lot of time
>>> hunting logging bugs, and writing new tests to try and make sure the
>>> logging code is working correctly in general.  Between that and some new
>>> tests from Arne, I've had to make some pretty big changes to the code.
>>>
>> I'm giving a hard read on the new code, and I notice a slight change:
> 
> Thanks a lot for reading it carefully.
> 
>> @@ -3006,14 +3179,11 @@ out:
>>  static int inode_in_log(struct btrfs_trans_handle *trans,
>>                  struct inode *inode)
>>  {
>> -       struct btrfs_root *root = BTRFS_I(inode)->root;
>>         int ret = 0;
>>  
>> -       mutex_lock(&root->log_mutex);
>> -       if (BTRFS_I(inode)->logged_trans == trans->transid &&
>> -           BTRFS_I(inode)->last_sub_trans <= root->last_log_commit)
>> +       if (BTRFS_I(inode)->logged_trans >= trans->transaction->transid &&
>> +           BTRFS_I(inode)->last_trans < BTRFS_I(inode)->logged_trans)
>>            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>                 ret = 1;
>> -       mutex_unlock(&root->log_mutex);
>>         return ret;
>>  }
>>
>> since we've moved the "sub_transid++" update to btrfs_sync_log(), the ending of log,
>> say there is a case like this:
>>
>> transaction ------------------------------------------ start
>>                  |
>>     sub_trans A  | --- start
>>                  |
>>                  | --- modify inode X, and set X's last_trans to sub_transid
>>  |               |
>>  |               | --- fsync inode X, and set X's logged_trans to sub_transid
>>  |               |
>>  |               | --- in btrfs_sync_log(), sub_transid++
>>  |               |
>> \|/              | --- end
>>                  |
>>    sub_trans A+1 | --- start
>>                  |
>>                  | --- no change to inode X
>>                  |
>>                  | --- fsync inode X
>>                  |
>>                  | --- in inode_in_log(), X's last_trans is equal to X's logged_trans,
>>                        unchanged X is just in the log, but we need to log X again.
>>
>>     ......             ......
>>
>> transaction ------------------------------------------ end
>>
>> we do not want this, does we?  Or am I missing something?
> 
> Correct, this is less optimal.  I was finding races where the transid
> increasing at the start of the log trans would lead to one process
> missing file and directory updates done by another process.
> 
> So I made the patch slightly more conservative.  We're still logging
> about 75% less than we used to in every workload I've tried, but we can
> definitely refine this in future commits.
> 

Ok, got it, thanks for the explanation.

> Along the way I fixed an old bug in directory logging that meant we
> almost always force a full commit for directory fsyncs.  The fix means
> we use the directory log more often now, which is faster in some cases
> and slower in others.
> 

I know them, one from drop_objectid_items() and the other from check_parent_dirs_for_sync(),
both have been fixed in the new code.

thanks,
liubo

> It also means a bug with delayed metadata insertion triggers more easily
> during log replay (we need to flush the delayed ops during log replay).
> The bug was hidden before because the directory log wasn't being used
> much.
> 
> -chris
> 
> --
> 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
> 

Warnings (was: Re: new integration-danger branch pushed out (kernel))

[David Sterba]

Hi,

On Mon, Oct 31, 2011 at 10:49:57PM -0400, Chris Mason wrote:
> I've pushed out a new integration branch, but it is not for general use.

Thank you!

xfstests/083 and 089 cause the following warnings. I've seen them before when
testing josef/for-chris and josef/master branches (reported on irc).

[ 1149.108088] ------------[ cut here ]------------
[ 1149.114384] WARNING: at fs/btrfs/extent-tree.c:3932 btrfs_free_block_groups+0x304/0x320 [btrfs]()
[ 1149.124928] Hardware name: Santa Rosa platform
[ 1149.124931] Modules linked in: loop btrfs aoe
[ 1149.124938] Pid: 23991, comm: umount Not tainted 3.1.0-default+ #64
[ 1149.124941] Call Trace:
[ 1149.124950]  [<ffffffff81057fdf>] warn_slowpath_common+0x7f/0xc0
[ 1149.124953]  [<ffffffff8105803a>] warn_slowpath_null+0x1a/0x20
[ 1149.124973]  [<ffffffffa002bba4>] btrfs_free_block_groups+0x304/0x320 [btrfs]
[ 1149.124985]  [<ffffffffa0036ab9>] close_ctree+0x1e9/0x390 [btrfs]
[ 1149.124991]  [<ffffffff8115e2df>] ? dispose_list+0x4f/0x60
[ 1149.124999]  [<ffffffffa00108dd>] btrfs_put_super+0x1d/0x30 [btrfs]
[ 1149.125003]  [<ffffffff81145202>] generic_shutdown_super+0x62/0xe0
[ 1149.125006]  [<ffffffff81145316>] kill_anon_super+0x16/0x30
[ 1149.125009]  [<ffffffff811461a2>] ? deactivate_super+0x42/0x70
[ 1149.125012]  [<ffffffff811456dd>] deactivate_locked_super+0x3d/0xa0
[ 1149.125015]  [<ffffffff811461aa>] deactivate_super+0x4a/0x70
[ 1149.125019]  [<ffffffff81162972>] mntput_no_expire+0xa2/0xf0
[ 1149.125022]  [<ffffffff811636df>] sys_umount+0x6f/0x390
[ 1149.125027]  [<ffffffff81a1d782>] system_call_fastpath+0x16/0x1b
[ 1149.125030] ---[ end trace 81d2bc6c70d7ca56 ]---
[ 1149.125032] ------------[ cut here ]------------
[ 1149.125041] WARNING: at fs/btrfs/extent-tree.c:3933 btrfs_free_block_groups+0x2ee/0x320 [btrfs]()
[ 1149.125044] Hardware name: Santa Rosa platform
[ 1149.125045] Modules linked in: loop btrfs aoe
[ 1149.125049] Pid: 23991, comm: umount Tainted: G        W   3.1.0-default+ #64
[ 1149.125051] Call Trace:
[ 1149.125054]  [<ffffffff81057fdf>] warn_slowpath_common+0x7f/0xc0
[ 1149.125057]  [<ffffffff8105803a>] warn_slowpath_null+0x1a/0x20
[ 1149.125067]  [<ffffffffa002bb8e>] btrfs_free_block_groups+0x2ee/0x320 [btrfs]
[ 1149.125078]  [<ffffffffa0036ab9>] close_ctree+0x1e9/0x390 [btrfs]
[ 1149.125081]  [<ffffffff8115e2df>] ? dispose_list+0x4f/0x60
[ 1149.125089]  [<ffffffffa00108dd>] btrfs_put_super+0x1d/0x30 [btrfs]
[ 1149.125092]  [<ffffffff81145202>] generic_shutdown_super+0x62/0xe0
[ 1149.125096]  [<ffffffff81145316>] kill_anon_super+0x16/0x30
[ 1149.125099]  [<ffffffff811461a2>] ? deactivate_super+0x42/0x70
[ 1149.125102]  [<ffffffff811456dd>] deactivate_locked_super+0x3d/0xa0
[ 1149.125105]  [<ffffffff811461aa>] deactivate_super+0x4a/0x70
[ 1149.125108]  [<ffffffff81162972>] mntput_no_expire+0xa2/0xf0
[ 1149.125111]  [<ffffffff811636df>] sys_umount+0x6f/0x390
[ 1149.125115]  [<ffffffff81a1d782>] system_call_fastpath+0x16/0x1b
[ 1149.125117] ---[ end trace 81d2bc6c70d7ca57 ]---

The code in question:

3927 static void release_global_block_rsv(struct btrfs_fs_info *fs_info)
3928 {
3929         block_rsv_release_bytes(&fs_info->global_block_rsv, NULL, (u64)-1);
3930         WARN_ON(fs_info->delalloc_block_rsv.size > 0);
3931         WARN_ON(fs_info->delalloc_block_rsv.reserved > 0);

3932         WARN_ON(fs_info->trans_block_rsv.size > 0);
3933         WARN_ON(fs_info->trans_block_rsv.reserved > 0);

3934         WARN_ON(fs_info->chunk_block_rsv.size > 0);
3935         WARN_ON(fs_info->chunk_block_rsv.reserved > 0);
3936 }


[ 1149.125119] ------------[ cut here ]------------
[ 1149.125128] WARNING: at fs/btrfs/extent-tree.c:7090 btrfs_free_block_groups+0x23b/0x320 [btrfs]()
[ 1149.125130] Hardware name: Santa Rosa platform
[ 1149.125131] Modules linked in: loop btrfs aoe
[ 1149.125135] Pid: 23991, comm: umount Tainted: G        W   3.1.0-default+ #64
[ 1149.125137] Call Trace:
[ 1149.125140]  [<ffffffff81057fdf>] warn_slowpath_common+0x7f/0xc0
[ 1149.125143]  [<ffffffff8105803a>] warn_slowpath_null+0x1a/0x20
[ 1149.125153]  [<ffffffffa002badb>] btrfs_free_block_groups+0x23b/0x320 [btrfs]
[ 1149.125164]  [<ffffffffa0036ab9>] close_ctree+0x1e9/0x390 [btrfs]
[ 1149.125167]  [<ffffffff8115e2df>] ? dispose_list+0x4f/0x60
[ 1149.125175]  [<ffffffffa00108dd>] btrfs_put_super+0x1d/0x30 [btrfs]
[ 1149.125178]  [<ffffffff81145202>] generic_shutdown_super+0x62/0xe0
[ 1149.125181]  [<ffffffff81145316>] kill_anon_super+0x16/0x30
[ 1149.125184]  [<ffffffff811461a2>] ? deactivate_super+0x42/0x70
[ 1149.125187]  [<ffffffff811456dd>] deactivate_locked_super+0x3d/0xa0
[ 1149.125191]  [<ffffffff811461aa>] deactivate_super+0x4a/0x70
[ 1149.125194]  [<ffffffff81162972>] mntput_no_expire+0xa2/0xf0
[ 1149.125197]  [<ffffffff811636df>] sys_umount+0x6f/0x390
[ 1149.125200]  [<ffffffff81a1d782>] system_call_fastpath+0x16/0x1b
[ 1149.125202] ---[ end trace 81d2bc6c70d7ca58 ]---
[ 1149.125206] space_info 5 has 4931584 free, is full
[ 1149.125208] space_info total=48234496, used=43302912, pinned=0, reserved=0, may_use=294912, readonly=0


7028 int btrfs_free_block_groups(struct btrfs_fs_info *info)
...
7083         while(!list_empty(&info->space_info)) {
7084                 space_info = list_entry(info->space_info.next,
7085                                         struct btrfs_space_info,
7086                                         list);
7087                 if (space_info->bytes_pinned > 0 ||
7088                     space_info->bytes_reserved > 0 ||
7089                     space_info->bytes_may_use > 0) {

7090                         WARN_ON(1);

7091                         dump_space_info(space_info, 0, 0);
7092                 }
7093                 list_del(&space_info->list);
7094                 kfree(space_info);
7095         }
7096         return 0;
7097 }


david

Re: Warnings (was: Re: new integration-danger branch pushed out (kernel))

[Chris Mason]

On Tue, Nov 01, 2011 at 11:11:10AM +0100, David Sterba wrote:
> Hi,
> 
> On Mon, Oct 31, 2011 at 10:49:57PM -0400, Chris Mason wrote:
> > I've pushed out a new integration branch, but it is not for general use.
> 
> Thank you!
> 
> xfstests/083 and 089 cause the following warnings. I've seen them before when
> testing josef/for-chris and josef/master branches (reported on irc).

Ok, just a status update on my end.  Josef and I have the block group
warnings fixed.  The tree log crash is also explained, the eexist oops
comes when you're using the inode_cache code (hopefully you are?).

I have one test fix for this but it still has a few wrinkles that I'll
have to sort out in the morning.

-chris

> 
> [ 1149.108088] ------------[ cut here ]------------
> [ 1149.114384] WARNING: at fs/btrfs/extent-tree.c:3932 btrfs_free_block_groups+0x304/0x320 [btrfs]()
> [ 1149.124928] Hardware name: Santa Rosa platform
> [ 1149.124931] Modules linked in: loop btrfs aoe
> [ 1149.124938] Pid: 23991, comm: umount Not tainted 3.1.0-default+ #64
> [ 1149.124941] Call Trace:
> [ 1149.124950]  [<ffffffff81057fdf>] warn_slowpath_common+0x7f/0xc0
> [ 1149.124953]  [<ffffffff8105803a>] warn_slowpath_null+0x1a/0x20
> [ 1149.124973]  [<ffffffffa002bba4>] btrfs_free_block_groups+0x304/0x320 [btrfs]
> [ 1149.124985]  [<ffffffffa0036ab9>] close_ctree+0x1e9/0x390 [btrfs]
> [ 1149.124991]  [<ffffffff8115e2df>] ? dispose_list+0x4f/0x60
> [ 1149.124999]  [<ffffffffa00108dd>] btrfs_put_super+0x1d/0x30 [btrfs]
> [ 1149.125003]  [<ffffffff81145202>] generic_shutdown_super+0x62/0xe0
> [ 1149.125006]  [<ffffffff81145316>] kill_anon_super+0x16/0x30
> [ 1149.125009]  [<ffffffff811461a2>] ? deactivate_super+0x42/0x70
> [ 1149.125012]  [<ffffffff811456dd>] deactivate_locked_super+0x3d/0xa0
> [ 1149.125015]  [<ffffffff811461aa>] deactivate_super+0x4a/0x70
> [ 1149.125019]  [<ffffffff81162972>] mntput_no_expire+0xa2/0xf0
> [ 1149.125022]  [<ffffffff811636df>] sys_umount+0x6f/0x390
> [ 1149.125027]  [<ffffffff81a1d782>] system_call_fastpath+0x16/0x1b
> [ 1149.125030] ---[ end trace 81d2bc6c70d7ca56 ]---
> [ 1149.125032] ------------[ cut here ]------------
> [ 1149.125041] WARNING: at fs/btrfs/extent-tree.c:3933 btrfs_free_block_groups+0x2ee/0x320 [btrfs]()
> [ 1149.125044] Hardware name: Santa Rosa platform
> [ 1149.125045] Modules linked in: loop btrfs aoe
> [ 1149.125049] Pid: 23991, comm: umount Tainted: G        W   3.1.0-default+ #64
> [ 1149.125051] Call Trace:
> [ 1149.125054]  [<ffffffff81057fdf>] warn_slowpath_common+0x7f/0xc0
> [ 1149.125057]  [<ffffffff8105803a>] warn_slowpath_null+0x1a/0x20
> [ 1149.125067]  [<ffffffffa002bb8e>] btrfs_free_block_groups+0x2ee/0x320 [btrfs]
> [ 1149.125078]  [<ffffffffa0036ab9>] close_ctree+0x1e9/0x390 [btrfs]
> [ 1149.125081]  [<ffffffff8115e2df>] ? dispose_list+0x4f/0x60
> [ 1149.125089]  [<ffffffffa00108dd>] btrfs_put_super+0x1d/0x30 [btrfs]
> [ 1149.125092]  [<ffffffff81145202>] generic_shutdown_super+0x62/0xe0
> [ 1149.125096]  [<ffffffff81145316>] kill_anon_super+0x16/0x30
> [ 1149.125099]  [<ffffffff811461a2>] ? deactivate_super+0x42/0x70
> [ 1149.125102]  [<ffffffff811456dd>] deactivate_locked_super+0x3d/0xa0
> [ 1149.125105]  [<ffffffff811461aa>] deactivate_super+0x4a/0x70
> [ 1149.125108]  [<ffffffff81162972>] mntput_no_expire+0xa2/0xf0
> [ 1149.125111]  [<ffffffff811636df>] sys_umount+0x6f/0x390
> [ 1149.125115]  [<ffffffff81a1d782>] system_call_fastpath+0x16/0x1b
> [ 1149.125117] ---[ end trace 81d2bc6c70d7ca57 ]---
> 
> The code in question:
> 
> 3927 static void release_global_block_rsv(struct btrfs_fs_info *fs_info)
> 3928 {
> 3929         block_rsv_release_bytes(&fs_info->global_block_rsv, NULL, (u64)-1);
> 3930         WARN_ON(fs_info->delalloc_block_rsv.size > 0);
> 3931         WARN_ON(fs_info->delalloc_block_rsv.reserved > 0);
> 
> 3932         WARN_ON(fs_info->trans_block_rsv.size > 0);
> 3933         WARN_ON(fs_info->trans_block_rsv.reserved > 0);
> 
> 3934         WARN_ON(fs_info->chunk_block_rsv.size > 0);
> 3935         WARN_ON(fs_info->chunk_block_rsv.reserved > 0);
> 3936 }
> 
> 
> [ 1149.125119] ------------[ cut here ]------------
> [ 1149.125128] WARNING: at fs/btrfs/extent-tree.c:7090 btrfs_free_block_groups+0x23b/0x320 [btrfs]()
> [ 1149.125130] Hardware name: Santa Rosa platform
> [ 1149.125131] Modules linked in: loop btrfs aoe
> [ 1149.125135] Pid: 23991, comm: umount Tainted: G        W   3.1.0-default+ #64
> [ 1149.125137] Call Trace:
> [ 1149.125140]  [<ffffffff81057fdf>] warn_slowpath_common+0x7f/0xc0
> [ 1149.125143]  [<ffffffff8105803a>] warn_slowpath_null+0x1a/0x20
> [ 1149.125153]  [<ffffffffa002badb>] btrfs_free_block_groups+0x23b/0x320 [btrfs]
> [ 1149.125164]  [<ffffffffa0036ab9>] close_ctree+0x1e9/0x390 [btrfs]
> [ 1149.125167]  [<ffffffff8115e2df>] ? dispose_list+0x4f/0x60
> [ 1149.125175]  [<ffffffffa00108dd>] btrfs_put_super+0x1d/0x30 [btrfs]
> [ 1149.125178]  [<ffffffff81145202>] generic_shutdown_super+0x62/0xe0
> [ 1149.125181]  [<ffffffff81145316>] kill_anon_super+0x16/0x30
> [ 1149.125184]  [<ffffffff811461a2>] ? deactivate_super+0x42/0x70
> [ 1149.125187]  [<ffffffff811456dd>] deactivate_locked_super+0x3d/0xa0
> [ 1149.125191]  [<ffffffff811461aa>] deactivate_super+0x4a/0x70
> [ 1149.125194]  [<ffffffff81162972>] mntput_no_expire+0xa2/0xf0
> [ 1149.125197]  [<ffffffff811636df>] sys_umount+0x6f/0x390
> [ 1149.125200]  [<ffffffff81a1d782>] system_call_fastpath+0x16/0x1b
> [ 1149.125202] ---[ end trace 81d2bc6c70d7ca58 ]---
> [ 1149.125206] space_info 5 has 4931584 free, is full
> [ 1149.125208] space_info total=48234496, used=43302912, pinned=0, reserved=0, may_use=294912, readonly=0
> 
> 
> 7028 int btrfs_free_block_groups(struct btrfs_fs_info *info)
> ...
> 7083         while(!list_empty(&info->space_info)) {
> 7084                 space_info = list_entry(info->space_info.next,
> 7085                                         struct btrfs_space_info,
> 7086                                         list);
> 7087                 if (space_info->bytes_pinned > 0 ||
> 7088                     space_info->bytes_reserved > 0 ||
> 7089                     space_info->bytes_may_use > 0) {
> 
> 7090                         WARN_ON(1);
> 
> 7091                         dump_space_info(space_info, 0, 0);
> 7092                 }
> 7093                 list_del(&space_info->list);
> 7094                 kfree(space_info);
> 7095         }
> 7096         return 0;
> 7097 }
> 
> 
> david

Re: Warnings (was: Re: new integration-danger branch pushed out (kernel))

[David Sterba]

On Tue, Nov 01, 2011 at 08:56:15PM -0400, Chris Mason wrote:
> > xfstests/083 and 089 cause the following warnings. I've seen them before when
> > testing josef/for-chris and josef/master branches (reported on irc).
> 
> Ok, just a status update on my end.  Josef and I have the block group
> warnings fixed.

I confirm the warnings do not show anymore with the "Btrfs: release
metadata from global reserve if we have to fallback for unlink" patch.

> The tree log crash is also explained, the eexist oops
> comes when you're using the inode_cache code (hopefully you are?).

yes,

MOUNT_OPTIONS='-o compress=lzo,discard,inode_cache,space_cache,autodefrag'

> I have one test fix for this but it still has a few wrinkles that I'll
> have to sort out in the morning.

Great, I'm ready to test it.


david

Warnings: destroy inode (was: new integration-danger branch pushed out (kernel))

[David Sterba]

this time I'm not quite sure which xfstest triggered it, but there was

209 35s ...     [11:20:19] [11:20:53] [failed, exit status 1] - output mismatch (see 209.out.bad)
--- 209.out     2011-02-11 11:42:31.000000000 +0100
+++ 209.out.bad 2011-11-01 11:20:53.000000000 +0100
@@ -1,2 +1,2 @@
 QA output created by 209
-test ran for 30 seconds without error
+reader found old byte at pos 7380992
\ No newline at end of file


[ 3134.165501] ------------[ cut here ]------------
[ 3134.171488] WARNING: at fs/btrfs/inode.c:6789 btrfs_destroy_inode+0x315/0x350 [btrfs]()
[ 3134.180812] Hardware name: Santa Rosa platform
[ 3134.180814] Modules linked in: loop btrfs aoe
[ 3134.180820] Pid: 26264, comm: rm Tainted: G        W   3.1.0-default+ #64
[ 3134.180822] Call Trace:
[ 3134.180829]  [<ffffffff81057fdf>] warn_slowpath_common+0x7f/0xc0
[ 3134.180832]  [<ffffffff8105803a>] warn_slowpath_null+0x1a/0x20
[ 3134.180845]  [<ffffffffa0048165>] btrfs_destroy_inode+0x315/0x350 [btrfs]
[ 3134.180850]  [<ffffffff8115db3c>] destroy_inode+0x3c/0x70
[ 3134.180853]  [<ffffffff8115dc8e>] evict+0x11e/0x1c0
[ 3134.180855]  [<ffffffff8115de3d>] iput+0x10d/0x210
[ 3134.180859]  [<ffffffff8115240f>] do_unlinkat+0x16f/0x1d0
[ 3134.180863]  [<ffffffff81a15319>] ? retint_swapgs+0x13/0x1b
[ 3134.180867]  [<ffffffff81097bd5>] ? trace_hardirqs_on_caller+0x155/0x1d0
[ 3134.180872]  [<ffffffff8135c9be>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 3134.180875]  [<ffffffff811532b2>] sys_unlinkat+0x22/0x40
[ 3134.180879]  [<ffffffff81a1d782>] system_call_fastpath+0x16/0x1b
[ 3134.180882] ---[ end trace 81d2bc6c70d7ca5c ]---
[ 3134.180883] ------------[ cut here ]------------
[ 3134.180895] WARNING: at fs/btrfs/inode.c:6790 btrfs_destroy_inode+0x2ff/0x350 [btrfs]()
[ 3134.180897] Hardware name: Santa Rosa platform
[ 3134.180899] Modules linked in: loop btrfs aoe
[ 3134.180903] Pid: 26264, comm: rm Tainted: G        W   3.1.0-default+ #64
[ 3134.180905] Call Trace:
[ 3134.180908]  [<ffffffff81057fdf>] warn_slowpath_common+0x7f/0xc0
[ 3134.180911]  [<ffffffff8105803a>] warn_slowpath_null+0x1a/0x20
[ 3134.180923]  [<ffffffffa004814f>] btrfs_destroy_inode+0x2ff/0x350 [btrfs]
[ 3134.180927]  [<ffffffff8115db3c>] destroy_inode+0x3c/0x70
[ 3134.180929]  [<ffffffff8115dc8e>] evict+0x11e/0x1c0
[ 3134.180933]  [<ffffffff8115de3d>] iput+0x10d/0x210
[ 3134.180936]  [<ffffffff8115240f>] do_unlinkat+0x16f/0x1d0
[ 3134.180939]  [<ffffffff81a15319>] ? retint_swapgs+0x13/0x1b
[ 3134.180942]  [<ffffffff81097bd5>] ? trace_hardirqs_on_caller+0x155/0x1d0
[ 3134.180945]  [<ffffffff8135c9be>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 3134.180948]  [<ffffffff811532b2>] sys_unlinkat+0x22/0x40
[ 3134.180952]  [<ffffffff81a1d782>] system_call_fastpath+0x16/0x1b
[ 3134.180954] ---[ end trace 81d2bc6c70d7ca5d ]---
[ 3134.180956] ------------[ cut here ]------------
[ 3134.180967] WARNING: at fs/btrfs/inode.c:6792 btrfs_destroy_inode+0x2d3/0x350 [btrfs]()
[ 3134.181008] Hardware name: Santa Rosa platform
[ 3134.181010] Modules linked in: loop btrfs aoe
[ 3134.181014] Pid: 26264, comm: rm Tainted: G        W   3.1.0-default+ #64
[ 3134.181016] Call Trace:
[ 3134.181019]  [<ffffffff81057fdf>] warn_slowpath_common+0x7f/0xc0
[ 3134.181023]  [<ffffffff8105803a>] warn_slowpath_null+0x1a/0x20
[ 3134.181035]  [<ffffffffa0048123>] btrfs_destroy_inode+0x2d3/0x350 [btrfs]
[ 3134.181038]  [<ffffffff8115db3c>] destroy_inode+0x3c/0x70
[ 3134.181041]  [<ffffffff8115dc8e>] evict+0x11e/0x1c0
[ 3134.181043]  [<ffffffff8115de3d>] iput+0x10d/0x210
[ 3134.181046]  [<ffffffff8115240f>] do_unlinkat+0x16f/0x1d0
[ 3134.181049]  [<ffffffff81a15319>] ? retint_swapgs+0x13/0x1b
[ 3134.181052]  [<ffffffff81097bd5>] ? trace_hardirqs_on_caller+0x155/0x1d0
[ 3134.181055]  [<ffffffff8135c9be>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 3134.181059]  [<ffffffff811532b2>] sys_unlinkat+0x22/0x40
[ 3134.181062]  [<ffffffff81a1d782>] system_call_fastpath+0x16/0x1b
[ 3134.181064] ---[ end trace 81d2bc6c70d7ca5e ]---
[ 3135.152109] ------------[ cut here ]------------

6782 void btrfs_destroy_inode(struct inode *inode)
6783 {
6784         struct btrfs_ordered_extent *ordered;
6785         struct btrfs_root *root = BTRFS_I(inode)->root;
6786
6787         WARN_ON(!list_empty(&inode->i_dentry));
6788         WARN_ON(inode->i_data.nrpages);
6789         WARN_ON(BTRFS_I(inode)->outstanding_extents);
6790         WARN_ON(BTRFS_I(inode)->reserved_extents);
6791         WARN_ON(BTRFS_I(inode)->delalloc_bytes);
6792         WARN_ON(BTRFS_I(inode)->csum_bytes);


david

BUG at fs/btrfs/tree-log.c:3106 (Re: new integration-danger branch pushed out (kernel))

[David Sterba]

xfstests/214

[ 3142.654774] ------------[ cut here ]------------
[ 3142.656017] kernel BUG at fs/btrfs/tree-log.c:3106!
[ 3142.656017] invalid opcode: 0000 [#1] SMP
[ 3142.656017] CPU 0
[ 3142.656017] Modules linked in: loop btrfs aoe
[ 3142.656017]
[ 3142.656017] Pid: 27328, comm: xfs_io Tainted: G        W   3.1.0-default+ #64 Intel Corporation Santa Rosa platform/Matanzas
[ 3142.656017] RIP: 0010:[<ffffffffa006fe74>]  [<ffffffffa006fe74>] btrfs_log_inode+0x554/0x600 [btrfs]
[ 3142.656017] RSP: 0018:ffff88005c801d58  EFLAGS: 00010282
[ 3142.656017] RAX: 00000000ffffffef RBX: ffff88003ef39e20 RCX: 0000000000000006
[ 3142.656017] RDX: 0000000000000001 RSI: ffff8800643aa170 RDI: 0000000000000286
[ 3142.656017] RBP: ffff88005c801e48 R08: 0000000000000001 R09: 0000000000000001
[ 3142.656017] R10: 0000000000000001 R11: 0000000000000002 R12: ffff88003405fe70
[ 3142.656017] R13: ffff88005c801db8 R14: 0000000000000003 R15: ffff8800340604b0
[ 3142.656017] FS:  00007f7034667700(0000) GS:ffff88007dc00000(0000) knlGS:0000000000000000
[ 3142.656017] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 3142.656017] CR2: 00000000006b1fb0 CR3: 00000000778df000 CR4: 00000000000006f0
[ 3142.656017] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 3142.656017] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 3142.656017] Process xfs_io (pid: 27328, threadinfo ffff88005c800000, task ffff8800643a9ac0)
[ 3142.656017] Stack:
[ 3142.656017]  0000000000000000 0000000000000000 ffff8800340602b0 ffff880072efe000
[ 3142.656017]  0000000000000000 00000000000004c8 000000005c801dd8 ffff8800340604b0
[ 3142.656017]  ffff88003ef39eb0 ffff88000dfb4420 0000000000000019 0000000000000308
[ 3142.656017] Call Trace:
[ 3142.656017]  [<ffffffffa0070d28>] btrfs_log_inode_parent+0x198/0x480 [btrfs]
[ 3142.656017]  [<ffffffff8115941c>] ? dget_parent+0x1c/0xd0
[ 3142.656017]  [<ffffffffa0071059>] btrfs_log_dentry_safe+0x49/0x70 [btrfs]
[ 3142.656017]  [<ffffffffa0049406>] btrfs_sync_file+0x146/0x1d0 [btrfs]
[ 3142.656017]  [<ffffffff81143e80>] ? fget_raw+0x210/0x210
[ 3142.656017]  [<ffffffff81171029>] do_fsync+0x59/0x80
[ 3142.656017]  [<ffffffff81171340>] sys_fsync+0x10/0x20
[ 3142.656017]  [<ffffffff81a1d782>] system_call_fastpath+0x16/0x1b
[ 3142.656017] Code: 60 ff ff ff 45 89 f1 48 8b bd 58 ff ff ff 4c 89 e1 4c 89 fe 89 14 24 48 8b 95 50 ff ff ff e8 44 cf ff ff 85 c0 0f 84 04 fe ff ff <0f> 0b 48 89 df e8 f2 62 fa ff 48 8b bd 50 ff ff ff e8 e6 62 fa
[ 3142.656017] RIP  [<ffffffffa006fe74>] btrfs_log_inode+0x554/0x600 [btrfs]
[ 3142.656017]  RSP <ffff88005c801d58>
[ 3142.995743] ---[ end trace 81d2bc6c70d7ca63 ]---

2923 static int btrfs_log_inode(struct btrfs_trans_handle *trans,
2924                              struct btrfs_root *root, struct inode *inode,
2925                              int inode_only)
2926 {
...
3105 out_unlock:
3106         BUG_ON(err);

3107         mutex_unlock(&BTRFS_I(inode)->log_mutex);
3108
3109         btrfs_free_path(path);
3110         btrfs_free_path(dst_path);
3111         return err;
3112 }

from the value of RAX, -17 it's EEXIST

the code originates from:

commit 3ff4357398886f277c278fd039ba65abf5e3a113
Author: Liu Bo <liubo2009@cn.fujitsu.com>
Date:   Wed Oct 12 20:01:24 2011 -0400

    Btrfs: improve log with sub transaction

    When logging an inode _A_, current btrfs will
    a) clear all items belonged to _A_ in log,
    b) copy all items belonged to _A_ from fs/file tree to log tree,
    and this just wastes a lot of time, especially when logging big files.

    So we want to use a smarter approach, i.e. "find and merge".
    The amount of file extent items is the largest, so we focus on it.
    Thanks to sub transaction, now we can find those file extent items which
    are changed after last _transaction commit_ or last _log commit_, and
    then merge them with the existed ones in log tree.

    It will be great helpful on fsync performance, cause the common case is
    "make changes on a _part_ of inode".

    Chris Mason did some reworking of this code, any bugs left are his.

    Signed-off-by: Liu Bo <liubo2009@cn.fujitsu.com>
    Signed-off-by: Chris Mason <chris.mason@oracle.com>
---


david

Re: BUG at fs/btrfs/tree-log.c:3106 (Re: new integration-danger branch pushed out (kernel))

[Chris Mason]

On Tue, Nov 01, 2011 at 11:36:37AM +0100, David Sterba wrote:
> xfstests/214
> 
> [ 3142.654774] ------------[ cut here ]------------
> [ 3142.656017] kernel BUG at fs/btrfs/tree-log.c:3106!

What kind of hardware are you running this on?  I'm passing 214 here.

-chris

Re: BUG at fs/btrfs/tree-log.c:3106 (Re: new integration-danger branch pushed out (kernel))

[David Sterba]

On Tue, Nov 01, 2011 at 06:56:50AM -0400, Chris Mason wrote:
> On Tue, Nov 01, 2011 at 11:36:37AM +0100, David Sterba wrote:
> > xfstests/214
> > 
> > [ 3142.654774] ------------[ cut here ]------------
> > [ 3142.656017] kernel BUG at fs/btrfs/tree-log.c:3106!
> 
> What kind of hardware are you running this on?  I'm passing 214 here.

this is some old piece of hw, intel 2x 2.2Ghz CPU, 2GB memory, ICH8, SATA
controller is 82801HBM/HEM.

partition setup:

SCRATCH
Label: none  uuid: b3aabfae-69f6-4b9b-9dc0-e1ec3472183c
        Total devices 1 FS bytes used 11.32MB
        devid    1 size 104.00MB used 104.00MB path /dev/sda9

TEST
Label: none  uuid: d0e2fc5f-8a72-4c54-bee3-3c8ae1766ade
        Total devices 4 FS bytes used 15.16MB
        devid    4 size 10.00GB used 1.01GB path /dev/sda8
        devid    3 size 10.00GB used 1.01GB path /dev/sda7
        devid    2 size 10.00GB used 2.00GB path /dev/sda6
        devid    1 size 10.00GB used 2.02GB path /dev/sda5

mkfs was default.


the second box, which reproduced this same BUG, is 8 CPU AMD,
partition setup is:

Label: none  uuid: 686f0422-2bc5-4265-a4a7-f17f21cdcfd0
        Total devices 1 FS bytes used 11.31MB
        devid    1 size 104.00MB used 104.00MB path /dev/sda9

Label: none  uuid: c17552f9-4727-411d-9b75-5d84a1c5ba66
        Total devices 4 FS bytes used 13.18MB
        devid    4 size 30.00GB used 30.00GB path /dev/sda8
        devid    3 size 30.00GB used 30.00GB path /dev/sda7
        devid    2 size 30.00GB used 30.00GB path /dev/sda6
        devid    1 size 30.00GB used 30.00GB path /dev/sda5

and the crashdump is

[ 5326.176937] ------------[ cut here ]------------
[ 5326.180791] kernel BUG at fs/btrfs/tree-log.c:3106!
[ 5326.180791] invalid opcode: 0000 [#1] SMP
[ 5326.180791] CPU 5
[ 5326.180791] Modules linked in: btrfs zlib_deflate crc32c libcrc32c edd nfs lockd fscache auth_rpcgss nfs_acl sunrpc af_packet bridge ipv6 stp llc cpufreq_conservative cpufreq_userspace cpufreq_powersave powernow_k8 mperf microcode fuse loop dm_mod kvm_amd kvm tpm_infineon tg3 amd64_edac_mod edac_core shpchp edac_mce_amd i2c_piix4 i2c_core pcspkr tpm_tis tpm tpm_bios pci_hotplug sg sr_mod k10temp cdrom rtc_cmos button mptctl ext3 jbd mbcache ohci_hcd ehci_hcd usbcore sd_mod crc_t10dif fan thermal processor thermal_sys hwmon ide_pci_generic serverworks ide_core ata_generic sata_svw pata_serverworks libata mptsas mptscsih mptbase scsi_transport_sas scsi_mod [last unloaded: floppy]
[ 5326.180791]
[ 5326.180791] Pid: 17588, comm: xfs_io Tainted: G        W   3.1.0-default+ #3
[ 5326.180791] RIP: 0010:[<ffffffffa05e0504>]  [<ffffffffa05e0504>] btrfs_log_inode+0x4c4/0x680 [btrfs]
[ 5326.180791] RSP: 0018:ffff880054857d18  EFLAGS: 00010282
[ 5326.180791] RAX: 00000000ffffffef RBX: 0000000000000353 RCX: ffff88011d703300
[ 5326.180791] RDX: 000000000000002e RSI: 0000000000000001 RDI: 0000000000000286
[ 5326.180791] RBP: ffff880054857e38 R08: ffff880054857aa8 R09: 0000000000001000
[ 5326.180791] R10: 00000000000000da R11: 0000000000000000 R12: ffff8801297eb400
[ 5326.180791] R13: 0000000000000003 R14: ffff880024d781e0 R15: ffff88011861f1d8
[ 5326.180791] FS:  00007f2c3354e700(0000) GS:ffff88012fc80000(0000) knlGS:0000000000000000
[ 5326.180791] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 5326.180791] CR2: 00007f4d712f8c30 CR3: 0000000127a31000 CR4: 00000000000006e0
[ 5326.180791] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 5326.180791] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 5326.180791] Process xfs_io (pid: 17588, threadinfo ffff880054856000, task ffff880076a26300)
[ 5326.180791] Stack:
[ 5326.180791]  ffff880000000000 0007ffffffffffff ffff880054857d78 00000000810e85e0
[ 5326.180791]  ffff88007ba7f000 ffff8801101e8108 0000000000000000 0000000000000c23
[ 5326.180791]  0000000000000c23 ffff88011861f0e0 ffff880110030ac0 0000001c00000000
[ 5326.180791] Call Trace:
[ 5326.180791]  [<ffffffff810e9db3>] ? filemap_fdatawait_range+0x93/0x150
[ 5326.180791]  [<ffffffffa05e080c>] btrfs_log_inode_parent+0x14c/0x2d0 [btrfs]
[ 5326.180791]  [<ffffffffa05ac55f>] ? join_transaction+0x1f/0x250 [btrfs]
[ 5326.180791]  [<ffffffffa05e0a44>] btrfs_log_dentry_safe+0x44/0x70 [btrfs]
[ 5326.180791]  [<ffffffffa05badbf>] btrfs_sync_file+0x16f/0x1c0 [btrfs]
[ 5326.180791]  [<ffffffff81172283>] vfs_fsync_range+0x23/0x30
[ 5326.180791]  [<ffffffff811722a7>] vfs_fsync+0x17/0x20
[ 5326.180791]  [<ffffffff811724b5>] do_fsync+0x35/0x60
[ 5326.180791]  [<ffffffff8117250b>] sys_fsync+0xb/0x10
[ 5326.180791]  [<ffffffff814232d2>] system_call_fastpath+0x16/0x1b
[ 5326.180791] Code: 3c ff ff ff 45 89 e9 48 8b bd 08 ff ff ff 4c 89 f1 4c 89 fe 89 14 24 48 8b 95 30 ff ff ff e8 e4 f6 ff ff 85 c0 0f 84 c5 fc ff ff <0f> 0b eb fe 0f 1f 84 00 00 00 00 00 45 85 ed 74 33 8b 85 fc fe
[ 5326.180791] RIP  [<ffffffffa05e0504>] btrfs_log_inode+0x4c4/0x680 [btrfs]
[ 5326.180791]  RSP <ffff880054857d18>
[ 5326.482211] ---[ end trace 0a323c63265b6de4 ]---

[while writing this mail, testbox1 just tripped over the BUG again]

In both cases, the xfstests suite was run on clean mkfs and from test 001 on.

I see that process "rm -f /mnt/sda5/ouch2" is stuck at

$ cat /proc/17594/stack
[<ffffffff81152ae1>] vfs_unlink+0x61/0x120
[<ffffffff81156723>] do_unlinkat+0x1d3/0x1e0
[<ffffffff811568ad>] sys_unlinkat+0x1d/0x40
[<ffffffff814232d2>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff

So, bug is reproducible quite reliably.


david

Re: BUG at fs/btrfs/tree-log.c:3106 (Re: new integration-danger branch pushed out (kernel))

[David Sterba]

On Tue, Nov 01, 2011 at 11:36:37AM +0100, David Sterba wrote:
> xfstests/214
> 
> [ 3142.654774] ------------[ cut here ]------------
> [ 3142.656017] kernel BUG at fs/btrfs/tree-log.c:3106!
> [ 3142.656017] invalid opcode: 0000 [#1] SMP
> [ 3142.656017] CPU 0
> [ 3142.656017] Modules linked in: loop btrfs aoe
> [ 3142.656017]
> [ 3142.656017] Pid: 27328, comm: xfs_io Tainted: G        W   3.1.0-default+ #64 Intel Corporation Santa Rosa platform/Matanzas
> [ 3142.656017] RIP: 0010:[<ffffffffa006fe74>]  [<ffffffffa006fe74>] btrfs_log_inode+0x554/0x600 [btrfs]
> [ 3142.656017] RSP: 0018:ffff88005c801d58  EFLAGS: 00010282
> [ 3142.656017] RAX: 00000000ffffffef RBX: ffff88003ef39e20 RCX: 0000000000000006
> [ 3142.656017] RDX: 0000000000000001 RSI: ffff8800643aa170 RDI: 0000000000000286
> [ 3142.656017] RBP: ffff88005c801e48 R08: 0000000000000001 R09: 0000000000000001
> [ 3142.656017] R10: 0000000000000001 R11: 0000000000000002 R12: ffff88003405fe70
> [ 3142.656017] R13: ffff88005c801db8 R14: 0000000000000003 R15: ffff8800340604b0
> [ 3142.656017] FS:  00007f7034667700(0000) GS:ffff88007dc00000(0000) knlGS:0000000000000000
> [ 3142.656017] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 3142.656017] CR2: 00000000006b1fb0 CR3: 00000000778df000 CR4: 00000000000006f0
> [ 3142.656017] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 3142.656017] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 3142.656017] Process xfs_io (pid: 27328, threadinfo ffff88005c800000, task ffff8800643a9ac0)
> [ 3142.656017] Stack:
> [ 3142.656017]  0000000000000000 0000000000000000 ffff8800340602b0 ffff880072efe000
> [ 3142.656017]  0000000000000000 00000000000004c8 000000005c801dd8 ffff8800340604b0
> [ 3142.656017]  ffff88003ef39eb0 ffff88000dfb4420 0000000000000019 0000000000000308
> [ 3142.656017] Call Trace:
> [ 3142.656017]  [<ffffffffa0070d28>] btrfs_log_inode_parent+0x198/0x480 [btrfs]
> [ 3142.656017]  [<ffffffff8115941c>] ? dget_parent+0x1c/0xd0
> [ 3142.656017]  [<ffffffffa0071059>] btrfs_log_dentry_safe+0x49/0x70 [btrfs]
> [ 3142.656017]  [<ffffffffa0049406>] btrfs_sync_file+0x146/0x1d0 [btrfs]
> [ 3142.656017]  [<ffffffff81143e80>] ? fget_raw+0x210/0x210
> [ 3142.656017]  [<ffffffff81171029>] do_fsync+0x59/0x80
> [ 3142.656017]  [<ffffffff81171340>] sys_fsync+0x10/0x20
> [ 3142.656017]  [<ffffffff81a1d782>] system_call_fastpath+0x16/0x1b
> [ 3142.656017] Code: 60 ff ff ff 45 89 f1 48 8b bd 58 ff ff ff 4c 89 e1 4c 89 fe 89 14 24 48 8b 95 50 ff ff ff e8 44 cf ff ff 85 c0 0f 84 04 fe ff ff <0f> 0b 48 89 df e8 f2 62 fa ff 48 8b bd 50 ff ff ff e8 e6 62 fa
> [ 3142.656017] RIP  [<ffffffffa006fe74>] btrfs_log_inode+0x554/0x600 [btrfs]
> [ 3142.656017]  RSP <ffff88005c801d58>
> [ 3142.995743] ---[ end trace 81d2bc6c70d7ca63 ]---

for the record, exactly same crash at xfstets/256 (run from 215- on),
with "rm -f /mnt/a1/25365.falloc" stuck (D) at vfs_unlink


david

Warnings and crash

[David Sterba]

the related source pointers of the warnings and crash (detailed below):

[ 1186.540073] WARNING: at fs/btrfs/extent-tree.c:5837 btrfs_alloc_free_block+0x337/0x350 [btrfs]()
[ 1186.541076] WARNING: at fs/btrfs/extent-tree.c:4617 __btrfs_free_extent+0x60d/0x6c0 [btrfs]()
[ 1186.541234] BUG: unable to handle kernel NULL pointer dereference at           (null)
[ 1186.541237] IP: [<ffffffffa005b881>] map_private_extent_buffer+0x21/0x1f0 [btrfs]


fs/btrfs/extent-tree.c:5837

This not a new warning, also known as 'the warn in use_block_rsv', happened
during xfstests/224.

The ratelimited printk patch (btrfs: ratelimit WARN_ON in use_block_rsv) is
part of the btrfs-next-stable branch pulled in, though is still meant as a
safety not to hang the box completely (and should go away in the future).

[ 1186.529033] btrfs: block rsv returned -28
[ 1186.534256] ------------[ cut here ]------------
[ 1186.540073] WARNING: at fs/btrfs/extent-tree.c:5837 btrfs_alloc_free_block+0x337/0x350 [btrfs]()
[ 1186.540075] Hardware name: Santa Rosa platform
[ 1186.540077] Modules linked in: btrfs aoe
[ 1186.540082] Pid: 5007, comm: btrfs-transacti Not tainted 3.1.0-default+ #64
[ 1186.540084] Call Trace:
[ 1186.540091]  [<ffffffff81057fdf>] warn_slowpath_common+0x7f/0xc0
[ 1186.540095]  [<ffffffff8105803a>] warn_slowpath_null+0x1a/0x20
[ 1186.540104]  [<ffffffffa002a9d7>] btrfs_alloc_free_block+0x337/0x350 [btrfs]
[ 1186.540109]  [<ffffffff810913dd>] ? trace_hardirqs_off+0xd/0x10
[ 1186.540113]  [<ffffffff810098d5>] ? native_sched_clock+0x15/0x70
[ 1186.540118]  [<ffffffff810844ff>] ? local_clock+0x6f/0x80
[ 1186.540126]  [<ffffffffa0017162>] __btrfs_cow_block+0x152/0x800 [btrfs]
[ 1186.540130]  [<ffffffff810844ff>] ? local_clock+0x6f/0x80
[ 1186.540133]  [<ffffffff810916fd>] ? lock_release_holdtime+0x3d/0x1a0
[ 1186.540141]  [<ffffffffa0017ae1>] btrfs_cow_block+0x2d1/0x410 [btrfs]
[ 1186.540150]  [<ffffffffa001cb88>] btrfs_search_slot+0x728/0xe70 [btrfs]
[ 1186.540159]  [<ffffffffa0022f0b>] lookup_inline_extent_backref+0x8b/0x480 [btrfs]
[ 1186.540168]  [<ffffffffa00245f0>] __btrfs_free_extent+0xd0/0x6c0 [btrfs]
[ 1186.540172]  [<ffffffff813628be>] ? do_raw_spin_unlock+0x5e/0xb0
[ 1186.540182]  [<ffffffffa00287cf>] run_clustered_refs+0x21f/0x850 [btrfs]
[ 1186.540192]  [<ffffffffa0028ec8>] btrfs_run_delayed_refs+0xc8/0x220 [btrfs]
[ 1186.540195]  [<ffffffff813628be>] ? do_raw_spin_unlock+0x5e/0xb0
[ 1186.540205]  [<ffffffffa0029178>] btrfs_write_dirty_block_groups+0x158/0x540 [btrfs]
[ 1186.540216]  [<ffffffffa0038ee5>] commit_cowonly_roots+0x115/0x1e0 [btrfs]
[ 1186.540228]  [<ffffffffa0039ee7>] btrfs_commit_transaction+0x477/0x8f0 [btrfs]
[ 1186.540240]  [<ffffffffa00391a9>] ? join_transaction+0x69/0x2b0 [btrfs]
[ 1186.540243]  [<ffffffff8107d480>] ? wake_up_bit+0x40/0x40
[ 1186.540254]  [<ffffffffa0032a1b>] transaction_kthread+0x28b/0x2a0 [btrfs]
[ 1186.540264]  [<ffffffffa0032790>] ? btree_readpage+0x30/0x30 [btrfs]
[ 1186.540267]  [<ffffffff8107cf16>] kthread+0xa6/0xb0
[ 1186.540272]  [<ffffffff81a1ea04>] kernel_thread_helper+0x4/0x10
[ 1186.540276]  [<ffffffff81a15334>] ? retint_restore_args+0x13/0x13
[ 1186.540279]  [<ffffffff8107ce70>] ? __init_kthread_worker+0x70/0x70
[ 1186.540282]  [<ffffffff81a1ea00>] ? gs_change+0x13/0x13
[ 1186.540284] ---[ end trace 6fa3da5fd65420af ]---
[ 1186.540433] btrfs: block rsv returned -28

ratelimited, I see just 2 occurences before, followed by

[ 1186.541076] WARNING: at fs/btrfs/extent-tree.c:4617 __btrfs_free_extent+0x60d/0x6c0 [btrfs]()
[ 1186.541079] Hardware name: Santa Rosa platform
[ 1186.541080] Modules linked in: btrfs aoe
[ 1186.541084] Pid: 5007, comm: btrfs-transacti Tainted: G        W   3.1.0-default+ #64
[ 1186.541086] Call Trace:
[ 1186.541089]  [<ffffffff81057fdf>] warn_slowpath_common+0x7f/0xc0
[ 1186.541093]  [<ffffffff8105803a>] warn_slowpath_null+0x1a/0x20
[ 1186.541101]  [<ffffffffa0024b2d>] __btrfs_free_extent+0x60d/0x6c0 [btrfs]
[ 1186.541105]  [<ffffffff813628be>] ? do_raw_spin_unlock+0x5e/0xb0
[ 1186.541114]  [<ffffffffa0028949>] run_clustered_refs+0x399/0x850 [btrfs]
[ 1186.541126]  [<ffffffffa0079800>] ? btrfs_find_ref_cluster+0xb0/0x1a0 [btrfs]
[ 1186.541136]  [<ffffffffa0028ec8>] btrfs_run_delayed_refs+0xc8/0x220 [btrfs]
[ 1186.541139]  [<ffffffff813628be>] ? do_raw_spin_unlock+0x5e/0xb0
[ 1186.541149]  [<ffffffffa0029178>] btrfs_write_dirty_block_groups+0x158/0x540 [btrfs]
[ 1186.541160]  [<ffffffffa0038ee5>] commit_cowonly_roots+0x115/0x1e0 [btrfs]
[ 1186.541172]  [<ffffffffa0039ee7>] btrfs_commit_transaction+0x477/0x8f0 [btrfs]
[ 1186.541183]  [<ffffffffa00391a9>] ? join_transaction+0x69/0x2b0 [btrfs]
[ 1186.541186]  [<ffffffff8107d480>] ? wake_up_bit+0x40/0x40
[ 1186.541196]  [<ffffffffa0032a1b>] transaction_kthread+0x28b/0x2a0 [btrfs]
[ 1186.541207]  [<ffffffffa0032790>] ? btree_readpage+0x30/0x30 [btrfs]
[ 1186.541210]  [<ffffffff8107cf16>] kthread+0xa6/0xb0
[ 1186.541213]  [<ffffffff81a1ea04>] kernel_thread_helper+0x4/0x10
[ 1186.541216]  [<ffffffff81a15334>] ? retint_restore_args+0x13/0x13
[ 1186.541219]  [<ffffffff8107ce70>] ? __init_kthread_worker+0x70/0x70
[ 1186.541222]  [<ffffffff81a1ea00>] ? gs_change+0x13/0x13
[ 1186.541224] ---[ end trace 6fa3da5fd65420b1 ]---
[ 1186.541076] WARNING: at fs/btrfs/extent-tree.c:4617 __btrfs_free_extent+0x60d/0x6c0 [btrfs]()
[ 1186.541079] Hardware name: Santa Rosa platform
[ 1186.541080] Modules linked in: btrfs aoe
[ 1186.541084] Pid: 5007, comm: btrfs-transacti Tainted: G        W   3.1.0-default+ #64
[ 1186.541086] Call Trace:
[ 1186.541089]  [<ffffffff81057fdf>] warn_slowpath_common+0x7f/0xc0
[ 1186.541093]  [<ffffffff8105803a>] warn_slowpath_null+0x1a/0x20
[ 1186.541101]  [<ffffffffa0024b2d>] __btrfs_free_extent+0x60d/0x6c0 [btrfs]
[ 1186.541105]  [<ffffffff813628be>] ? do_raw_spin_unlock+0x5e/0xb0
[ 1186.541114]  [<ffffffffa0028949>] run_clustered_refs+0x399/0x850 [btrfs]
[ 1186.541126]  [<ffffffffa0079800>] ? btrfs_find_ref_cluster+0xb0/0x1a0 [btrfs]
[ 1186.541136]  [<ffffffffa0028ec8>] btrfs_run_delayed_refs+0xc8/0x220 [btrfs]
[ 1186.541139]  [<ffffffff813628be>] ? do_raw_spin_unlock+0x5e/0xb0
[ 1186.541149]  [<ffffffffa0029178>] btrfs_write_dirty_block_groups+0x158/0x540 [btrfs]
[ 1186.541160]  [<ffffffffa0038ee5>] commit_cowonly_roots+0x115/0x1e0 [btrfs]
[ 1186.541172]  [<ffffffffa0039ee7>] btrfs_commit_transaction+0x477/0x8f0 [btrfs]
[ 1186.541183]  [<ffffffffa00391a9>] ? join_transaction+0x69/0x2b0 [btrfs]
[ 1186.541186]  [<ffffffff8107d480>] ? wake_up_bit+0x40/0x40
[ 1186.541196]  [<ffffffffa0032a1b>] transaction_kthread+0x28b/0x2a0 [btrfs]
[ 1186.541207]  [<ffffffffa0032790>] ? btree_readpage+0x30/0x30 [btrfs]
[ 1186.541210]  [<ffffffff8107cf16>] kthread+0xa6/0xb0
[ 1186.541213]  [<ffffffff81a1ea04>] kernel_thread_helper+0x4/0x10
[ 1186.541216]  [<ffffffff81a15334>] ? retint_restore_args+0x13/0x13
[ 1186.541219]  [<ffffffff8107ce70>] ? __init_kthread_worker+0x70/0x70
[ 1186.541222]  [<ffffffff81a1ea00>] ? gs_change+0x13/0x13
[ 1186.541224] ---[ end trace 6fa3da5fd65420b1 ]---

4615         } else {
4616                 btrfs_print_leaf(extent_root, path->nodes[0]);
4617                 WARN_ON(1);
4618                 printk(KERN_ERR "btrfs unable to find ref byte nr %llu "
4619                        "parent %llu root %llu  owner %llu offset %llu\n",
4620                        (unsigned long long)bytenr,
4621                        (unsigned long long)parent,
4622                        (unsigned long long)root_objectid,
4623                        (unsigned long long)owner_objectid,
4624                        (unsigned long long)owner_offset);
4625         }


[ 1186.541227] btrfs unable to find ref byte nr 428474368 parent 0 root 7  owner 0 offset 0
[ 1186.541234] BUG: unable to handle kernel NULL pointer dereference at           (null)
[ 1186.541237] IP: [<ffffffffa005b881>] map_private_extent_buffer+0x21/0x1f0 [btrfs]
[ 1186.541250] PGD 51ece067 PUD 6425d067 PMD 0
[ 1186.541253] Oops: 0000 [#1] SMP
[ 1186.541257] CPU 0
[ 1186.541258] Modules linked in: btrfs aoe
[ 1186.541261]
[ 1186.541263] Pid: 5007, comm: btrfs-transacti Tainted: G        W   3.1.0-default+ #64 Intel Corporation Santa Rosa platform/Matanzas
[ 1186.541268] RIP: 0010:[<ffffffffa005b881>]  [<ffffffffa005b881>] map_private_extent_buffer+0x21/0x1f0 [btrfs]
[ 1186.541281] RSP: 0018:ffff8800795d1960  EFLAGS: 00010286
[ 1186.541283] RAX: 0000000000000000 RBX: 0000000000000065 RCX: ffff8800795d19d0
[ 1186.541285] RDX: 0000000000000004 RSI: 000000000000007a RDI: 0000000000000000
[ 1186.541288] RBP: ffff8800795d19b0 R08: ffff8800795d19c8 R09: ffff8800795d19c0
[ 1186.541290] R10: 0000000000000001 R11: 0000000000000001 R12: 000000000000007a
[ 1186.541292] R13: 0000000000000000 R14: 0000000000000065 R15: 0000000000000000
[ 1186.541295] FS:  0000000000000000(0000) GS:ffff88007c000000(0000) knlGS:0000000000000000
[ 1186.541297] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 1186.541300] CR2: 0000000000000000 CR3: 000000006a578000 CR4: 00000000000006f0
[ 1186.541302] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1186.541304] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 1186.541307] Process btrfs-transacti (pid: 5007, threadinfo ffff8800795d0000, task ffff88007a00c880)
[ 1186.541309] Stack:
[ 1186.541310]  ffff8800795d1970 00ffffff00000003 ffff8800795d19b0 ffff880078da6520
[ 1186.541314]  0000000000000000 0000000000000065 000000000000007a 0000000000000000
[ 1186.541318]  0000000000000065 0000000000000000 ffff8800795d1a00 ffffffffa0050dfc
[ 1186.541322] Call Trace:
[ 1186.541335]  [<ffffffffa0050dfc>] btrfs_item_size+0x3c/0x90 [btrfs]
[ 1186.541344]  [<ffffffffa0024755>] __btrfs_free_extent+0x235/0x6c0 [btrfs]
[ 1186.541348]  [<ffffffff813628be>] ? do_raw_spin_unlock+0x5e/0xb0
[ 1186.541357]  [<ffffffffa0028949>] run_clustered_refs+0x399/0x850 [btrfs]
[ 1186.541369]  [<ffffffffa0079800>] ? btrfs_find_ref_cluster+0xb0/0x1a0 [btrfs]
[ 1186.541378]  [<ffffffffa0028ec8>] btrfs_run_delayed_refs+0xc8/0x220 [btrfs]
[ 1186.541382]  [<ffffffff813628be>] ? do_raw_spin_unlock+0x5e/0xb0
[ 1186.541391]  [<ffffffffa0029178>] btrfs_write_dirty_block_groups+0x158/0x540 [btrfs]
[ 1186.541402]  [<ffffffffa0038ee5>] commit_cowonly_roots+0x115/0x1e0 [btrfs]
[ 1186.541414]  [<ffffffffa0039ee7>] btrfs_commit_transaction+0x477/0x8f0 [btrfs]
[ 1186.541425]  [<ffffffffa00391a9>] ? join_transaction+0x69/0x2b0 [btrfs]
[ 1186.541428]  [<ffffffff8107d480>] ? wake_up_bit+0x40/0x40
[ 1186.541439]  [<ffffffffa0032a1b>] transaction_kthread+0x28b/0x2a0 [btrfs]
[ 1186.541449]  [<ffffffffa0032790>] ? btree_readpage+0x30/0x30 [btrfs]
[ 1186.541452]  [<ffffffff8107cf16>] kthread+0xa6/0xb0
[ 1186.541456]  [<ffffffff81a1ea04>] kernel_thread_helper+0x4/0x10
[ 1186.541459]  [<ffffffff81a15334>] ? retint_restore_args+0x13/0x13
[ 1186.541462]  [<ffffffff8107ce70>] ? __init_kthread_worker+0x70/0x70
[ 1186.541464]  [<ffffffff81a1ea00>] ? gs_change+0x13/0x13
[ 1186.541466] Code: 55 90 e9 b6 fc ff ff 0f 1f 00 55 48 89 e5 48 83 ec 50 48 89 5d d8 4c 89 65 e0 4c 89 6d e8 4c 89 75 f0 4c 89 7d f8 66 66 66 66 90 <4c> 8b 37 49 89 cd 4c 89 cb 41 81 e6 ff 0f 00 00 4a 8d 04 36 48
[ 1186.541493] RIP  [<ffffffffa005b881>] map_private_extent_buffer+0x21/0x1f0 [btrfs]
[ 1186.541506]  RSP <ffff8800795d1960>
[ 1186.541507] CR2: 0000000000000000
[ 1187.258581] ---[ end trace 6fa3da5fd65420b2 ]---


david

Re: Warnings and crash

[David Sterba]

This one happened again, exactly same sequence of warnings and the crash
at the end (same stack traces). It was in integration-scrub branch, ie.
with all fixes on top.

(I have captured sysrq-w, /proc/pid/stack of all processes and have the
dmesg logs if anybody is interested.)


david

Re: Warnings and crash

[Chris Mason]

On Thu, Nov 03, 2011 at 12:02:31AM +0100, David Sterba wrote:
> This one happened again, exactly same sequence of warnings and the crash
> at the end (same stack traces). It was in integration-scrub branch, ie.
> with all fixes on top.
> 
> (I have captured sysrq-w, /proc/pid/stack of all processes and have the
> dmesg logs if anybody is interested.)

Yes, I'd like to see the logs.  We need to figure out if we just failed
with enospc in a critical spot or if there are other bigger problems.

-chris

Re: Warnings and crash

[Mitch Harder]

On Wed, Nov 2, 2011 at 6:40 PM, Chris Mason <chris.mason@oracle.com> wr=
ote:
> On Thu, Nov 03, 2011 at 12:02:31AM +0100, David Sterba wrote:
>> This one happened again, exactly same sequence of warnings and the c=
rash
>> at the end (same stack traces). It was in integration-scrub branch, =
ie.
>> with all fixes on top.
>>
>> (I have captured sysrq-w, /proc/pid/stack of all processes and have =
the
>> dmesg logs if anybody is interested.)
>
> Yes, I'd like to see the logs. =A0We need to figure out if we just fa=
iled
> with enospc in a critical spot or if there are other bigger problems.
>

I'm seeing similar warnings while testing the integration-scrub branch.

I'm testing on a 16-GB partition that is less than 20% full when I'm
seeing the warning.

Let me know if you're still working on this issue, and I'll try to
isolate the command that is running.

[ 8631.183234] device fsid aff24946-5596-4c19-a6c4-81809ae6bd94 devid
1 transid 7 /dev/sdb6
[ 8631.183483] btrfs: disk space caching is enabled
[ 8712.675332] btrfs: block rsv returned -28
[ 8712.675334] ------------[ cut here ]------------
[ 8712.675362] WARNING: at fs/btrfs/extent-tree.c:5837
btrfs_alloc_free_block+0x3e9/0x400 [btrfs]()
[ 8712.675364] Hardware name: P35-DS3L
[ 8712.675365] Modules linked in: ipv6 snd_seq_midi snd_seq_dummy
snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss
lgdt330x cx88_dvb cx88_vp3054_i2c videobuf_dvb dvb_core rc_hauppauge
tuner_simple tuner_types tda9887 tda8290 tuner nvidia(P) ir_lirc_codec
lirc_dev ir_mce_kbd_decoder cx88_alsa cx8800 ir_sony_decoder
ir_jvc_decoder ir_rc6_decoder cx8802 cx88xx snd_ens1371 ir_rc5_decoder
ir_nec_decoder gameport snd_rawmidi snd_seq_device rc_core
i2c_algo_bit snd_ac97_codec videobuf_dma_sg tveeprom v4l2_common
videodev media v4l2_compat_ioctl32 videobuf_core btcx_risc iTCO_wdt
iTCO_vendor_support intel_agp intel_gtt ac97_bus snd_pcm snd_timer
i2c_i801 snd i2c_core snd_page_alloc ppdev parport_pc parport tpm_tis
tpm r8169 tpm_bios sr_mod pcspkr iscsi_tcp libiscsi_tcp libiscsi fuse
nfs nfs_acl auth_rpcgss lockd sunrpc btrfs zlib_deflate sl811_hcd
ohci_hcd uhci_hcd ehci_hcd
[ 8712.675409] Pid: 7917, comm: btrfs-transacti Tainted: P
3.1.0-integration-scrub+ #1
[ 8712.675411] Call Trace:
[ 8712.675417]  [<ffffffff81046e8f>] warn_slowpath_common+0x7f/0xc0
[ 8712.675420]  [<ffffffff81046eea>] warn_slowpath_null+0x1a/0x20
[ 8712.675428]  [<ffffffffa004a2e9>] btrfs_alloc_free_block+0x3e9/0x400=
 [btrfs]
[ 8712.675435]  [<ffffffffa003b621>] ? btrfs_leaf_free_space+0x61/0xb0 =
[btrfs]
[ 8712.675442]  [<ffffffffa0039069>] __btrfs_cow_block+0x119/0x560 [btr=
fs]
[ 8712.675451]  [<ffffffffa0054070>] ? btrfs_buffer_uptodate+0x50/0x70 =
[btrfs]
[ 8712.675458]  [<ffffffffa0039669>] btrfs_cow_block+0x1b9/0x2f0 [btrfs=
]
[ 8712.675465]  [<ffffffffa003d640>] btrfs_search_slot+0x5c0/0xa90 [btr=
fs]
[ 8712.675473]  [<ffffffffa0048b49>]
btrfs_write_dirty_block_groups+0xd9/0x530 [btrfs]
[ 8712.675481]  [<ffffffffa0048952>] ? btrfs_run_delayed_refs+0xf2/0x21=
0 [btrfs]
[ 8712.675490]  [<ffffffffa0057475>] commit_cowonly_roots+0x115/0x1e0 [=
btrfs]
[ 8712.675499]  [<ffffffffa0058a74>]
btrfs_commit_transaction+0x404/0x8a0 [btrfs]
[ 8712.675508]  [<ffffffffa0057e31>] ?
join_transaction.clone.24+0x21/0x240 [btrfs]
[ 8712.675511]  [<ffffffff81068e30>] ? wake_up_bit+0x40/0x40
[ 8712.675520]  [<ffffffffa0051ee3>] transaction_kthread+0x263/0x280 [b=
trfs]
[ 8712.675528]  [<ffffffffa0051c80>] ? btrfs_congested_fn+0xb0/0xb0 [bt=
rfs]
[ 8712.675536]  [<ffffffffa0051c80>] ? btrfs_congested_fn+0xb0/0xb0 [bt=
rfs]
[ 8712.675539]  [<ffffffff810688a6>] kthread+0x96/0xa0
[ 8712.675542]  [<ffffffff816d3b54>] kernel_thread_helper+0x4/0x10
[ 8712.675545]  [<ffffffff81068810>] ? kthread_worker_fn+0x1a0/0x1a0
[ 8712.675547]  [<ffffffff816d3b50>] ? gs_change+0xb/0xb
[ 8712.675549] ---[ end trace 234618ad5fea81a4 ]---
--
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

All green (Re: new integration-danger branch pushed out (kernel))

[David Sterba]

Hi,

all reported issues are fixed with the updated branch, thanks!


david