linux-kernel - Re: [PATCH -next 0/6] Patches for v6.17

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a5aeaec7-d4fc-47e1-b618-e7c768dada54@gmail.com>
Date: Sun, 20 Jul 2025 13:30:57 +0900
From: Akira Yokosawa <akiyks@...il.com>
To: joelagnelf@...dia.com, neeraj.iitr10@...il.com
Cc: linux-kernel@...r.kernel.org, paulmck@...nel.org, rcu@...r.kernel.org,
 Frederic Weisbecker <frederic@...nel.org>, Akira Yokosawa <akiyks@...il.com>
Subject: Re: [PATCH -next 0/6] Patches for v6.17

[+CC Frederic]

Hi Joel and Neeraj,

Belated drive-by review.  Please see below.

On Tue, 15 Jul 2025 16:01:50 -0400, Joel Fernandes wrote:
> Just a repost of patches with tags, for our consideration into v6.17.
> 
> All have tags, and the last commit is a fixup for the deadloop patch which can
> be squashed into the original patch.
> 
> Joel Fernandes (6):
>   smp: Document preemption and stop_machine() mutual exclusion
>   rcu: Refactor expedited handling check in rcu_read_unlock_special()
>   rcu: Document GP init vs hotplug-scan ordering requirements
>   rcu: Document separation of rcu_state and rnp's gp_seq
>   rcu: Document concurrent quiescent state reporting for offline CPUs
>   [please squash] fixup! rcu: Fix rcu_read_unlock() deadloop due to IRQ
>     work

There seems to be a couple of issues in the S-O-B chains of commits listed
below (in rcu/next):

 * dcf1668449c9 ("rcu: Document GP init vs hotplug-scan ordering requirements")
 * bb1c373934db ("rcu: Document concurrent quiescent state reporting for offline CPUs")

They have a "Co-developed-by:" tag without a corresponding "Signed-off-by:"
tag [1].

Or, if the contribution is too minor to have a "Signed-off-by:",
then a "Suggested-by:" tag with a "Link:" to the relevant message should
suffice.

I have no idea which approach suits better in each commit above.

[1]: Documentation/process/submitting-patches.rst
     section "When to use Acked-by:, Cc:, and Co-developed-by:"

Quoting relevant paragraph:

  Co-developed-by: states that the patch was co-created by multiple developers;
  it is used to give attribution to co-authors (in addition to the author
  attributed by the From: tag) when several people work on a single patch.  Since
  Co-developed-by: denotes authorship, every Co-developed-by: must be immediately
  followed by a Signed-off-by: of the associated co-author.  Standard sign-off
  procedure applies, i.e. the ordering of Signed-off-by: tags should reflect the
  chronological history of the patch insofar as possible, regardless of whether
  the author is attributed via From: or Co-developed-by:.  Notably, the last
  Signed-off-by: must always be that of the developer submitting the patch.

Side note:
  scripts/checkpatch.pl would have complained about those missing
  Signed-off-by: tags.

> 
>  .../Data-Structures/Data-Structures.rst       |  32 +++++
>  .../RCU/Design/Requirements/Requirements.rst  | 128 ++++++++++++++++++

I'm seeing sub-optimal uses of reST markups in Requirements.rst from kernel
documentation stand point.

I'm going to submit a patch or two to improve them, but I can't promise when.
They will likely be only cosmetic cleanups and I'm OK with it upstreamed as
it is.

        Thanks, Akira

>  kernel/rcu/tree.c                             |  31 ++++-
>  kernel/rcu/tree.h                             |  10 +-
>  kernel/rcu/tree_plugin.h                      |  90 ++++++++++--
>  kernel/smp.c                                  |  26 ++--
>  6 files changed, 293 insertions(+), 24 deletions(-)
> 
> -- 
> 2.34.1