Re: [PATCH] alarmtimer: Expose information about next alarm to userspace via sysfs

[Pranav Prasad]

On Fri, Jan 19, 2024 at 11:38 AM Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
>
> On Thu, Jan 18 2024 at 14:11, John Stultz wrote:
> >   I'm always a bit cautious when exposing stuff to userland,
> > particularly if it's potentially racy as you mentioned in your
> > description. One thought I had was might adding a similar check
> > earlier in the suspend path on the kernel side provide similar benefit
> > (without requiring userland changes)?
> >
> > Basically, if I understand the problem:
> > echo mem > /sys/power/state
> > <kernel goes through suspending everything>
> > alarmtimer_suspend()
> >   if (next_alarm < TWO_SECONDS)
> >       return -EBUSY;
> > <kernel has to resume everything, and all that time was wasted>
> >
> > So if instead we did:
> > echo mem > /sys/power/state
> > enter_state()
> >    if (alarmtimer_immenent())
> >       retrun -EBUSY
> >
> > So the kernel would come back much faster if the suspend was going to abort.
> >
> > I suspect you all have considered this already but wanted to
> > understand what issues that approach has.
>
> It has the same race issues as the user space readout has as far as I
> understand and it's much simpler.
>
> Thanks,
>
>         tglx

Thanks John and Thomas for the suggestions!

The reason I did not go ahead with this approach previously was that I
wanted to contain the changes to the alarmtimer subsystem. I see the
benefit in eliminating the dependency on userspace reading from sysfs,
hence I shall work on v2 for this patch with an alternate solution
where I expose a function from alarmtimer to be used by the suspend
prepare flow in kernel/power.

Regards,
Pranav