btrfs: fix warning when creating a directory with smack enabled
When we have smack enabled, during the creation of a directory smack may
attempt to add a "smack transmute" xattr on the inode, which results in
the following warning and trace:
WARNING: CPU: 3 PID: 2548 at fs/btrfs/transaction.c:537 start_transaction+0x489/0x4f0
Modules linked in: nft_objref nf_conntrack_netbios_ns (...)
CPU: 3 PID: 2548 Comm: mkdir Not tainted 5.9.0-rc2smack+ #81
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
RIP: 0010:start_transaction+0x489/0x4f0
Code: e9 be fc ff ff (...)
RSP: 0018:
ffffc90001887d10 EFLAGS:
00010202
RAX:
ffff88816f1e0000 RBX:
0000000000000201 RCX:
0000000000000003
RDX:
0000000000000201 RSI:
0000000000000002 RDI:
ffff888177849000
RBP:
ffff888177849000 R08:
0000000000000001 R09:
0000000000000004
R10:
ffffffff825e8f7a R11:
0000000000000003 R12:
ffffffffffffffe2
R13:
0000000000000000 R14:
ffff88803d884270 R15:
ffff8881680d8000
FS:
00007f67317b8440(0000) GS:
ffff88817bcc0000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
00007f67247a22a8 CR3:
000000004bfbc002 CR4:
0000000000370ee0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
Call Trace:
? slab_free_freelist_hook+0xea/0x1b0
? trace_hardirqs_on+0x1c/0xe0
btrfs_setxattr_trans+0x3c/0xf0
__vfs_setxattr+0x63/0x80
smack_d_instantiate+0x2d3/0x360
security_d_instantiate+0x29/0x40
d_instantiate_new+0x38/0x90
btrfs_mkdir+0x1cf/0x1e0
vfs_mkdir+0x14f/0x200
do_mkdirat+0x6d/0x110
do_syscall_64+0x2d/0x40
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7f673196ae6b
Code: 8b 05 11 (...)
RSP: 002b:
00007ffc3c679b18 EFLAGS:
00000246 ORIG_RAX:
0000000000000053
RAX:
ffffffffffffffda RBX:
00000000000001ff RCX:
00007f673196ae6b
RDX:
0000000000000000 RSI:
00000000000001ff RDI:
00007ffc3c67a30d
RBP:
00007ffc3c67a30d R08:
00000000000001ff R09:
0000000000000000
R10:
000055d3e39fe930 R11:
0000000000000246 R12:
0000000000000000
R13:
00007ffc3c679cd8 R14:
00007ffc3c67a30d R15:
00007ffc3c679ce0
irq event stamp: 11029
hardirqs last enabled at (11037): [<
ffffffff81153fe6>] console_unlock+0x486/0x670
hardirqs last disabled at (11044): [<
ffffffff81153c01>] console_unlock+0xa1/0x670
softirqs last enabled at (8864): [<
ffffffff81e0102f>] asm_call_on_stack+0xf/0x20
softirqs last disabled at (8851): [<
ffffffff81e0102f>] asm_call_on_stack+0xf/0x20
This happens because at btrfs_mkdir() we call d_instantiate_new() while
holding a transaction handle, which results in the following call chain:
btrfs_mkdir()
trans = btrfs_start_transaction(root, 5);
d_instantiate_new()
smack_d_instantiate()
__vfs_setxattr()
btrfs_setxattr_trans()
btrfs_start_transaction()
start_transaction()
WARN_ON()
--> a tansaction start has TRANS_EXTWRITERS
set in its type
h->orig_rsv = h->block_rsv
h->block_rsv = NULL
btrfs_end_transaction(trans)
Besides the warning triggered at start_transaction, we set the handle's
block_rsv to NULL which may cause some surprises later on.
So fix this by making btrfs_setxattr_trans() not start a transaction when
we already have a handle on one, stored in current->journal_info, and use
that handle. We are good to use the handle because at btrfs_mkdir() we did
reserve space for the xattr and the inode item.
Reported-by: Casey Schaufler <casey@schaufler-ca.com>
CC: stable@vger.kernel.org # 5.4+
Acked-by: Casey Schaufler <casey@schaufler-ca.com>
Tested-by: Casey Schaufler <casey@schaufler-ca.com>
Link: https://lore.kernel.org/linux-btrfs/434d856f-bd7b-4889-a6ec-e81aaebfa735@schaufler-ca.com/
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>