linux-kernel - [RFC PATCH -next 0/3] fs: Introduce the scope-based resource management for folio

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240826071036.2445717-1-lizetao1@huawei.com>
Date: Mon, 26 Aug 2024 15:10:33 +0800
From: Li Zetao <lizetao1@...wei.com>
To: <viro@...iv.linux.org.uk>, <brauner@...nel.org>, <jack@...e.cz>,
	<willy@...radead.org>, <akpm@...ux-foundation.org>
CC: <lizetao1@...wei.com>, <linux-fsdevel@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <linux-mm@...ck.org>
Subject: [RFC PATCH -next 0/3] fs: Introduce the scope-based resource management for folio_lock/unlock

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(-)

-- 
2.34.1