linux-kernel - Re: [RFC][PATCH 2/2] time: alarmtimer: Use TASK

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

Message-ID: <CAOf5uw=a2RYYFj+4_WOX+KaF_FCXSsUgfM+T2m2XjVuqKMdooA@mail.gmail.com>
Date:   Mon, 20 Feb 2023 19:11:33 +0100
From:   Michael Nazzareno Trimarchi <michael@...rulasolutions.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     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
Subject: Re: [RFC][PATCH 2/2] time: alarmtimer: Use TASK_FREEZABLE to cleanup
 freezer handling

Hi Thomas

On Mon, Feb 20, 2023 at 6:48 PM Thomas Gleixner <tglx@...utronix.de> wrote:
>
> Michael!
>
> On Mon, Feb 20 2023 at 12:47, Michael Nazzareno Trimarchi wrote:
> > On Mon, Feb 20, 2023 at 9:23 AM Michael Nazzareno Trimarchi
> > <michael@...rulasolutions.com> wrote:
> >> On Mon, Feb 20, 2023 at 8:23 AM Thomas Gleixner <tglx@...utronix.de> wrote:
> >> > > Starting suspend loops
> >> > > [   89.674127] PM: suspend entry (deep)
> >> > > [   89.714916] Filesystems sync: 0.037 seconds
> >> > > [   89.733594] Freezing user space processes
> >> > > [   89.740680] Freezing user space processes completed (elapsed 0.002 seconds)
> >> > > [   89.748593] OOM killer disabled.
> >> > > [   89.752257] Freezing remaining freezable tasks
> >> > > [   89.756807] alarmtimer_fired: called
> >> > > [   89.756831] alarmtimer_dequeue: called <---- HERE
> >> > >
> >> > > I have the dequeue but not an enquee of the periodic alarm. I was
> >> > > thinking that create a periodic time of 4 seconds
> >> > > and have the first alarm on suspend will always guarantee the re-arm
> >> > > it but it's not working as I expect
> >> >
> >> > Again. You are not telling what you expect. It depends on how the timer
> >> > is set up whether the timer is self rearmed or not.
> >>
> >> Posted the pseudo code. As far as I understand, the timer periodic is
> >> re-armed in get_signal do_work_pending->do_signal()->get_signal(),
> >> then in the posix timer code the enqueue_alarm is called. All the
> >> timers used from suspend are coming from the expiration list that
> >> contains only the enqueue alarm.
>
> Let me try to decode the above.
>
> Yes, periodic timers are re-armed when the signal is delivered, but that
> happens way later after the system resumed.
>
> Here is what I observe:
>
> [   27.349352] alarmtimer_enqueue()
>
> U: Before SUSPEND
>
> [   31.353228] PM: suspend entry (s2idle)
> [   31.388857] Filesystems sync: 0.033 seconds
> [   31.418427] Freezing user space processes
> [   31.422406] Freezing user space processes completed (elapsed 0.002 seconds)
> [   31.425435] OOM killer disabled.
> [   31.426833] Freezing remaining freezable tasks
> [   31.429838] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
> [   31.432922] printk: Suspending console(s) (use no_console_suspend to debug)
> [   31.435912] alarmtimer alarmtimer.0.auto: PM: dpm_run_callback(): platform_pm_suspend+0x0/0x50 returns -16
> [   31.435954] alarmtimer alarmtimer.0.auto: PM: failed to suspend: error -16
>
> That means the RTC interrupt was raised before the system was able to suspend.

if (ktime_to_ns(min) < 2 * NSEC_PER_SEC) {
    pm_wakeup_event(dev, 2 * MSEC_PER_SEC);
    return -EBUSY;
}

I think that above happens to you. So it means that you are too close
to this limit, can be?
Yes but the alarm for me was set to be fired just before freezing. Is
this a valid scenario? I can retest on 6.2

Let's say that I set an alarm to be fired just before the userspace
freeze happens. If I'm close to
it then then process will not process the signal to enquene again the
alarm in the list and then during
alarm suspend the list will be empty for the above.

So your suggestion is that something is wrong with my environment so I
will do the same on top of 6.2

Michael

>
> [   31.436077] PM: Some devices failed to suspend, or early wake event detected
> [   31.444270] OOM killer enabled.
> [   31.445011] Restarting tasks ... done.
> [   31.446820] random: crng reseeded on system resumption
> [   31.466019] PM: suspend exit
>
> [   31.480283] alarmtimer_fired()
> [   31.481403] alarmtimer_dequeue()     <- Signal queued
>
> [   31.482596] alarmtimer_rearm()_      <- Signal delivery
> [   31.483713] alarmtimer_enqueue()
>
> U: ALRM signal received                 <- User space signal handler
> U: Post Suspend                         <- system("echo .... >") returns
>
> That's 6.2 + John's patches.
>
> Thanks,
>
>         tglx
>


-- 
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
michael@...rulasolutions.com
__________________________________

Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
info@...rulasolutions.com
www.amarulasolutions.com