public inbox for linux-next@vger.kernel.org 
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat•com>
To: Stephen Rothwell <sfr@canb•auug.org.au>,
	Andrew Morton <akpm@linux-foundation•org>
Cc: Linux Kernel Mailing List <linux-kernel@vger•kernel.org>,
	Linux Next Mailing List <linux-next@vger•kernel.org>
Subject: Re: linux-next: build warning after merge of the mm tree
Date: Mon, 25 Mar 2024 09:56:27 +0100	[thread overview]
Message-ID: <074ff62c-1533-4566-9375-24e353b53712@redhat.com> (raw)
In-Reply-To: <20240325122250.48128d5a@canb.auug.org.au>

On 25.03.24 02:22, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the mm tree, today's linux-next build (htmldocs) produced
> this warning:
> 
> Documentation/core-api/mm-api:112: include/linux/mm.h:2187: ERROR: Unexpected indentation.
> Documentation/core-api/mm-api:112: include/linux/mm.h:2189: WARNING: Block quote ends without a blank line; unexpected unindent.
> Documentation/core-api/mm-api:112: include/linux/mm.h:2199: ERROR: Unexpected indentation.
> Documentation/core-api/mm-api:112: include/linux/mm.h:2200: WARNING: Block quote ends without a blank line; unexpected unindent.
> 
> Introduced by commit
> 
>    08ec651d776e ("mm: convert folio_estimated_sharers() to folio_likely_mapped_shared()")
> 
> from the mm-unstable branch of the mm tree.
> 

Seems like kerneldoc does not appreciate my lists+indentation. The following
should get the job done:

 From 3e472636d266e3acba3755ed5712992adbc2151d Mon Sep 17 00:00:00 2001
From: David Hildenbrand <david@redhat•com>
Date: Mon, 25 Mar 2024 09:23:03 +0100
Subject: [PATCH] folio_likely_mapped_shared() kerneldoc fixup

Fixup "mm: convert folio_estimated_sharers() to
folio_likely_mapped_shared()".

Signed-off-by: David Hildenbrand <david@redhat•com>
---
  include/linux/mm.h | 32 +++++++++++++++++---------------
  1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index afe27ff3fa94..fb3724723448 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2183,23 +2183,25 @@ static inline size_t folio_size(struct folio *folio)
   * at most once into an MM, and they cannot be partially mapped.
   *
   * For other folios, the result can be fuzzy:
- * (a) For partially-mappable large folios (THP), the return value can wrongly
- *     indicate "mapped exclusively" (false negative) when the folio is
- *     only partially mapped into at least one MM.
- * (b) For pagecache folios (including hugetlb), the return value can wrongly
- *     indicate "mapped shared" (false positive) when two VMAs in the same MM
- *     cover the same file range.
- * (c) For (small) KSM folios, the return value can wrongly indicate "mapped
- *     shared" (false negative), when the folio is mapped multiple times into
- *     the same MM.
+ *    #. For partially-mappable large folios (THP), the return value can wrongly
+ *       indicate "mapped exclusively" (false negative) when the folio is
+ *       only partially mapped into at least one MM.
+ *    #. For pagecache folios (including hugetlb), the return value can wrongly
+ *       indicate "mapped shared" (false positive) when two VMAs in the same MM
+ *       cover the same file range.
+ *    #. For (small) KSM folios, the return value can wrongly indicate "mapped
+ *       shared" (false negative), when the folio is mapped multiple times into
+ *       the same MM.
   *
   * Further, this function only considers current page table mappings that
- * are tracked using the folio mapcount(s). It does not consider:
- * (1) If the folio might get mapped in the (near) future (e.g., swapcache,
- *     pagecache, temporary unmapping for migration).
- * (2) If the folio is mapped differently (VM_PFNMAP).
- * (3) If hugetlb page table sharing applies. Callers might want to check
- *     hugetlb_pmd_shared().
+ * are tracked using the folio mapcount(s).
+ *
+ * This function does not consider:
+ *    #. If the folio might get mapped in the (near) future (e.g., swapcache,
+ *       pagecache, temporary unmapping for migration).
+ *    #. If the folio is mapped differently (VM_PFNMAP).
+ *    #. If hugetlb page table sharing applies. Callers might want to check
+ *       hugetlb_pmd_shared().
   *
   * Return: Whether the folio is estimated to be mapped into more than one MM.
   */
-- 
2.43.2


-- 
Cheers,

David / dhildenb


  reply	other threads:[~2024-03-25  8:56 UTC|newest]

Thread overview: 93+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-25  1:22 linux-next: build warning after merge of the mm tree Stephen Rothwell
2024-03-25  8:56 ` David Hildenbrand [this message]
  -- strict thread matches above, loose matches on Subject: below --
2025-04-04  2:14 Stephen Rothwell
2025-04-05  6:30 ` Zhiquan Li
2025-03-28  6:46 Stephen Rothwell
2025-03-28 15:08 ` Kent Overstreet
2025-03-05  9:33 Stephen Rothwell
2025-03-05 18:28 ` SeongJae Park
2025-02-18 23:46 Stephen Rothwell
2025-02-14  9:57 Stephen Rothwell
2025-02-10  3:51 Stephen Rothwell
2025-01-09  4:27 Stephen Rothwell
2025-01-06  6:37 Stephen Rothwell
2025-01-06 18:39 ` SeongJae Park
2024-10-17  8:43 Stephen Rothwell
2024-10-17 16:53 ` Sabyrzhan Tasbolatov
2024-10-17 21:16   ` Andrew Morton
2024-09-03  5:37 Stephen Rothwell
2024-09-03  6:35 ` Sergey Senozhatsky
2024-09-02  6:30 Stephen Rothwell
2024-08-12  3:30 Stephen Rothwell
2024-08-12  4:40 ` Saurabh Singh Sengar
2024-08-12  3:24 Stephen Rothwell
2024-06-06  3:23 Stephen Rothwell
2024-06-06  5:01 ` Baolin Wang
2024-06-11 21:58   ` Andrew Morton
2024-06-12  0:47     ` Baolin Wang
2024-06-06  3:19 Stephen Rothwell
2024-06-06  3:36 ` Kefeng Wang
2024-05-07  6:26 Stephen Rothwell
2024-04-17  5:18 Stephen Rothwell
2024-04-17 15:57 ` Matthew Wilcox
2024-04-15  5:20 Stephen Rothwell
2024-04-15  5:45 ` Barry Song
2024-03-27 22:13 Stephen Rothwell
2024-03-28  1:59 ` Baoquan He
2024-03-28  4:29   ` Stephen Rothwell
2024-03-25  1:25 Stephen Rothwell
2024-03-26  2:21 ` Suren Baghdasaryan
2024-03-13  4:07 Stephen Rothwell
2024-03-13  9:00 ` Uwe Kleine-König
2024-03-13 15:22   ` Masahiro Yamada
2024-03-13 21:11     ` Uwe Kleine-König
2024-01-02  5:40 Stephen Rothwell
2024-01-02 12:54 ` Kirill A. Shutemov
2023-12-04  4:54 Stephen Rothwell
2023-12-04 17:03 ` SeongJae Park
2023-11-28  2:33 Stephen Rothwell
2023-10-04  4:46 Stephen Rothwell
2023-09-25 23:27 Stephen Rothwell
2023-09-18  3:18 Stephen Rothwell
2023-09-12  5:20 Stephen Rothwell
2023-06-05  3:10 Stephen Rothwell
2023-06-05 14:57 ` Liam R. Howlett
2023-05-15 23:25 Stephen Rothwell
2023-05-08  1:19 Stephen Rothwell
2023-05-08 21:36 ` Nhat Pham
2023-03-20  3:47 Stephen Rothwell
2023-03-23  2:58 ` Stephen Rothwell
2023-03-23 19:38   ` Andrew Morton
2023-03-16  1:12 Stephen Rothwell
2023-03-01  0:36 Stephen Rothwell
2023-03-01  0:47 ` Suren Baghdasaryan
2023-03-01  2:29   ` Suren Baghdasaryan
2023-03-01  5:45     ` Stephen Rothwell
2023-01-17  3:51 Stephen Rothwell
2022-12-17 19:22 Stephen Rothwell
2022-11-10  7:36 Stephen Rothwell
2022-11-10  7:33 Stephen Rothwell
2022-11-10 16:27 ` Linus Torvalds
2022-11-10 20:20   ` Randy Dunlap
2022-11-10 20:43     ` Jonathan Corbet
2022-10-26  0:57 Stephen Rothwell
2022-10-26  1:13 ` Sergey Senozhatsky
2022-09-19  9:09 Stephen Rothwell
2022-09-19  9:30 ` Miaohe Lin
2022-07-21  9:55 Stephen Rothwell
2022-07-21 11:11 ` Zach O'Keefe
2022-07-18 10:28 Stephen Rothwell
2022-07-18 22:54 ` Andrew Morton
2022-06-22  5:54 Stephen Rothwell
2022-06-22  7:11 ` Stephen Rothwell
2022-06-22 16:39   ` Mike Kravetz
2022-06-22 18:49     ` Andrew Morton
2022-05-25  5:54 Stephen Rothwell
2022-05-25 10:57 ` Zi Yan
2022-05-25 17:36   ` Andrew Morton
2022-05-12  9:46 Stephen Rothwell
2022-05-12 12:23 ` Johannes Weiner
2022-05-05 21:35 Stephen Rothwell
2022-05-05 21:38 ` Stephen Rothwell
2022-05-05 22:18 ` Matthew Wilcox
2022-04-28  7:44 Stephen Rothwell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=074ff62c-1533-4566-9375-24e353b53712@redhat.com \
    --to=david@redhat$(echo .)com \
    --cc=akpm@linux-foundation$(echo .)org \
    --cc=linux-kernel@vger$(echo .)kernel.org \
    --cc=linux-next@vger$(echo .)kernel.org \
    --cc=sfr@canb$(echo .)auug.org.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox