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
