From patchwork Mon Aug 26 07:10:33 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: lizetao X-Patchwork-Id: 13777236 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 07BB8C5321D for ; Mon, 26 Aug 2024 07:02:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 771926B034C; Mon, 26 Aug 2024 03:02:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 72B846B034D; Mon, 26 Aug 2024 03:02:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5C2846B0350; Mon, 26 Aug 2024 03:02:47 -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 3DD2C6B034C for ; Mon, 26 Aug 2024 03:02:47 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id E5AA9A0D11 for ; Mon, 26 Aug 2024 07:02:46 +0000 (UTC) X-FDA: 82493503932.30.F4C1924 Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by imf12.hostedemail.com (Postfix) with ESMTP id BC3D34000A for ; Mon, 26 Aug 2024 07:02:44 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf12.hostedemail.com: domain of lizetao1@huawei.com designates 45.249.212.255 as permitted sender) smtp.mailfrom=lizetao1@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724655681; 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-type: content-transfer-encoding:content-transfer-encoding:in-reply-to: references; bh=S7IX4b73gp9HGad9zBCGxHSluQjD5WJP/Rff/+F9fcU=; b=5alWF82T/AZ+yH7ydfe4o/rkQrWOk6ZZitYAlEiLF8ZpSC9jaF34UVTjLNntsb/kIhUClZ hb4j2hNzwj94EnDwx90KAoQFMU8YkKBIuIYE+38IWZ6r9Bm8gN1aAHAJMBByltr6hrYf/f 6Kr0sM5ZEESiU4jqRUAMD/vnb3pr1eg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724655681; a=rsa-sha256; cv=none; b=Eat59Xbyu2dY/3uAubctuYX0dixud1vtSLDaKZLiIgBb/JGZqOdeKdLZurbVfb1bu5iLqb Di7ZNQTsnDTcaUDlc9dQCUDG/ll1YHASnzzIRc6QVH+fRQETN+/E3Cjdd9atVnjAU9Qpos p0tiTjNQRQ+69iblfpl/bWHGYinwPCE= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf12.hostedemail.com: domain of lizetao1@huawei.com designates 45.249.212.255 as permitted sender) smtp.mailfrom=lizetao1@huawei.com Received: from mail.maildlp.com (unknown [172.19.163.252]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4WshS40Z41z14G42; Mon, 26 Aug 2024 15:01:56 +0800 (CST) Received: from kwepemd500012.china.huawei.com (unknown [7.221.188.25]) by mail.maildlp.com (Postfix) with ESMTPS id 647F21800A5; Mon, 26 Aug 2024 15:02:41 +0800 (CST) Received: from huawei.com (10.90.53.73) by kwepemd500012.china.huawei.com (7.221.188.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.34; Mon, 26 Aug 2024 15:02:40 +0800 From: Li Zetao To: , , , , CC: , , , Subject: [RFC PATCH -next 0/3] fs: Introduce the scope-based resource management for folio_lock/unlock Date: Mon, 26 Aug 2024 15:10:33 +0800 Message-ID: <20240826071036.2445717-1-lizetao1@huawei.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 X-Originating-IP: [10.90.53.73] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To kwepemd500012.china.huawei.com (7.221.188.25) X-Rspamd-Queue-Id: BC3D34000A X-Stat-Signature: jhnuut7o9ai9bkho6pjod7qg61sonno9 X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1724655764-907206 X-HE-Meta: U2FsdGVkX19cScpQwZGe9qC3PSkEWkMTogKUDewNLoGhdPjt3DLadnnlxDYHNpqjfBWpRLwvfJTi373vvyGd6CQipBLzwoqqT5evvrBZBGzyrmrzj/Oi6sni8PLGIbHuUM+pk8r4doPSfd1Si08BnMqvopHz+TAjk39XvOih2CwPLwI2rTj7lwJ+yNR50vzyq7Hpp01TgCuFr5SKK1F72Be6IaQMR/IM+WLTRbf0bnSzV3l7hbWo6Jvk4dpFgf5jscSkYQfjxkpVp6St0FVUW7CqZY6EcEf3Et3KIW8XTZLkIN6QekNnSBbbXvCFHJVa6Qs08rz6QP8/2/whCdjXNv/ROuwn2xpmg5AMNVxLo1YDw8sLk/SzUj0BA8JOYgwe6nqyjugai0psEXdtOvDsbt+OHl7WyUiD/5FzWSK9DIdmyyGYzrp3mhnLflGsL7/o96sBeaz3VzTciwidfWPjw6ZSPzqeWTXpCF6Oc/OGTe3Q5QKZac7z051Qn+wyfUdlToC62xUUbjogMs8xIpQmwO4I/dHDs6ynqEZ/GmRxt0TbzxAHwDUhdTrgm2Xt4yZP0UMFUmk0rDTSE9rxrYe/ZhdpKxtjfjVgvuzvFpcjPtTRxr5LBZZJhGj+SNaQtgLdp1Mh/HUkAqENaQ7T+ITz1C6wjL77sEHD2131M9DbdffKNAT+qrUfzImYzyuPI4rS8L/xAm2B7TuazBns6G8lboxVWk7TXu+osrKKmsDcOBjfoq1wzo7W28UXV56fCarRdL69TZ/anTn3nwDScwbjBB0A7zUTwVV7YQk4o1hwThWHe2QxsFXcdbc2SKZJdc4JODPj/rPCYMpLZQ5KcewHz3Tn9BCDaAET6kzYwrlT8bmRltw2mqCsvZij6EW+cMHg5laDDK6Usn/TUYiWRIITtt8k9WTyf5SqNIBqbSRfS6t0vH9krj71QEivusFEDX8yQuRUP9usdq9uDkon2J2 4YYsjUyb hsWurJIFhamxuQGRb8mN9LoH2DGoVPBYM6A12zA4goqh8QCKW7c4QtAD5SbWBJFH2cN5lQD7i50ylQUQvye/8OhsRvs/2JVo/U9OSlO4xNk+OfHNV3b5nOta3jMuCdWw+RRcS6DjBWFxapACSheQnS1UrlUqiW48q2IEs 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: Hi, all Currently, multiple kernel subsystems are switching to folio, and the page API is gradually being phased out. When using folio, due to the need to consider competition, folio needs to be locked, but folio_lock/unlock is used directly. Developers need to be careful about releasing the lock at the appropriate location. By using compiler features, the kernel has implemented scope-based resource access. Applying these features to folio can mitigate the risk of forgetting to release folio lock, and at the same time, can remove some of the controversial goto unlock code. Some interfaces are currently not suitable for using scope-based resource management mechanisms, such as iomap_page_mkwrite. This interface only needs to release the lock when an error occurs, and needs to hold the folio lock when it succeeds. Maybe we can intervene in the compiler's automatic cleanup behavior in a certain scenario like implementing no_free_ptr. This patchset has been tested by fsstress for a long time, and no problems were found. Thanks, Li Zetao. Li Zetao (3): mm: Support scope-based resource management for folio_lock/unlock buffer: Using scope-based resource instead of folio_lock/unlock splice: Using scope-based resource instead of folio_lock/unlock fs/buffer.c | 6 ++---- fs/splice.c | 21 +++++---------------- include/linux/pagemap.h | 4 ++++ 3 files changed, 11 insertions(+), 20 deletions(-)