All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guopeng Zhang <guopeng.zhang@linux.dev>
To: Suren Baghdasaryan <surenb@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	Valentin Schneider <vschneid@redhat.com>,
	K Prateek Nayak <kprateek.nayak@amd.com>,
	Tejun Heo <tj@kernel.org>,
	Zhaoyang Huang <zhaoyang.huang@unisoc.com>,
	"ziwei.dai" <ziwei.dai@unisoc.com>,
	Chengming Zhou <zhouchengming@bytedance.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] sched/psi: Avoid losing wakeups during rtpoll worker replacement
Date: Fri, 7 Aug 2026 17:51:43 +0800	[thread overview]
Message-ID: <65ca1d4e-b11b-4d4c-9562-ef3e0a12c6db@linux.dev> (raw)
In-Reply-To: <CAJuCfpGG+VLcNGkL6aeazdnTQ+zcb_WPTzqkDd5npxBf8GQboA@mail.gmail.com>



在 2026/7/27 12:03, Suren Baghdasaryan 写道:
> On Fri, Jul 17, 2026 at 2:14 AM Guopeng Zhang <guopeng.zhang@linux.dev> wrote:
>>
>> From: Guopeng Zhang <zhangguopeng@kylinos.cn>
>>
>> psi_trigger_destroy() clears rtpoll_task while holding the trigger
>> lock, but has to drop the lock before stopping the worker because
>> psi_rtpoll_work() takes the same lock. A new trigger can therefore
>> install a replacement worker before the old one exits.
>>
>> rtpoll_wakeup is shared by both workers. The wait condition currently
> 
> To be clear, "both workers" refer to the old worked being stopped and
> the new worked created by psi_trigger_create(). Please spell that out
> to avoid confusion.
> 
Hi Suren,

Sorry for the late reply, I got tied up with some other work :)

Thanks for the review. Yes, I'll make that explicit in v2.

>> consumes it before checking whether the worker should stop. If the
>> replacement timer sets the wakeup while the old worker is being stopped,
>> the old worker can consume it and then exit. Since the one-shot timer has
>> already fired and rtpoll_scheduled remains set, the replacement can stay
>> asleep and rtpolling can stall.
>>
>> Make the wait condition only observe the wakeup. Check for stop before
>> consuming it and, once consumed, always process the work.
>>
>> Fixes: 461daba06bdc ("psi: eliminate kthread_worker from psi trigger scheduling mechanism")
>> Signed-off-by: Guopeng Zhang <zhangguopeng@kylinos.cn>
>> ---
>>  kernel/sched/psi.c | 8 +++++++-
>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/kernel/sched/psi.c b/kernel/sched/psi.c
>> index 4e152410653d..b9e2a93a757b 100644
>> --- a/kernel/sched/psi.c
>> +++ b/kernel/sched/psi.c
>> @@ -743,10 +743,16 @@ static int psi_rtpoll_worker(void *data)
>>
>>         while (true) {
>>                 wait_event_interruptible(group->rtpoll_wait,
>> -                               atomic_cmpxchg(&group->rtpoll_wakeup, 1, 0) ||
>> +                               atomic_read(&group->rtpoll_wakeup) ||
>>                                 kthread_should_stop());
>>                 if (kthread_should_stop())
>>                         break;
>> +               /*
>> +                * Consume the wakeup only after checking for stop. Once consumed,
>> +                * always run the work so a replacement worker cannot lose it.
>> +                */
>> +               if (atomic_cmpxchg(&group->rtpoll_wakeup, 1, 0) != 1)
>> +                       continue;
> 
> This works but a simpler fix is to reorder conditions in
> wait_event_interruptible() call like this:
> 
>          while (true) {
>                  wait_event_interruptible(group->rtpoll_wait,
>                                 kthread_should_stop() ||
>                                 atomic_cmpxchg(&group->rtpoll_wakeup, 1, 0));
>                  if (kthread_should_stop())
>                          break;
> 
>                  psi_rtpoll_work(group);
>          }
> 
> The old worker would check kthread_should_stop() and stop before it
> can consume rtpoll_wakeup. Do you agree?
> 

Could the following race still happen?

old worker                         teardown
-------------------------------------------------------
kthread_should_stop() == false
cmpxchg(wakeup, 1, 0) succeeds
                                   kthread_stop() sets SHOULD_STOP
kthread_should_stop() == true
exits without running the work

In this case, it seems the old worker could still consume the wakeup and
then observe the stop request before calling psi_rtpoll_work().

Therefore, reordering the conditions appears to narrow the race window,
but does not close it completely.

Thanks,
Guopeng

>>
>>                 psi_rtpoll_work(group);
>>         }
>> --
>> 2.43.0


  reply	other threads:[~2026-08-07  9:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-17  9:14 [PATCH 0/3] sched/psi: Fix rtpoll teardown races Guopeng Zhang
2026-07-17  9:14 ` [PATCH 1/3] sched/psi: Avoid losing wakeups during rtpoll worker replacement Guopeng Zhang
2026-07-27  4:03   ` Suren Baghdasaryan
2026-08-07  9:51     ` Guopeng Zhang [this message]
2026-07-17  9:14 ` [PATCH 2/3] sched/psi: Prevent stale timer rearm after rtpoll teardown Guopeng Zhang
2026-07-27  4:49   ` Suren Baghdasaryan
2026-08-07  9:52     ` Guopeng Zhang
2026-07-17  9:14 ` [PATCH 3/3] sched/psi: Avoid clobbering rtpoll_scheduled during teardown Guopeng Zhang
2026-07-27  5:53   ` Suren Baghdasaryan

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=65ca1d4e-b11b-4d4c-9562-ef3e0a12c6db@linux.dev \
    --to=guopeng.zhang@linux.dev \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=hannes@cmpxchg.org \
    --cc=juri.lelli@redhat.com \
    --cc=kprateek.nayak@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=surenb@google.com \
    --cc=tj@kernel.org \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.com \
    --cc=zhaoyang.huang@unisoc.com \
    --cc=zhouchengming@bytedance.com \
    --cc=ziwei.dai@unisoc.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.