Re: [PATCH v2 4/4] docs/mm: update document for split i_mmap tree

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The commit message claims to document the `i_mmap_tree_unlock_write` helper, but it is completely omitted from the documentation text changes.
--

commit d14051a8e507a6d5364fa4f0f61edf41becf1526
Author: Huang Shijie <huangsj@hygon.cn>

docs/mm: update document for split i_mmap tree

This commit updates the documentation to reflect i_mmap locking changes. It
details the split i_mmap tree architecture, new per-tree lock helpers, and
updated lock ordering and page table freeing semantics.

> Add documentation for:
> - CONFIG_SPLIT_I_MMAP split i_mmap tree architecture with per-tree locks
> - New per-tree lock helpers: i_mmap_tree_lock_write/unlock_write

[Severity: Medium]
Does the commit message accurately reflect the changes in the patch?

The message mentions adding documentation for the unlock helper, but
looking at the updated text in the patch, it appears to be missing.

> diff --git a/Documentation/mm/process_addrs.rst b/Documentation/mm/process_addrs.rst
> index 042d64d72421b..bc0d1ac7136d9 100644
> --- a/Documentation/mm/process_addrs.rst
> +++ b/Documentation/mm/process_addrs.rst

[ ... ]

> @@ -60,6 +60,15 @@ Terminology
>    :c:func:`!i_mmap_[try]lock_write` for file-backed memory. We refer to these
>    locks as the reverse mapping locks, or 'rmap locks' for brevity.
>  
> +  When :c:macro:`!CONFIG_SPLIT_I_MMAP` is enabled, the file-backed i_mmap tree
> +  is split into multiple sibling trees (one per NUMA node or a number based on
> +  CPU count), each with its own :c:type:`!struct i_mmap_tree` containing a
> +  red/black interval tree and a :c:type:`!struct rw_semaphore`. In this
> +  configuration, :c:func:`!i_mmap_lock_read` and :c:func:`!i_mmap_lock_write`
> +  acquire all per-tree locks, while VMA insert/remove operations use the
> +  per-tree granularity :c:func:`!i_mmap_tree_lock_write` to lock only the
> +  relevant sibling tree, significantly reducing lock contention.

[Severity: Medium]
Was the documentation for i_mmap_tree_unlock_write accidentally omitted from
this section? The text explains the locking side but does not mention the
corresponding unlock function.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260611061915.2354307-1-huangsj@hygon.cn?part=4