[RFC,-next,0/3] fs: Introduce the scope-based resource management for folio_lock/unlock

Message

lizetao Aug. 26, 2024, 7:10 a.m. UTC

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