Michael!
On Thu, Feb 09 2023 at 12:19, Michael Nazzareno Trimarchi wrote:
> On Wed, Feb 8, 2023 at 7:06 PM Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
>> I wrote that patch against the back then mainline code. No idea if it's
>> still applying, but the underlying issue is still the same AFAICT.
>>
>> It needs some polishing and a proper changelog.
>>
> Ok, I will try to update it on some mainline kernel in my environment
> and test it back. I need
> a little information if it's possible. Consider that I have no
> experience in this area. I understand how
> code was designed in general but the part around the freezer and all
> those code you remove, what was the logic behind in the removed code?
What I can oracle out of that well commented gem is:
A userspace task invokes clock_nanosleep(CLOCK_*_ALARM, ...), which
arms an alarm timer. The expiry of an alarmtimer causes the system to
come out of suspend.
As the task invokes schedule() it can also be brought back from
schedule() via a signal. If that happens then the task cancels the
alarmtimer and returns to handle the signal. While doing that it can
be frozen, which means the alarm and therefore the wake from suspend
is lost.
To prevent that the code tries to save the earliest expiring alarm if
the task is marked freezing() and the suspend code takes that into
account.
John, did I summarize that correctly?
The change I made remove that magic and marks the task freezable when it
goes to schedule, which prevents the signal wakeup. That ensures that
the alarm stays armed during freeze/suspend.
That obviously needs some testing and scrunity by the folks which use
this mechanism. IIRC that's used by android, but I might be wrong.
Thanks,
tglx
