Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1708909pxb; Mon, 8 Mar 2021 04:36:02 -0800 (PST) X-Google-Smtp-Source: ABdhPJz6I99jdgdgpGfT/CD0qFU+7nLLk2foFCLyqmkqjNj138MtqGnhzPhRK1CjIuQhwAFK7o16 X-Received: by 2002:a17:906:d291:: with SMTP id ay17mr6112267ejb.308.1615206962270; Mon, 08 Mar 2021 04:36:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615206962; cv=none; d=google.com; s=arc-20160816; b=D64ph8ljKce0t1oXMXtvEx7/4iezRfoo+Y56FiTfxuTBUAmOEaM8LJlS+LaXdvBgI9 6s6agICVe9TabCwRFjDSTgGvY8ovq1aOjaF2GMtnZZ8J+5aQKsoY/SQIiVtmspEM7bDb 8VTxC3kRYqarjtpMlM5RiO0gIy4W8MqoGBOnd+YEF22cR/hZFRI9CRyqrnVCiDhJhciI zAKBV07F20M1VSlDNBpFiJDP3K/6RO/0YuRaIw65kU3xYRlRkvxbc3gsE+UCsS7aLQtY aiS+/iJNAnIbiY0YM2fLhFE1Sqii2GTBpwmZ2xxWiLINbFREbal3P08ZzAH3KMqL03cz /1RQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=OIlbuL3+9Dm35B+XWaAdwdhvq87xRDxAzh0Ve4yS6YQ=; b=i2Q1fp+D5fJuWkdm2pDStOQgBfj8PQj2DazIN556ofpusDS9bqo9zfC+/POuALAXAT LiiOMqxX58lC4u2b9n7W/10gEeBX5ejP+7kubNsUmm2BfYUXx/aJEr6SSt5ESD/ARfzk YbBoLkf1gYeg5WH5f+qMdq2RRrYepGwt+v5l0hVRB5ZHvx6MpeRQmuvwCByK14Dq0Bjf c9zrGqaA2OFbjQPKQvvUPN5IpL1y7UjtrsIAazkeDP94SkLcO6odAb8R4go11y5fFJGv OBgFzt2luvfWzRFky8WAqM70pHPod2l9kes+IPQR8ASzItMgkWs4hPi1cxpo6hVfHPI/ Ar3Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=035eL9zY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f20si7089820edr.318.2021.03.08.04.35.39; Mon, 08 Mar 2021 04:36:02 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=035eL9zY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231789AbhCHMee (ORCPT + 99 others); Mon, 8 Mar 2021 07:34:34 -0500 Received: from mail.kernel.org ([198.145.29.99]:42734 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231203AbhCHMd5 (ORCPT ); Mon, 8 Mar 2021 07:33:57 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id E89CF651C3; Mon, 8 Mar 2021 12:33:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1615206837; bh=2McWRBxUwSx2egTeDxtKrJL6qhs5FY+OLg2fcUVemVs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=035eL9zY7fQDu9FsHNtnkkv+1xUzzfUFQCY+tD33aMWe6dxZVbTYNnM7WO8bzcXzx 4v4Ur4qCL8l/SixeuUg//7ieNyAIhZxUPF/VqkGM1Z7vBQ6FQ9UufBAoCJdYAI5BPV jj0ObUrAplsaITuw5faQqGkEdPwdxZhdfiV7PUZw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Casey Schaufler , Filipe Manana , David Sterba Subject: [PATCH 5.10 15/42] btrfs: fix warning when creating a directory with smack enabled Date: Mon, 8 Mar 2021 13:30:41 +0100 Message-Id: <20210308122718.890230109@linuxfoundation.org> X-Mailer: git-send-email 2.30.1 In-Reply-To: <20210308122718.120213856@linuxfoundation.org> References: <20210308122718.120213856@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Filipe Manana commit fd57a98d6f0c98fa295813087f13afb26c224e73 upstream. 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): [] console_unlock+0x486/0x670 hardirqs last disabled at (11044): [] console_unlock+0xa1/0x670 softirqs last enabled at (8864): [] asm_call_on_stack+0xf/0x20 softirqs last disabled at (8851): [] 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 CC: stable@vger.kernel.org # 5.4+ Acked-by: Casey Schaufler Tested-by: Casey Schaufler Link: https://lore.kernel.org/linux-btrfs/434d856f-bd7b-4889-a6ec-e81aaebfa735@schaufler-ca.com/ Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/xattr.c | 31 +++++++++++++++++++++++++++---- 1 file changed, 27 insertions(+), 4 deletions(-) --- a/fs/btrfs/xattr.c +++ b/fs/btrfs/xattr.c @@ -229,11 +229,33 @@ int btrfs_setxattr_trans(struct inode *i { struct btrfs_root *root = BTRFS_I(inode)->root; struct btrfs_trans_handle *trans; + const bool start_trans = (current->journal_info == NULL); int ret; - trans = btrfs_start_transaction(root, 2); - if (IS_ERR(trans)) - return PTR_ERR(trans); + if (start_trans) { + /* + * 1 unit for inserting/updating/deleting the xattr + * 1 unit for the inode item update + */ + trans = btrfs_start_transaction(root, 2); + if (IS_ERR(trans)) + return PTR_ERR(trans); + } else { + /* + * This can happen when smack is enabled and a directory is being + * created. It happens through d_instantiate_new(), which calls + * smack_d_instantiate(), which in turn calls __vfs_setxattr() to + * set the transmute xattr (XATTR_NAME_SMACKTRANSMUTE) on the + * inode. We have already reserved space for the xattr and inode + * update at btrfs_mkdir(), so just use the transaction handle. + * We don't join or start a transaction, as that will reset the + * block_rsv of the handle and trigger a warning for the start + * case. + */ + ASSERT(strncmp(name, XATTR_SECURITY_PREFIX, + XATTR_SECURITY_PREFIX_LEN) == 0); + trans = current->journal_info; + } ret = btrfs_setxattr(trans, inode, name, value, size, flags); if (ret) @@ -244,7 +266,8 @@ int btrfs_setxattr_trans(struct inode *i ret = btrfs_update_inode(trans, root, inode); BUG_ON(ret); out: - btrfs_end_transaction(trans); + if (start_trans) + btrfs_end_transaction(trans); return ret; }