Re: [patch 18/20] posix-timers: Clarify posix_timer_fn() comments

[Frederic Weisbecker]

Le Thu, Jun 01, 2023 at 09:07:37PM +0200, Thomas Gleixner a écrit :
> @@ -359,34 +360,35 @@ static enum hrtimer_restart posix_timer_
>  			 * FIXME: What we really want, is to stop this
>  			 * timer completely and restart it in case the
>  			 * SIG_IGN is removed. This is a non trivial
> -			 * change which involves sighand locking
> -			 * (sigh !), which we don't want to do late in
> -			 * the release cycle.
> +			 * change to the signal handling code.
> +			 *
> +			 * For now let timers with an interval less than a
> +			 * jiffie expire every jiffie and recheck for a
> +			 * valid signal handler.
> +			 *
> +			 * This avoids interrupt starvation in case of a
> +			 * very small interval, which would expire the
> +			 * timer immediately again.
>  			 *
> -			 * For now we just let timers with an interval
> -			 * less than a jiffie expire every jiffie to
> -			 * avoid softirq starvation in case of SIG_IGN
> -			 * and a very small interval, which would put
> -			 * the timer right back on the softirq pending
> -			 * list. By moving now ahead of time we trick
> -			 * hrtimer_forward() to expire the timer
> -			 * later, while we still maintain the overrun
> -			 * accuracy, but have some inconsistency in
> -			 * the timer_gettime() case. This is at least
> -			 * better than a starved softirq. A more
> -			 * complex fix which solves also another related
> -			 * inconsistency is already in the pipeline.
> +			 * Moving now ahead of time by one jiffie tricks
> +			 * hrtimer_forward() to expire the timer later,
> +			 * while it still maintains the overrun accuracy
> +			 * for the price of a slight inconsistency in the
> +			 * timer_gettime() case. This is at least better
> +			 * than a starved softirq.

Could be hardirq. How about:

"This is at least better than a timer storm."

Reviewed-by: Frederic Weisbecker <frederic@xxxxxxxxxx>