[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87o6y5lvvg.fsf@trenco.lwn.net>
Date: Wed, 12 Mar 2025 16:36:19 -0600
From: Jonathan Corbet <corbet@....net>
To: Ignacio Encinas <ignacio@...cinas.com>,
linux-kernel-mentees@...ts.linux.dev, skhan@...uxfoundation.org, Marco
Elver <elver@...gle.com>, Dmitry Vyukov <dvyukov@...gle.com>
Cc: kasan-dev@...glegroups.com, workflows@...r.kernel.org,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org, Ignacio Encinas
<ignacio@...cinas.com>
Subject: Re: [PATCH] Documentation: kcsan: fix "Plain Accesses and Data
Races" URL in kcsan.rst
Ignacio Encinas <ignacio@...cinas.com> writes:
> Make the URL point to the "Plain Accesses and Data Races" section again
> and prevent it from becoming stale by adding a commit id to it.
>
> Signed-off-by: Ignacio Encinas <ignacio@...cinas.com>
> ---
> I noticed this while reviewing the documentation.
>
> The "fix" isn't perfect as the link might become stale because it points
> to a fixed commit. Alternatively, we could lose the line number
> altogether.
> ---
> Documentation/dev-tools/kcsan.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/dev-tools/kcsan.rst b/Documentation/dev-tools/kcsan.rst
> index d81c42d1063eab5db0cba1786de287406ca3ebe7..8575178aa87f1402d777af516f5c0e2fc8a3379d 100644
> --- a/Documentation/dev-tools/kcsan.rst
> +++ b/Documentation/dev-tools/kcsan.rst
> @@ -203,7 +203,7 @@ they happen concurrently in different threads, and at least one of them is a
> least one is a write. For a more thorough discussion and definition, see `"Plain
> Accesses and Data Races" in the LKMM`_.
>
> -.. _"Plain Accesses and Data Races" in the LKMM: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/memory-model/Documentation/explanation.txt#n1922
> +.. _"Plain Accesses and Data Races" in the LKMM: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/memory-model/Documentation/explanation.txt?id=8f6629c004b193d23612641c3607e785819e97ab#n2164
>
This seems like an improvement over what we have, so I've applied it.
It would be best, of course, to get the memory-model documentation
properly into our built docs...someday...
Thanks,
jon
Powered by blists - more mailing lists