Stefan Sperling <s...@stsp.name> wrote:
> On Fri, Aug 01, 2025 at 01:09:07AM -0600, Theo de Raadt wrote:
> > There are two issues being solved. One is blocking kernel behaviors
> > during the time when the kernel is fully in control. The second issue
> > is ignoring the user's requests. If the timer is simply extended
> > once the kernel-resume parts have finished, we get a nice 10 second
> > block on user interaction on all machines.
>
> I see. It becomes a much simpler diff:
>
> M sys/kern/subr_suspend.c | 2+ 1-
>
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> commit - 3b565b6513502b4d00eb2ea3c0e8d1aa648f5db2
> commit + 10825f0f1315cbb61913a0003512928e8419ae8a
> blob - 3c83a049cb97e4b3026fd9c3b75d3b1eff2d3caa
> blob + 08dd1e46c3fab68bdb8759bc6704af153d45ccf0
> --- sys/kern/subr_suspend.c
> +++ sys/kern/subr_suspend.c
> @@ -218,11 +218,12 @@ fail_hiballoc:
> cpu_setperf(perflevel); /* Restore hw.setperf */
> if (suspend_finish(v) == EAGAIN)
> goto top;
> + resume_time = getuptime();
> return (error);
> }
>
> int
> resuming(void)
> {
> - return (getuptime() < resume_time + 15);
> + return (getuptime() < resume_time + 10);
> }
That is what I thinking. I guess it works for you. I don't think this
can hurt any other machine.
