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: Li Zetao X-Patchwork-Id: 13777250 Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2B65036AF2; Mon, 26 Aug 2024 07:02:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.255 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724655766; cv=none; b=VfrgIVoyEhTZwxFOXg/pMwmgDfOytV4+wgPvlpraHJle3OGnsHC5tvCy/CIHQcy5IXXv044Y0lNebxSfTQhJ7Ytjemyyc2AT9GDhryotjzpboBy20jnF+3iDBo2ZhRMxtqrnsWCL0F9ncdeHwtLBceQy7/Z/x1GORsprUvqvYro= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724655766; c=relaxed/simple; bh=2GFGvv7bakK5iEy/5k9XPggr1oDBjfo/z+tdbDsog48=; h=From:To:CC:Subject:Date:Message-ID:MIME-Version:Content-Type; b=qSx8Fx0xCiWP6dJVByQccEBJ91+9ugD92LhNJmYyWJ2P2bgtf0VAoDaWMT3jwvLmXuWwMRIkUL11mWL42uQ4+KiE2ziTrRk54orrv6gDofnXhDW+yl8cYNFBn4nxvBcPwG9gao8yY52xiFe1IKvIVXUqeO2Aujx2Oo6jRnArPhQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=45.249.212.255 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=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 Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To kwepemd500012.china.huawei.com (7.221.188.25) 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(-)