From patchwork Thu Oct 24 13:22:19 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yu Kuai X-Patchwork-Id: 13849014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5A9E6CE8E70 for ; Thu, 24 Oct 2024 13:25:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3CBF26B00AD; Thu, 24 Oct 2024 09:25:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 34D216B00B0; Thu, 24 Oct 2024 09:25:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0695E6B00AD; Thu, 24 Oct 2024 09:25:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id BD7A86B00AE for ; Thu, 24 Oct 2024 09:25:22 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 5B5161C6FE8 for ; Thu, 24 Oct 2024 13:25:01 +0000 (UTC) X-FDA: 82708566906.16.17786F2 Received: from dggsgout12.his.huawei.com (dggsgout12.his.huawei.com [45.249.212.56]) by imf07.hostedemail.com (Postfix) with ESMTP id 645164001C for ; Thu, 24 Oct 2024 13:24:53 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=none; spf=pass (imf07.hostedemail.com: domain of yukuai1@huaweicloud.com designates 45.249.212.56 as permitted sender) smtp.mailfrom=yukuai1@huaweicloud.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729776242; a=rsa-sha256; cv=none; b=OdHh4N++5Kw6afPvpxx7nYNdu1ci5yfqCLmKbKX5tKOBi8WP/tLDkDbZa/EAjWhCDOCa0V 3LEFK7xz24E+ZXCEjcRNd6ycCTyFD+GgGmEqzhG2RDXNALotlLemGGl0VEBrsaUB6J5rQM DbPe4i6RVT2vjqxmBJk3YF+/gDi1xu0= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=none; spf=pass (imf07.hostedemail.com: domain of yukuai1@huaweicloud.com designates 45.249.212.56 as permitted sender) smtp.mailfrom=yukuai1@huaweicloud.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729776242; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=D2T3xfAxE7GGV51yhK65qcvDzA9Iczruo9D2MjoHPEA=; b=l95oaEMJVifYiTjd5apzu4g7uZWFE/deJpY6x58/gjpcFtOgDrryU02V+rmF2PuSH5TOZf tcOvtuQRJCxrnwkRXROXkgD94risZI0+TtaD8n6TXGtdOQ+Dptb+gsH1bTobPKrGuqvmYJ UiloqpOW+oGmGSdocEW892ozymtdhdU= Received: from mail.maildlp.com (unknown [172.19.163.235]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTP id 4XZ68n6VyPz4f3jMs for ; Thu, 24 Oct 2024 21:24:57 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id 5F4941A0568 for ; Thu, 24 Oct 2024 21:25:15 +0800 (CST) Received: from huaweicloud.com (unknown [10.175.104.67]) by APP4 (Coremail) with SMTP id gCh0CgD3LMmxShpnmfz6Ew--.42902S10; Thu, 24 Oct 2024 21:25:15 +0800 (CST) From: Yu Kuai To: stable@vger.kernel.org, gregkh@linuxfoundation.org, harry.wentland@amd.com, sunpeng.li@amd.com, Rodrigo.Siqueira@amd.com, alexander.deucher@amd.com, christian.koenig@amd.com, Xinhui.Pan@amd.com, airlied@gmail.com, daniel@ffwll.ch, viro@zeniv.linux.org.uk, brauner@kernel.org, Liam.Howlett@oracle.com, akpm@linux-foundation.org, hughd@google.com, willy@infradead.org, sashal@kernel.org, srinivasan.shanmugam@amd.com, chiahsuan.chung@amd.com, mingo@kernel.org, mgorman@techsingularity.net, yukuai3@huawei.com, chengming.zhou@linux.dev, zhangpeng.00@bytedance.com, chuck.lever@oracle.com Cc: amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, maple-tree@lists.infradead.org, linux-mm@kvack.org, yukuai1@huaweicloud.com, yi.zhang@huawei.com, yangerkun@huawei.com Subject: [PATCH 6.6 22/28] libfs: Re-arrange locking in offset_iterate_dir() Date: Thu, 24 Oct 2024 21:22:19 +0800 Message-Id: <20241024132225.2271667-7-yukuai1@huaweicloud.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20241024132225.2271667-1-yukuai1@huaweicloud.com> References: <20241024132009.2267260-1-yukuai1@huaweicloud.com> <20241024132225.2271667-1-yukuai1@huaweicloud.com> MIME-Version: 1.0 X-CM-TRANSID: gCh0CgD3LMmxShpnmfz6Ew--.42902S10 X-Coremail-Antispam: 1UD129KBjvJXoWxAFWktw1Uur1UZFy8Zw4DCFg_yoW5AFyUpF 9xGasrGr4fW3WjkaykJF1kZ34S93Z0gr47W395Wwn8XFy3trZ8t3ZFyr4Y9ayUZFZ3Cr47 XF45t3WS9w4UArDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmI14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Cr1j6r xdM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl6s0D M2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xIIjx v20xvE14v26r1Y6r17McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1l F7xvr2IYc2Ij64vIr41lF7I21c0EjII2zVCS5cI20VAGYxC7M4IIrI8v6xkF7I0E8cxan2 IY04v7MxkF7I0En4kS14v26rWY6Fy7MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY 6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17 CEb7AF67AKxVWrXVW8Jr1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVW5JVW7JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Cr1j6rxdMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCw CI42IY6I8E87Iv67AKxVW8JVWxJwCI42IY6I8E87Iv6xkF7I0E14v26F4UJVW0obIYCTnI WIevJa73UjIFyTuYvjTRGg4SUUUUU X-CM-SenderInfo: 51xn3trlr6x35dzhxuhorxvhhfrp/ X-Stat-Signature: 5gndirwu9uerr7cforexk9173gg76m8t X-Rspamd-Queue-Id: 645164001C X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1729776293-916026 X-HE-Meta: U2FsdGVkX181HafncKvEmiN/78i/jM+gD7Z0pVkHQk86eio4DIRkB4jYTi/WiajeKipCPh2TnSkNLt05F6FWrom1nN7c1zZsNIk5YJp02ov5mJPLQhpks+J6x6QdOppShFnkdraxtKyzYb5AvgXbc27s9sl6QQcqa84z8T6Ctc2Ohx6Egr0N282NIhTserPSqqYBqAIBY9GkXGg5xLg3UrDecGIBTyu0FGabggKQ82JuOCnRLVrQZTzcAb7lpwJuhef0mt0z6JpFxMltTSEx2b4DLrz/ZqA9C6sl8j0E8XrliIlhzyqBXkb6Ip4he24UX6bOOBXxUZ0u7OYn76wg80wuA2rIufdvSE2DpT/L2U9o4hr1wzpxAlBEEdMf5N89KIlj8C3bidUTtAvLPIZaFtZ7puNMTnvNPOkdYTXoauoTRHbZ1GGBwdpZZ24MgKpsHDqNJvF4ggrt07Oji9SrW3X9rZzLi09ivLkjke1k/HZlFSfIz6KGDVNnI56e4t8WrsDCcc3gHNDnV96yuLarLsgKP+jPD09HwWu9y4Ggj4LwuMbTFkMuZREndEMXqQC66RSWsL+729xTsoof0domxxDG0uc2vv8tnoR332z1EtQGXdY4xeVia6HYDsPs1j9OxHc2Fry6jpeWnBiISd+8NxCcSGrEFq4dZMxlZf73/M+AXyVge7hw36CB85SAGy0PFxy3wLJ1nRp8M1WGWQJQLfYMUCoZOoCc1kjxTjY95pDSKQpOjKcrtGXI6cTiA0Y4sCG6M+Uuefo6FiGHn2KaAWOEvbX/n4f/KSTGYvsq0rhR0qPmRNlX1YpD8CTnEtxuyewLyMAUFru7fq0e4aiPxduKT8xyiWIb1A0ys5e8VZkGWG7cBBzzmk8DfajkJh9TLZUPbTq4W6h9KecWxzBeLQvn2w6aE2URqMY+Bos8j8OgiNYO6AE7ZpVgwUJr5VUSAoHTox91dBuxmmRBcBT wUii7e4W vWdHpVOo0sKcrV9jjiU/p8WNQOk0JnFSPfw8xibpLy9SofxGFh4TGXgcETePPBckDu4RrzXMXk0UyMW1Cvl4qI+Tpeaz8xJFvGQk0eA8uNt+pjguToCzIluAvJX4ll0X8nHUaMnJQ8gY61SyXZ8aUtx7Pf5UBu8E06EEjy8CLPPTJxF7aa2jFeyTY+Vvicou/uTwbytGMTgvVhfdXZyNNkqhRWwVpLlg3QhIKIazukRg9Bm8pXivwAXl+YpmNi+sJVBXs X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: From: Chuck Lever commit 3f6d810665dfde0d33785420618ceb03fba0619d upstream. Liam and Matthew say that once the RCU read lock is released, xa_state is not safe to re-use for the next xas_find() call. But the RCU read lock must be released on each loop iteration so that dput(), which might_sleep(), can be called safely. Thus we are forced to walk the offset tree with fresh state for each directory entry. xa_find() can do this for us, though it might be a little less efficient than maintaining xa_state locally. We believe that in the current code base, inode->i_rwsem provides protection for the xa_state maintained in offset_iterate_dir(). However, there is no guarantee that will continue to be the case in the future. Since offset_iterate_dir() doesn't build xa_state locally any more, there's no longer a strong need for offset_find_next(). Clean up by rolling these two helpers together. Suggested-by: Liam R. Howlett Message-ID: <170785993027.11135.8830043889278631735.stgit@91.116.238.104.host.secureserver.net> Signed-off-by: Chuck Lever Link: https://lore.kernel.org/r/170820142021.6328.15047865406275957018.stgit@91.116.238.104.host.secureserver.net Reviewed-by: Jan Kara Signed-off-by: Christian Brauner Signed-off-by: Yu Kuai --- fs/libfs.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/fs/libfs.c b/fs/libfs.c index dc0f7519045f..430f7c95336c 100644 --- a/fs/libfs.c +++ b/fs/libfs.c @@ -401,12 +401,13 @@ static loff_t offset_dir_llseek(struct file *file, loff_t offset, int whence) return vfs_setpos(file, offset, U32_MAX); } -static struct dentry *offset_find_next(struct xa_state *xas) +static struct dentry *offset_find_next(struct offset_ctx *octx, loff_t offset) { struct dentry *child, *found = NULL; + XA_STATE(xas, &octx->xa, offset); rcu_read_lock(); - child = xas_next_entry(xas, U32_MAX); + child = xas_next_entry(&xas, U32_MAX); if (!child) goto out; spin_lock(&child->d_lock); @@ -429,12 +430,11 @@ static bool offset_dir_emit(struct dir_context *ctx, struct dentry *dentry) static void *offset_iterate_dir(struct inode *inode, struct dir_context *ctx) { - struct offset_ctx *so_ctx = inode->i_op->get_offset_ctx(inode); - XA_STATE(xas, &so_ctx->xa, ctx->pos); + struct offset_ctx *octx = inode->i_op->get_offset_ctx(inode); struct dentry *dentry; while (true) { - dentry = offset_find_next(&xas); + dentry = offset_find_next(octx, ctx->pos); if (!dentry) return ERR_PTR(-ENOENT); @@ -443,8 +443,8 @@ static void *offset_iterate_dir(struct inode *inode, struct dir_context *ctx) break; } + ctx->pos = dentry2offset(dentry) + 1; dput(dentry); - ctx->pos = xas.xa_index + 1; } return NULL; }