[PATCH] btrfs: ctree: Dump the leaf before BUG_ON()

[PATCH] btrfs: ctree: Dump the leaf before BUG_ON()

[Qu Wenruo]

We have a user reporting BUG_ON() triggered in
btrfs_set_item_key_safe().

Let's dump the leaf content before triggering BUG_ON() so that we can
have some clue on what's going wrong.
The output of tree locks should help us to debug such problem.

Signed-off-by: Qu Wenruo <wqu@suse.com>
---
 fs/btrfs/ctree.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index f52eb952597b..c769a7b50ba4 100644
--- a/fs/btrfs/ctree.c
+++ b/fs/btrfs/ctree.c
@@ -3185,10 +3185,12 @@ void btrfs_set_item_key_safe(struct btrfs_fs_info *fs_info,
 	slot = path->slots[0];
 	if (slot > 0) {
 		btrfs_item_key(eb, &disk_key, slot - 1);
+		btrfs_print_leaf(eb);
 		BUG_ON(comp_keys(&disk_key, new_key) >= 0);
 	}
 	if (slot < btrfs_header_nritems(eb) - 1) {
 		btrfs_item_key(eb, &disk_key, slot + 1);
+		btrfs_print_leaf(eb);
 		BUG_ON(comp_keys(&disk_key, new_key) <= 0);
 	}
 
-- 
2.21.0

Re: [PATCH] btrfs: ctree: Dump the leaf before BUG_ON()

[Nikolay Borisov]

On 24.04.19 г. 15:48 ч., Qu Wenruo wrote:
> Let's dump the leaf content before triggering BUG_ON() so that we can
> have some clue on what's going wrong.
> The output of tree locks should help us to debug such problem.
> 

The reason is some sort of in-memory corruption/confusion of the extent
maps, causing overlapping extents. However so far it hasn't been
possible to reproduce that on-demand to actually debug it. Filipe
suspected it has to do with extent mapping merging logic. This only
occurs when working with the log tree which takes its data from the
in-memory extent mapping tree.

Re: [PATCH] btrfs: ctree: Dump the leaf before BUG_ON()

[Qu Wenruo]

On 2019/4/24 下午8:52, Nikolay Borisov wrote:
>
>
> On 24.04.19 г. 15:48 ч., Qu Wenruo wrote:
>> Let's dump the leaf content before triggering BUG_ON() so that we can
>> have some clue on what's going wrong.
>> The output of tree locks should help us to debug such problem.
>>
>
> The reason is some sort of in-memory corruption/confusion of the extent
> maps, causing overlapping extents. However so far it hasn't been
> possible to reproduce that on-demand to actually debug it. Filipe
> suspected it has to do with extent mapping merging logic. This only
> occurs when working with the log tree which takes its data from the
> in-memory extent mapping tree.

Anyway, this won't hurt. right?

If it gives us some clue, that's the best case.
If not, it won't make the current situation worse, right?

Thanks,
Qu

Re: [PATCH] btrfs: ctree: Dump the leaf before BUG_ON()

[Filipe Manana]

On Wed, Apr 24, 2019 at 1:57 PM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>
>
>
> On 2019/4/24 下午8:52, Nikolay Borisov wrote:
> >
> >
> > On 24.04.19 г. 15:48 ч., Qu Wenruo wrote:
> >> Let's dump the leaf content before triggering BUG_ON() so that we can
> >> have some clue on what's going wrong.
> >> The output of tree locks should help us to debug such problem.
> >>
> >
> > The reason is some sort of in-memory corruption/confusion of the extent
> > maps, causing overlapping extents. However so far it hasn't been
> > possible to reproduce that on-demand to actually debug it. Filipe
> > suspected it has to do with extent mapping merging logic. This only
> > occurs when working with the log tree which takes its data from the
> > in-memory extent mapping tree.
>
> Anyway, this won't hurt. right?
>
> If it gives us some clue, that's the best case.
> If not, it won't make the current situation worse, right?

Right, but dumping the leaf alone, may not tell you much (I've been there).
Printing the new key and slot, together with the leaf dump, helps much more.

Thanks.

>
> Thanks,
> Qu



-- 
Filipe David Manana,

“Whether you think you can, or you think you can't — you're right.”

Re: [PATCH] btrfs: ctree: Dump the leaf before BUG_ON()

[Qu Wenruo]

On 2019/4/24 下午9:53, Filipe Manana wrote:
> On Wed, Apr 24, 2019 at 1:57 PM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>>
>>
>>
>> On 2019/4/24 下午8:52, Nikolay Borisov wrote:
>>>
>>>
>>> On 24.04.19 г. 15:48 ч., Qu Wenruo wrote:
>>>> Let's dump the leaf content before triggering BUG_ON() so that we can
>>>> have some clue on what's going wrong.
>>>> The output of tree locks should help us to debug such problem.
>>>>
>>>
>>> The reason is some sort of in-memory corruption/confusion of the extent
>>> maps, causing overlapping extents. However so far it hasn't been
>>> possible to reproduce that on-demand to actually debug it. Filipe
>>> suspected it has to do with extent mapping merging logic. This only
>>> occurs when working with the log tree which takes its data from the
>>> in-memory extent mapping tree.
>>
>> Anyway, this won't hurt. right?
>>
>> If it gives us some clue, that's the best case.
>> If not, it won't make the current situation worse, right?
> 
> Right, but dumping the leaf alone, may not tell you much (I've been there).
> Printing the new key and slot, together with the leaf dump, helps much more.

Right, I'd add them.

Thanks,
Qu

> 
> Thanks.
> 
>>
>> Thanks,
>> Qu
> 
> 
>