From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-187.mta1.migadu.com (out-187.mta1.migadu.com [95.215.58.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 067933F9F39 for ; Fri, 7 Aug 2026 09:51:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.187 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786096314; cv=none; b=lnoLJsjgajbTedrJfwtdVQh7BA0C7DnsU3PhybCz3anwmgRJc0oLLAuNLqW3noLTnIPsDC6+lacdFUS8Ch++BMHU6pYsyF9TKN/pvksKiogBh7ZUlWe876UT7q1mKZWyGLjwSR2YOEjycFabYeqkEcf7SQu07YFAwcYlg0tXQzk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786096314; c=relaxed/simple; bh=u1xHW7Q0gcjxR8qGeWlwfSEcXMNnXIXPiLh887We5lk=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=n8RiihkFN23kYJm4YULJE9I49WTy9IviRG1Vf9ybst6DaRkZXoBhONipZIAV+smcn2Skg/oe2eMPrS92JsfLYAMSh/2svrEQRmic4pSrVB/7foSJmpjvW5UKHJFgFOrma3spIpNOKZZi17dzoUAGLVidH77xzy42MhUB2QyBtc8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=EyMp9SLi; arc=none smtp.client-ip=95.215.58.187 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="EyMp9SLi" Message-ID: <65ca1d4e-b11b-4d4c-9562-ef3e0a12c6db@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1786096309; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mNOvIDWWKBYu/fhdxYLfhGMr2Ug8QWd7pBW9B8APkW0=; b=EyMp9SLiyMtgxJchgz2whb7ZuxDI9+X0qkevN4pRpvdhkmB3TkvTCA7FPXMJRs/bqb4RA6 U18tXBmz2q8wgLYzY4gWJID4edgI/Vxc776946BvyaQ+iukbx7Cw29MxfSBJeK7kjEP/pZ KvCJN99fFn275wcGgaxsAUBnHGuBQuE= Date: Fri, 7 Aug 2026 17:51:43 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH 1/3] sched/psi: Avoid losing wakeups during rtpoll worker replacement To: Suren Baghdasaryan Cc: Johannes Weiner , Peter Zijlstra , Ingo Molnar , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , K Prateek Nayak , Tejun Heo , Zhaoyang Huang , "ziwei.dai" , Chengming Zhou , linux-kernel@vger.kernel.org References: Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Guopeng Zhang In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT 在 2026/7/27 12:03, Suren Baghdasaryan 写道: > On Fri, Jul 17, 2026 at 2:14 AM Guopeng Zhang wrote: >> >> From: Guopeng Zhang >> >> 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 >> --- >> 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