[PATCH 0/4] Improve mm documentation

[PATCH 0/4] Improve mm documentation

[Matthew Wilcox (Oracle)]

If you build with W=1, kernel-doc complains about tlb_flush_rmaps().
Then I ran scripts/find-unused-docs.sh against mm/ and found a large
number of files which weren't included in the ReST documentation.
I fixed up a couple of them, and added all those without erros to the
rst files.  There's a lot more work to do to organise all of this, but
at least now if we have documentation that refers to these functions,
we'll get a nice link to them.

Matthew Wilcox (Oracle) (4):
  mm: Fix kernel-doc warning from tlb_flush_rmaps()
  mm: Fix get_mctgt_type() kernel-doc
  mm: Fix clean_record_shared_mapping_range kernel-doc
  mm: Add orphaned kernel-doc to the rst files.

 Documentation/core-api/mm-api.rst | 25 +++++++++++++++++++++++++
 Documentation/mm/highmem.rst      |  1 +
 Documentation/mm/zsmalloc.rst     |  5 +++++
 mm/mapping_dirty_helpers.c        | 11 ++++++-----
 mm/memcontrol.c                   | 31 +++++++++++++------------------
 mm/mmu_gather.c                   |  1 +
 6 files changed, 51 insertions(+), 23 deletions(-)

-- 
2.40.1

[PATCH 1/4] mm: Fix kernel-doc warning from tlb_flush_rmaps()

[Matthew Wilcox (Oracle)]

The vma parameter wasn't described.

Signed-off-by: Matthew Wilcox (Oracle) <willy-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
---
 mm/mmu_gather.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/mm/mmu_gather.c b/mm/mmu_gather.c
index ea9683e12936..4f559f4ddd21 100644
--- a/mm/mmu_gather.c
+++ b/mm/mmu_gather.c
@@ -63,6 +63,7 @@ static void tlb_flush_rmap_batch(struct mmu_gather_batch *batch, struct vm_area_
 /**
  * tlb_flush_rmaps - do pending rmap removals after we have flushed the TLB
  * @tlb: the current mmu_gather
+ * @vma: The memory area from which the pages are being removed.
  *
  * Note that because of how tlb_next_batch() above works, we will
  * never start multiple new batches with pending delayed rmaps, so
-- 
2.40.1

Re: [PATCH 1/4] mm: Fix kernel-doc warning from tlb_flush_rmaps()

[Randy Dunlap]

On 8/18/23 13:06, Matthew Wilcox (Oracle) wrote:
> The vma parameter wasn't described.
> 
> Signed-off-by: Matthew Wilcox (Oracle) <willy-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>

Acked-by: Randy Dunlap <rdunlap-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Thanks.

> ---
>  mm/mmu_gather.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/mm/mmu_gather.c b/mm/mmu_gather.c
> index ea9683e12936..4f559f4ddd21 100644
> --- a/mm/mmu_gather.c
> +++ b/mm/mmu_gather.c
> @@ -63,6 +63,7 @@ static void tlb_flush_rmap_batch(struct mmu_gather_batch *batch, struct vm_area_
>  /**
>   * tlb_flush_rmaps - do pending rmap removals after we have flushed the TLB
>   * @tlb: the current mmu_gather
> + * @vma: The memory area from which the pages are being removed.
>   *
>   * Note that because of how tlb_next_batch() above works, we will
>   * never start multiple new batches with pending delayed rmaps, so

-- 
~Randy

Re: [PATCH 1/4] mm: Fix kernel-doc warning from tlb_flush_rmaps()

[Mike Rapoport]

On Fri, Aug 18, 2023 at 09:06:27PM +0100, Matthew Wilcox (Oracle) wrote:
> The vma parameter wasn't described.
> 
> Signed-off-by: Matthew Wilcox (Oracle) <willy-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>

Acked-by: Mike Rapoport (IBM) <rppt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

> ---
>  mm/mmu_gather.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/mm/mmu_gather.c b/mm/mmu_gather.c
> index ea9683e12936..4f559f4ddd21 100644
> --- a/mm/mmu_gather.c
> +++ b/mm/mmu_gather.c
> @@ -63,6 +63,7 @@ static void tlb_flush_rmap_batch(struct mmu_gather_batch *batch, struct vm_area_
>  /**
>   * tlb_flush_rmaps - do pending rmap removals after we have flushed the TLB
>   * @tlb: the current mmu_gather
> + * @vma: The memory area from which the pages are being removed.
>   *
>   * Note that because of how tlb_next_batch() above works, we will
>   * never start multiple new batches with pending delayed rmaps, so
> -- 
> 2.40.1
> 

-- 
Sincerely yours,
Mike.

[PATCH 2/4] mm: Fix get_mctgt_type() kernel-doc

[Matthew Wilcox (Oracle)]

Convert the return values to an ReST list and tidy up the wording while
I'm touching it.

Signed-off-by: Matthew Wilcox (Oracle) <willy-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
---
 mm/memcontrol.c | 31 +++++++++++++------------------
 1 file changed, 13 insertions(+), 18 deletions(-)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index e041ba827e59..cd8b3ae6b8d9 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -5850,25 +5850,20 @@ static int mem_cgroup_move_account(struct page *page,
  * @ptent: the pte to be checked
  * @target: the pointer the target page or swap ent will be stored(can be NULL)
  *
- * Returns
- *   0(MC_TARGET_NONE): if the pte is not a target for move charge.
- *   1(MC_TARGET_PAGE): if the page corresponding to this pte is a target for
- *     move charge. if @target is not NULL, the page is stored in target->page
- *     with extra refcnt got(Callers should handle it).
- *   2(MC_TARGET_SWAP): if the swap entry corresponding to this pte is a
- *     target for charge migration. if @target is not NULL, the entry is stored
- *     in target->ent.
- *   3(MC_TARGET_DEVICE): like MC_TARGET_PAGE  but page is device memory and
- *   thus not on the lru.
- *     For now we such page is charge like a regular page would be as for all
- *     intent and purposes it is just special memory taking the place of a
- *     regular page.
- *
- *     See Documentations/vm/hmm.txt and include/linux/hmm.h
- *
- * Called with pte lock held.
+ * Context: Called with pte lock held.
+ * Return:
+ * * MC_TARGET_NONE - If the pte is not a target for move charge.
+ * * MC_TARGET_PAGE - If the page corresponding to this pte is a target for
+ *   move charge. If @target is not NULL, the page is stored in target->page
+ *   with extra refcnt got (Callers should handle it).
+ * * MC_TARGET_SWAP - If the swap entry corresponding to this pte is a
+ *   target for charge migration. if @target is not NULL, the entry is stored
+ *   in target->ent.
+ * * MC_TARGET_DEVICE - Like MC_TARGET_PAGE but page is device memory and
+ *   thus not on the lru.  For now such page is charged like a regular page
+ *   would be as it is just special memory taking the place of a regular page.
+ *   See Documentations/vm/hmm.txt and include/linux/hmm.h
  */
-
 static enum mc_target_type get_mctgt_type(struct vm_area_struct *vma,
 		unsigned long addr, pte_t ptent, union mc_target *target)
 {
-- 
2.40.1

Re: [PATCH 2/4] mm: Fix get_mctgt_type() kernel-doc

[Randy Dunlap]

On 8/18/23 13:06, Matthew Wilcox (Oracle) wrote:
> Convert the return values to an ReST list and tidy up the wording while
> I'm touching it.
> 
> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> ---
>  mm/memcontrol.c | 31 +++++++++++++------------------
>  1 file changed, 13 insertions(+), 18 deletions(-)
> 
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index e041ba827e59..cd8b3ae6b8d9 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -5850,25 +5850,20 @@ static int mem_cgroup_move_account(struct page *page,
>   * @ptent: the pte to be checked
>   * @target: the pointer the target page or swap ent will be stored(can be NULL)
>   *
> - * Returns
> - *   0(MC_TARGET_NONE): if the pte is not a target for move charge.
> - *   1(MC_TARGET_PAGE): if the page corresponding to this pte is a target for
> - *     move charge. if @target is not NULL, the page is stored in target->page
> - *     with extra refcnt got(Callers should handle it).
> - *   2(MC_TARGET_SWAP): if the swap entry corresponding to this pte is a
> - *     target for charge migration. if @target is not NULL, the entry is stored
> - *     in target->ent.
> - *   3(MC_TARGET_DEVICE): like MC_TARGET_PAGE  but page is device memory and
> - *   thus not on the lru.
> - *     For now we such page is charge like a regular page would be as for all
> - *     intent and purposes it is just special memory taking the place of a
> - *     regular page.
> - *
> - *     See Documentations/vm/hmm.txt and include/linux/hmm.h
> - *
> - * Called with pte lock held.
> + * Context: Called with pte lock held.
> + * Return:
> + * * MC_TARGET_NONE - If the pte is not a target for move charge.
> + * * MC_TARGET_PAGE - If the page corresponding to this pte is a target for
> + *   move charge. If @target is not NULL, the page is stored in target->page
> + *   with extra refcnt got (Callers should handle it).

I would s/got/taken/.

> + * * MC_TARGET_SWAP - If the swap entry corresponding to this pte is a
> + *   target for charge migration. if @target is not NULL, the entry is stored

s/if/If/

> + *   in target->ent.
> + * * MC_TARGET_DEVICE - Like MC_TARGET_PAGE but page is device memory and
> + *   thus not on the lru.  For now such page is charged like a regular page
> + *   would be as it is just special memory taking the place of a regular page.
> + *   See Documentations/vm/hmm.txt and include/linux/hmm.h
>   */
> -
>  static enum mc_target_type get_mctgt_type(struct vm_area_struct *vma,
>  		unsigned long addr, pte_t ptent, union mc_target *target)
>  {

Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.

-- 
~Randy

Re: [PATCH 2/4] mm: Fix get_mctgt_type() kernel-doc

[Mike Rapoport]

On Fri, Aug 18, 2023 at 09:06:28PM +0100, Matthew Wilcox (Oracle) wrote:
> Convert the return values to an ReST list and tidy up the wording while
> I'm touching it.
> 
> Signed-off-by: Matthew Wilcox (Oracle) <willy-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>

Acked-by: Mike Rapoport (IBM) <rppt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

> ---
>  mm/memcontrol.c | 31 +++++++++++++------------------
>  1 file changed, 13 insertions(+), 18 deletions(-)
> 
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index e041ba827e59..cd8b3ae6b8d9 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -5850,25 +5850,20 @@ static int mem_cgroup_move_account(struct page *page,
>   * @ptent: the pte to be checked
>   * @target: the pointer the target page or swap ent will be stored(can be NULL)
>   *
> - * Returns
> - *   0(MC_TARGET_NONE): if the pte is not a target for move charge.
> - *   1(MC_TARGET_PAGE): if the page corresponding to this pte is a target for
> - *     move charge. if @target is not NULL, the page is stored in target->page
> - *     with extra refcnt got(Callers should handle it).
> - *   2(MC_TARGET_SWAP): if the swap entry corresponding to this pte is a
> - *     target for charge migration. if @target is not NULL, the entry is stored
> - *     in target->ent.
> - *   3(MC_TARGET_DEVICE): like MC_TARGET_PAGE  but page is device memory and
> - *   thus not on the lru.
> - *     For now we such page is charge like a regular page would be as for all
> - *     intent and purposes it is just special memory taking the place of a
> - *     regular page.
> - *
> - *     See Documentations/vm/hmm.txt and include/linux/hmm.h
> - *
> - * Called with pte lock held.
> + * Context: Called with pte lock held.
> + * Return:
> + * * MC_TARGET_NONE - If the pte is not a target for move charge.
> + * * MC_TARGET_PAGE - If the page corresponding to this pte is a target for
> + *   move charge. If @target is not NULL, the page is stored in target->page
> + *   with extra refcnt got (Callers should handle it).
> + * * MC_TARGET_SWAP - If the swap entry corresponding to this pte is a
> + *   target for charge migration. if @target is not NULL, the entry is stored
> + *   in target->ent.
> + * * MC_TARGET_DEVICE - Like MC_TARGET_PAGE but page is device memory and
> + *   thus not on the lru.  For now such page is charged like a regular page
> + *   would be as it is just special memory taking the place of a regular page.
> + *   See Documentations/vm/hmm.txt and include/linux/hmm.h
>   */
> -
>  static enum mc_target_type get_mctgt_type(struct vm_area_struct *vma,
>  		unsigned long addr, pte_t ptent, union mc_target *target)
>  {
> -- 
> 2.40.1
> 

-- 
Sincerely yours,
Mike.

[PATCH 3/4] mm: Fix clean_record_shared_mapping_range kernel-doc

[Matthew Wilcox (Oracle)]

Turn the a), b) into an unordered ReST list and remove the unnecessary
'Note:' prefix.

Signed-off-by: Matthew Wilcox (Oracle) <willy-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
---
 mm/mapping_dirty_helpers.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/mm/mapping_dirty_helpers.c b/mm/mapping_dirty_helpers.c
index a26dd8bcfcdb..2f8829b3541a 100644
--- a/mm/mapping_dirty_helpers.c
+++ b/mm/mapping_dirty_helpers.c
@@ -288,13 +288,14 @@ EXPORT_SYMBOL_GPL(wp_shared_mapping_range);
  * @end: Pointer to the number of the last set bit in @bitmap.
  * none set. The value is modified as new bits are set by the function.
  *
- * Note: When this function returns there is no guarantee that a CPU has
+ * When this function returns there is no guarantee that a CPU has
  * not already dirtied new ptes. However it will not clean any ptes not
  * reported in the bitmap. The guarantees are as follows:
- * a) All ptes dirty when the function starts executing will end up recorded
- *    in the bitmap.
- * b) All ptes dirtied after that will either remain dirty, be recorded in the
- *    bitmap or both.
+ *
+ * * All ptes dirty when the function starts executing will end up recorded
+ *   in the bitmap.
+ * * All ptes dirtied after that will either remain dirty, be recorded in the
+ *   bitmap or both.
  *
  * If a caller needs to make sure all dirty ptes are picked up and none
  * additional are added, it first needs to write-protect the address-space
-- 
2.40.1

Re: [PATCH 3/4] mm: Fix clean_record_shared_mapping_range kernel-doc

[Randy Dunlap]

On 8/18/23 13:06, Matthew Wilcox (Oracle) wrote:
> Turn the a), b) into an unordered ReST list and remove the unnecessary
> 'Note:' prefix.
> 
> Signed-off-by: Matthew Wilcox (Oracle) <willy-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>

Acked-by: Randy Dunlap <rdunlap-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Thanks.

> ---
>  mm/mapping_dirty_helpers.c | 11 ++++++-----
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/mm/mapping_dirty_helpers.c b/mm/mapping_dirty_helpers.c
> index a26dd8bcfcdb..2f8829b3541a 100644
> --- a/mm/mapping_dirty_helpers.c
> +++ b/mm/mapping_dirty_helpers.c
> @@ -288,13 +288,14 @@ EXPORT_SYMBOL_GPL(wp_shared_mapping_range);
>   * @end: Pointer to the number of the last set bit in @bitmap.
>   * none set. The value is modified as new bits are set by the function.
>   *
> - * Note: When this function returns there is no guarantee that a CPU has
> + * When this function returns there is no guarantee that a CPU has
>   * not already dirtied new ptes. However it will not clean any ptes not
>   * reported in the bitmap. The guarantees are as follows:
> - * a) All ptes dirty when the function starts executing will end up recorded
> - *    in the bitmap.
> - * b) All ptes dirtied after that will either remain dirty, be recorded in the
> - *    bitmap or both.
> + *
> + * * All ptes dirty when the function starts executing will end up recorded
> + *   in the bitmap.
> + * * All ptes dirtied after that will either remain dirty, be recorded in the
> + *   bitmap or both.
>   *
>   * If a caller needs to make sure all dirty ptes are picked up and none
>   * additional are added, it first needs to write-protect the address-space

-- 
~Randy

Re: [PATCH 3/4] mm: Fix clean_record_shared_mapping_range kernel-doc

[Mike Rapoport]

On Fri, Aug 18, 2023 at 09:06:29PM +0100, Matthew Wilcox (Oracle) wrote:
> Turn the a), b) into an unordered ReST list and remove the unnecessary
> 'Note:' prefix.
> 
> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>

Acked-by: Mike Rapoport (IBM) <rppt@kernel.org>

> ---
>  mm/mapping_dirty_helpers.c | 11 ++++++-----
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/mm/mapping_dirty_helpers.c b/mm/mapping_dirty_helpers.c
> index a26dd8bcfcdb..2f8829b3541a 100644
> --- a/mm/mapping_dirty_helpers.c
> +++ b/mm/mapping_dirty_helpers.c
> @@ -288,13 +288,14 @@ EXPORT_SYMBOL_GPL(wp_shared_mapping_range);
>   * @end: Pointer to the number of the last set bit in @bitmap.
>   * none set. The value is modified as new bits are set by the function.
>   *
> - * Note: When this function returns there is no guarantee that a CPU has
> + * When this function returns there is no guarantee that a CPU has
>   * not already dirtied new ptes. However it will not clean any ptes not
>   * reported in the bitmap. The guarantees are as follows:
> - * a) All ptes dirty when the function starts executing will end up recorded
> - *    in the bitmap.
> - * b) All ptes dirtied after that will either remain dirty, be recorded in the
> - *    bitmap or both.
> + *
> + * * All ptes dirty when the function starts executing will end up recorded
> + *   in the bitmap.
> + * * All ptes dirtied after that will either remain dirty, be recorded in the
> + *   bitmap or both.
>   *
>   * If a caller needs to make sure all dirty ptes are picked up and none
>   * additional are added, it first needs to write-protect the address-space
> -- 
> 2.40.1
> 

-- 
Sincerely yours,
Mike.

[PATCH 4/4] mm: Add orphaned kernel-doc to the rst files.

[Matthew Wilcox (Oracle)]

There are many files in mm/ that contain kernel-doc which is not
currently published on kernel.org.  Some of it is easily categorisable,
but most of it is going into the miscellaneous documentation section to
be organised later.

Some files aren't ready to be included; they contain documentation with
build errors.  Or they're nommu.c which duplicates documentation from
"real" MMU systems.  Those files are noted with a # mark (although really
anything which isn't a recognised directive would do to prevent inclusion)

Signed-off-by: Matthew Wilcox (Oracle) <willy-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
---
 Documentation/core-api/mm-api.rst | 25 +++++++++++++++++++++++++
 Documentation/mm/highmem.rst      |  1 +
 Documentation/mm/zsmalloc.rst     |  5 +++++
 3 files changed, 31 insertions(+)

diff --git a/Documentation/core-api/mm-api.rst b/Documentation/core-api/mm-api.rst
index f5dde5bceaea..2d091c873d1e 100644
--- a/Documentation/core-api/mm-api.rst
+++ b/Documentation/core-api/mm-api.rst
@@ -115,3 +115,28 @@ More Memory Management Functions
 .. kernel-doc:: include/linux/mmzone.h
 .. kernel-doc:: mm/util.c
    :functions: folio_mapping
+
+.. kernel-doc:: mm/rmap.c
+.. kernel-doc:: mm/migrate.c
+.. kernel-doc:: mm/mmap.c
+.. kernel-doc:: mm/kmemleak.c
+.. #kernel-doc:: mm/hmm.c (build warnings)
+.. kernel-doc:: mm/memremap.c
+.. kernel-doc:: mm/hugetlb.c
+.. kernel-doc:: mm/swap.c
+.. kernel-doc:: mm/zpool.c
+.. kernel-doc:: mm/memcontrol.c
+.. #kernel-doc:: mm/memory-tiers.c (build warnings)
+.. kernel-doc:: mm/shmem.c
+.. kernel-doc:: mm/migrate_device.c
+.. #kernel-doc:: mm/nommu.c (duplicates kernel-doc from other files)
+.. kernel-doc:: mm/mapping_dirty_helpers.c
+.. #kernel-doc:: mm/memory-failure.c (build warnings)
+.. kernel-doc:: mm/percpu.c
+.. kernel-doc:: mm/maccess.c
+.. kernel-doc:: mm/vmscan.c
+.. kernel-doc:: mm/memory_hotplug.c
+.. kernel-doc:: mm/mmu_notifier.c
+.. kernel-doc:: mm/balloon_compaction.c
+.. kernel-doc:: mm/huge_memory.c
+.. kernel-doc:: mm/io-mapping.c
diff --git a/Documentation/mm/highmem.rst b/Documentation/mm/highmem.rst
index fe68e02fc8ff..9d92e3f2b3d6 100644
--- a/Documentation/mm/highmem.rst
+++ b/Documentation/mm/highmem.rst
@@ -209,4 +209,5 @@ Functions
 =========
 
 .. kernel-doc:: include/linux/highmem.h
+.. kernel-doc:: mm/highmem.c
 .. kernel-doc:: include/linux/highmem-internal.h
diff --git a/Documentation/mm/zsmalloc.rst b/Documentation/mm/zsmalloc.rst
index a3c26d587752..76902835e68e 100644
--- a/Documentation/mm/zsmalloc.rst
+++ b/Documentation/mm/zsmalloc.rst
@@ -263,3 +263,8 @@ is heavy internal fragmentation and zspool compaction is unable to relocate
 objects and release zspages. In these cases, it is recommended to decrease
 the limit on the size of the zspage chains (as specified by the
 CONFIG_ZSMALLOC_CHAIN_SIZE option).
+
+Functions
+=========
+
+.. kernel-doc:: mm/zsmalloc.c
-- 
2.40.1

Re: [PATCH 4/4] mm: Add orphaned kernel-doc to the rst files.

[Mike Rapoport]

On Fri, Aug 18, 2023 at 09:06:30PM +0100, Matthew Wilcox (Oracle) wrote:
> There are many files in mm/ that contain kernel-doc which is not
> currently published on kernel.org.  Some of it is easily categorisable,
> but most of it is going into the miscellaneous documentation section to
> be organised later.
> 
> Some files aren't ready to be included; they contain documentation with
> build errors.  Or they're nommu.c which duplicates documentation from
> "real" MMU systems.  Those files are noted with a # mark (although really
> anything which isn't a recognised directive would do to prevent inclusion)
> 
> Signed-off-by: Matthew Wilcox (Oracle) <willy-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>

Acked-by: Mike Rapoport (IBM) <rppt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

> ---
>  Documentation/core-api/mm-api.rst | 25 +++++++++++++++++++++++++
>  Documentation/mm/highmem.rst      |  1 +
>  Documentation/mm/zsmalloc.rst     |  5 +++++
>  3 files changed, 31 insertions(+)
> 
> diff --git a/Documentation/core-api/mm-api.rst b/Documentation/core-api/mm-api.rst
> index f5dde5bceaea..2d091c873d1e 100644
> --- a/Documentation/core-api/mm-api.rst
> +++ b/Documentation/core-api/mm-api.rst
> @@ -115,3 +115,28 @@ More Memory Management Functions
>  .. kernel-doc:: include/linux/mmzone.h
>  .. kernel-doc:: mm/util.c
>     :functions: folio_mapping
> +
> +.. kernel-doc:: mm/rmap.c
> +.. kernel-doc:: mm/migrate.c
> +.. kernel-doc:: mm/mmap.c
> +.. kernel-doc:: mm/kmemleak.c
> +.. #kernel-doc:: mm/hmm.c (build warnings)
> +.. kernel-doc:: mm/memremap.c
> +.. kernel-doc:: mm/hugetlb.c
> +.. kernel-doc:: mm/swap.c
> +.. kernel-doc:: mm/zpool.c
> +.. kernel-doc:: mm/memcontrol.c
> +.. #kernel-doc:: mm/memory-tiers.c (build warnings)
> +.. kernel-doc:: mm/shmem.c
> +.. kernel-doc:: mm/migrate_device.c
> +.. #kernel-doc:: mm/nommu.c (duplicates kernel-doc from other files)
> +.. kernel-doc:: mm/mapping_dirty_helpers.c
> +.. #kernel-doc:: mm/memory-failure.c (build warnings)
> +.. kernel-doc:: mm/percpu.c
> +.. kernel-doc:: mm/maccess.c
> +.. kernel-doc:: mm/vmscan.c
> +.. kernel-doc:: mm/memory_hotplug.c
> +.. kernel-doc:: mm/mmu_notifier.c
> +.. kernel-doc:: mm/balloon_compaction.c
> +.. kernel-doc:: mm/huge_memory.c
> +.. kernel-doc:: mm/io-mapping.c
> diff --git a/Documentation/mm/highmem.rst b/Documentation/mm/highmem.rst
> index fe68e02fc8ff..9d92e3f2b3d6 100644
> --- a/Documentation/mm/highmem.rst
> +++ b/Documentation/mm/highmem.rst
> @@ -209,4 +209,5 @@ Functions
>  =========
>  
>  .. kernel-doc:: include/linux/highmem.h
> +.. kernel-doc:: mm/highmem.c
>  .. kernel-doc:: include/linux/highmem-internal.h
> diff --git a/Documentation/mm/zsmalloc.rst b/Documentation/mm/zsmalloc.rst
> index a3c26d587752..76902835e68e 100644
> --- a/Documentation/mm/zsmalloc.rst
> +++ b/Documentation/mm/zsmalloc.rst
> @@ -263,3 +263,8 @@ is heavy internal fragmentation and zspool compaction is unable to relocate
>  objects and release zspages. In these cases, it is recommended to decrease
>  the limit on the size of the zspage chains (as specified by the
>  CONFIG_ZSMALLOC_CHAIN_SIZE option).
> +
> +Functions
> +=========
> +
> +.. kernel-doc:: mm/zsmalloc.c
> -- 
> 2.40.1
> 

-- 
Sincerely yours,
Mike.