linux-kernel - Re: [PATCH v3] sched/rt: Skip currently executing CPU in rto_next_cpu()

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] [day] [month] [year] [list]

Message-ID: <20251204104445.5c937ee1@gandalf.local.home>
Date: Thu, 4 Dec 2025 10:44:45 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Chen Jinghuang <chenjinghuang2@...wei.com>
Cc: <bsegall@...gle.com>, <dietmar.eggemann@....com>,
 <juri.lelli@...hat.com>, <linux-kernel@...r.kernel.org>, <mgorman@...e.de>,
 <mingo@...hat.com>, <peterz@...radead.org>, <vincent.guittot@...aro.org>,
 <vschneid@...hat.com>
Subject: Re: [PATCH v3] sched/rt: Skip currently executing CPU in
 rto_next_cpu() - Request for merge

On Thu, 4 Dec 2025 07:35:44 +0000
Chen Jinghuang <chenjinghuang2@...wei.com> wrote:

> Hi Steven Rostedt,
> 
> This is a follow-up on my v3 patch for sched/rt: "Skip currently executing
> CPU in rto_next_cpu()" (archive link:
> https://lore.kernel.org/lkml/20251126055403.2076735-1-chenjinghuang2@huawei.com/)
> 
> You previously confirmed that this patch resolves the issue of a CPU
> sending an IPI to itself. This patch has also fully resolved the issue

I didn't confirm it resolved the issue. I just said it looks like it would.
I'm not the one that found the bug. I would assume the one that found this
issue tested this new patch and confirmed that it passed.

> I encountered in my testing environment. Could you please help merge this
> v3 patch into mainline? I'm happy to address any code review.
> 
> Thanks a lot for your time and review!

I already gave my reviewed-by tag. It's Peter Zijlstra that needs to accept
it. I'm only a reviewer and not one of the scheduling maintainers.

One issue you have here is that you are replying to the previous patch with
a new patch. That's not how it works. A new patch must be a start of a new
thread. Otherwise it gets very confusing for the maintainer, and most of
the time, maintainers miss these new patches embedded into threads of old
patches.

What you should also do is reference the lore link in your "changes"
portion after the '---'. For example, v3 should have been a new thread with
the following:

Fixes: 4bdced5c9a292 ("sched/rt: Simplify the IPI based RT balancing logic")
Suggested-by: Steven Rostedt (Google) <rostedt@...dmis.org>
Signed-off-by: Chen Jinghuang <chenjinghuang2@...wei.com>
Reviewed-by: Steven Rostedt (Google) <rostedt@...dmis.org>
---
Changes since v2: https://lore.kernel.org/all/20251125083649.1814558-1-chenjinghuang2@huawei.com/

- Replace the original "check NEED_RESCHED on target CPU"
  logic with "skip the currently executing CPU"
- This modification eliminates self-IPIS

And the patch of v2 should have had:

Changes since v1: https://lore.kernel.org/all/20251121014004.564508-1-chenjinghuang2@huawei.com/
- Remove unneeded extra whitespace
- Add Reviewed-by tag from Steven Rostedt

And that allows people to find the previous version of the patch without
having the new version be a reply to it.

-- Steve