linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: Jonathan Corbet <corbet@lwn.net>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Suren Baghdasaryan <surenb@google.com>,
	"Liam R . Howlett" <Liam.Howlett@oracle.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	Shakeel Butt <shakeel.butt@linux.dev>,
	Jann Horn <jannh@google.com>,
	Qi Zheng <zhengqi.arch@bytedance.com>,
	linux-mm@kvack.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] docs/mm: expand vma doc to highlight pte freeing, non-vma traversal
Date: Tue, 3 Jun 2025 15:24:23 +0100	[thread overview]
Message-ID: <ea8c2be9-0af0-445b-b7fe-fd9e80bd6a65@lucifer.local> (raw)
In-Reply-To: <8734cg9auh.fsf@trenco.lwn.net>

On Tue, Jun 03, 2025 at 08:08:22AM -0600, Jonathan Corbet wrote:
> Lorenzo Stoakes <lorenzo.stoakes@oracle.com> writes:
>
> > On Mon, Jun 02, 2025 at 03:38:55PM -0600, Jonathan Corbet wrote:
> >> Lorenzo Stoakes <lorenzo.stoakes@oracle.com> writes:
> >>
> >> > --- a/Documentation/mm/process_addrs.rst
> >> > +++ b/Documentation/mm/process_addrs.rst
> >> > @@ -303,7 +303,9 @@ There are four key operations typically performed on page tables:
> >> >  1. **Traversing** page tables - Simply reading page tables in order to traverse
> >> >     them. This only requires that the VMA is kept stable, so a lock which
> >> >     establishes this suffices for traversal (there are also lockless variants
> >> > -   which eliminate even this requirement, such as :c:func:`!gup_fast`).
> >> > +   which eliminate even this requirement, such as :c:func:`!gup_fast`). There is
> >> > +   also a special case of page table traversal for non-VMA regions which we
> >>
> >> The "!gup_fast" caught my attention - I was unaware that Sphinx had such
> >> a thing.  Its purpose would be to appear to suppress the generation of the
> >> link that turns the cross reference into a cross reference.
> >>
> >> The MM docs are full of these, do we know why?
> >
> > Removing it from the struct vm_area_struct struct immediately give:
> >
> > /home/lorenzo/kerndev/kernels/mm/Documentation/mm/process_addrs.rst:11: WARNING: Unparseable C cross-reference: 'struct vm_area_struct'
> > Invalid C declaration: Expected identifier in nested name, got keyword: struct [error at 6]
> >   struct vm_area_struct
> >
> > And given C's weirdness with typing I really prefer to be explicit in
> > referencing a struct vs. e.g. a typedef.
>
> That's because the :c:struct: markup doesn't want the word "struct" in
> there.  In this case, the "!" is being used, essentially, to hide the
> fact that the Sphinx markup is being entirely misused here.  You would
> be far better off just saying:
>
>   **struct vm_area_struct**
>
> and avoiding the uglier markup in this case.

I can go change that.

But to repeat - 'given C's weirdness with typing I really prefer to be
explicit in referencing a struct vs. e.g. a typedef.'

I'm not doing this with an intent of Sphix misuse, it's with intent of
being as clear as possible.

>
> Once again, taking out the markup entirely will cause the automarkup
> code to do the right thing, with the proviso that undocumented
> structures (which, tragically, includes struct vm_area_struct) won't be
> marked up in the current implementation.  By far the best solution here
> is to remove all of the markup and add a kerneldoc comment for this
> rather important structure.
>
> > At any rate I'm not sure it's all that useful to cross-reference these?
>
> Why would you *not* want to cross-reference something and make life easier
> for your reader?

Because it apparently requires me to document every function I reference?
Unless I'm missing something?

I may be misunderstanding you.

If not then fine, I can delay this patch, go off and do a 'cleanup' patch
first, that will drop the '!'s and come back to this.

But if I need to document every referenced function that just isn't
feasible for me with my current workload.

Please clarify!

>
> Thanks,
>
> jon


  reply	other threads:[~2025-06-03 14:24 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-02 21:07 Lorenzo Stoakes
2025-06-02 21:38 ` Jonathan Corbet
2025-06-03 10:56   ` Lorenzo Stoakes
2025-06-03 11:24     ` Lorenzo Stoakes
2025-06-03 14:01       ` Jonathan Corbet
2025-06-03 14:11         ` Lorenzo Stoakes
2025-06-03 14:33           ` Jonathan Corbet
2025-06-03 14:08     ` Jonathan Corbet
2025-06-03 14:24       ` Lorenzo Stoakes [this message]
2025-06-03 14:37         ` Jonathan Corbet
2025-06-03 14:52           ` Lorenzo Stoakes
2025-06-03 15:05             ` Jonathan Corbet
2025-06-03 15:14               ` Lorenzo Stoakes
2025-06-03 15:28                 ` Jonathan Corbet
2025-06-02 22:25 ` Jann Horn
2025-06-03 10:45   ` Lorenzo Stoakes
2025-06-03 18:36     ` Jann Horn
2025-06-03 18:52       ` Lorenzo Stoakes

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=ea8c2be9-0af0-445b-b7fe-fd9e80bd6a65@lucifer.local \
    --to=lorenzo.stoakes@oracle.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=corbet@lwn.net \
    --cc=jannh@google.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=shakeel.butt@linux.dev \
    --cc=surenb@google.com \
    --cc=vbabka@suse.cz \
    --cc=zhengqi.arch@bytedance.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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