From: Abdul Haleem <hidden> Date: 2019-09-03 08:56:24
Greeting's
Mainline kernel panics with LTP/fs_fill-dir tests for btrfs file system on my P9 box running mainline kernel 5.3.0-rc5
BUG_ON was first introduced by below commit
commit 00801ae4bb2be5f5af46502ef239ac5f4b536094
Author: David Sterba [off-list ref]
Date: Thu May 2 16:53:47 2019 +0200
btrfs: switch extent_buffer write_locks from atomic to int
The write_locks is either 0 or 1 and always updated under the lock,
so we don't need the atomic_t semantics.
Reviewed-by: Nikolay Borisov [off-list ref]
Signed-off-by: David Sterba [off-list ref]
From: Nikolay Borisov <hidden> Date: 2019-09-03 10:40:04
On 3.09.19 г. 11:55 ч., Abdul Haleem wrote:
quoted hunk
Greeting's
Mainline kernel panics with LTP/fs_fill-dir tests for btrfs file system on my P9 box running mainline kernel 5.3.0-rc5
BUG_ON was first introduced by below commit
commit 00801ae4bb2be5f5af46502ef239ac5f4b536094
Author: David Sterba [off-list ref]
Date: Thu May 2 16:53:47 2019 +0200
btrfs: switch extent_buffer write_locks from atomic to int
The write_locks is either 0 or 1 and always updated under the lock,
so we don't need the atomic_t semantics.
Reviewed-by: Nikolay Borisov [off-list ref]
Signed-off-by: David Sterba [off-list ref]
From: Abdul Haleem <hidden> Date: 2019-09-11 08:00:44
On Tue, 2019-09-03 at 13:39 +0300, Nikolay Borisov wrote:
On 3.09.19 г. 11:55 ч., Abdul Haleem wrote:
quoted
Greeting's
Mainline kernel panics with LTP/fs_fill-dir tests for btrfs file system on my P9 box running mainline kernel 5.3.0-rc5
BUG_ON was first introduced by below commit
commit 00801ae4bb2be5f5af46502ef239ac5f4b536094
Author: David Sterba [off-list ref]
Date: Thu May 2 16:53:47 2019 +0200
btrfs: switch extent_buffer write_locks from atomic to int
The write_locks is either 0 or 1 and always updated under the lock,
so we don't need the atomic_t semantics.
Reviewed-by: Nikolay Borisov [off-list ref]
Signed-off-by: David Sterba [off-list ref]
Can you provide the line numbers btrfs_search_slot+0x8e8/0xb80
corresponds to?
btrfs_search_slot+0x8e8/0xb80 maps to fs/btrfs/ctree.c:2751
write_lock_level = BTRFS_MAX_LEVEL;
9a70: 08 00 40 39 li r10,8
9a74: 08 00 a0 3a li r21,8
9a78: 6c 00 41 91 stw r10,108(r1)
9a7c: 1c f8 ff 4b b 9298 <btrfs_search_slot+0x108>
b = btrfs_root_node(root);
and btrfs_assert_tree_locked+0x10/0x20 maps to ./fs/btrfs/locking.c:71
void btrfs_assert_tree_locked(struct extent_buffer *eb)
{
BUG_ON(!eb->write_locks);
80: 14 01 23 81 lwz r9,276(r3)
84: 34 00 29 7d cntlzw r9,r9
88: 7e d9 29 55 rlwinm r9,r9,27,5,31
8c: 20 00 29 79 clrldi r9,r9,32
90: 00 00 09 0b tdnei r9,0
94: 20 00 80 4e blr
98: 00 00 00 60 nop
9c: 00 00 42 60 ori r2,r2,0
I have sent direct message attaching vmlinux and the obj dump for
ctree.c and locking.c
--
Regard's
Abdul Haleem
IBM Linux Technology Centre
From: Nikolay Borisov <hidden> Date: 2019-09-11 08:09:41
On 11.09.19 г. 11:00 ч., Abdul Haleem wrote:
On Tue, 2019-09-03 at 13:39 +0300, Nikolay Borisov wrote:
quoted
<split>
quoted
corresponds to?
btrfs_search_slot+0x8e8/0xb80 maps to fs/btrfs/ctree.c:2751
write_lock_level = BTRFS_MAX_LEVEL;
That doesn't make sense, presumably btrfs_search_slot+0x8e8/0xb80 should
point at or right after the instruction which called
btrfs_set_path_blocking. So either line 2796, 2894, 2901 or 2918 .
9a70: 08 00 40 39 li r10,8
9a74: 08 00 a0 3a li r21,8
quoted
9a78: 6c 00 41 91 stw r10,108(r1)
9a7c: 1c f8 ff 4b b 9298 <btrfs_search_slot+0x108>
b = btrfs_root_node(root);
and btrfs_assert_tree_locked+0x10/0x20 maps to ./fs/btrfs/locking.c:71
void btrfs_assert_tree_locked(struct extent_buffer *eb)
{
BUG_ON(!eb->write_locks);
80: 14 01 23 81 lwz r9,276(r3)
84: 34 00 29 7d cntlzw r9,r9
88: 7e d9 29 55 rlwinm r9,r9,27,5,31
8c: 20 00 29 79 clrldi r9,r9,32
quoted
90: 00 00 09 0b tdnei r9,0
94: 20 00 80 4e blr
98: 00 00 00 60 nop
9c: 00 00 42 60 ori r2,r2,0
I have sent direct message attaching vmlinux and the obj dump for
ctree.c and locking.c
I just got a message from : InterScan Messaging Security Suite about
some policy being broken and no vmscan.
From: Abdul Haleem <hidden> Date: 2019-09-11 09:15:00
On Wed, 2019-09-11 at 11:09 +0300, Nikolay Borisov wrote:
On 11.09.19 г. 11:00 ч., Abdul Haleem wrote:
quoted
On Tue, 2019-09-03 at 13:39 +0300, Nikolay Borisov wrote:
quoted
<split>
quoted
quoted
corresponds to?
btrfs_search_slot+0x8e8/0xb80 maps to fs/btrfs/ctree.c:2751
write_lock_level = BTRFS_MAX_LEVEL;
That doesn't make sense, presumably btrfs_search_slot+0x8e8/0xb80 should
point at or right after the instruction which called
btrfs_set_path_blocking. So either line 2796, 2894, 2901 or 2918 .
I might be calculating to wrong address, could you please have a look on
the obj dump for files I have sent (which are less than 2MB)
quoted
I have sent direct message attaching vmlinux and the obj dump for
ctree.c and locking.c
I just got a message from : InterScan Messaging Security Suite about
some policy being broken and no vmscan.
Sorry, my vmlinux was above 28Mb.
--
Regard's
Abdul Haleem
IBM Linux Technology Centre
From: David Sterba <hidden> Date: 2019-09-03 12:37:52
On Tue, Sep 03, 2019 at 02:25:07PM +0530, Abdul Haleem wrote:
Greeting's
Mainline kernel panics with LTP/fs_fill-dir tests for btrfs file system on my P9 box running mainline kernel 5.3.0-rc5
BUG_ON was first introduced by below commit
Well, technically the bug_on was there already the only change is the
handling of the updates of the value.
commit 00801ae4bb2be5f5af46502ef239ac5f4b536094
Author: David Sterba [off-list ref]
Date: Thu May 2 16:53:47 2019 +0200
btrfs: switch extent_buffer write_locks from atomic to int
The write_locks is either 0 or 1 and always updated under the lock,
so we don't need the atomic_t semantics.
Assuming the code was correct before the patch, if this got broken one
of the above does not hold anymore:
* 0/1 updates -- this can be verified in code that all the state
transitions are valid, ie. initial 0, locked update to 1, locked
update 1->0
* atomic_t -> int behaves differently and the changes of the value get
mixed up, eg. on the instruction level where intel architecture does
'inc' while p9 does I-don't-know-what a RMW update?
But even with a RMW, this should not matter due to
write_lock/write_unlock around all the updates.