[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87wn3ykbfa.ffs@tglx>
Date: Thu, 02 Mar 2023 23:58:49 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: Michael Nazzareno Trimarchi <michael@...rulasolutions.com>,
John Stultz <jstultz@...gle.com>,
LKML <linux-kernel@...r.kernel.org>,
Stephen Boyd <sboyd@...nel.org>, Arnd Bergmann <arnd@...db.de>,
Michael <michael@...isi.de>, kernel-team@...roid.com,
Peter Zijlstra <peterz@...radead.org>,
"Rafael J. Wysocki" <rafael@...nel.org>
Subject: Re: [RFC][PATCH 2/2] time: alarmtimer: Use TASK_FREEZABLE to
cleanup freezer handling
On Thu, Mar 02 2023 at 23:21, Thomas Gleixner wrote:
> On Thu, Mar 02 2023 at 15:32, Rafael J. Wysocki wrote:
>> On Mon, Feb 20, 2023 at 10:19 PM Thomas Gleixner <tglx@...utronix.de> wrote:
>>> +static atomic_t alarmtimer_wakeup;
>>>
>>> /**
>>> * alarmtimer_fired - Handles alarm hrtimer being fired.
>>> @@ -194,6 +196,8 @@ static enum hrtimer_restart alarmtimer_f
>>> int ret = HRTIMER_NORESTART;
>>> int restart = ALARMTIMER_NORESTART;
>>>
>>> + atomic_inc(&alarmtimer_wakeup);
>>> +
>>
>> This appears to be still somewhat racy, because the notifier can run
>> at this point AFAICS.
>
> Indeed it is. Let me think more about this.
All of this is inherently racy as there is zero feedback whether the
event has been consumed or not. Making this feedback based is not
necessarily trivial, but let me stare into that.
Thanks,
tglx
Powered by blists - more mailing lists