All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <frederic@kernel.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Anna-Maria Behnsen <anna-maria@linutronix.de>,
	John Stultz <jstultz@google.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>, Stephen Boyd <sboyd@kernel.org>,
	Eric Biederman <ebiederm@xmission.com>,
	Oleg Nesterov <oleg@redhat.com>
Subject: Re: [patch v6 02/20] posix-timers: Make signal overrun accounting sensible
Date: Fri, 1 Nov 2024 13:51:58 +0100	[thread overview]
Message-ID: <ZyTO7mFZWRZf7sNv@localhost.localdomain> (raw)
In-Reply-To: <20241031154424.677253735@linutronix.de>

Le Thu, Oct 31, 2024 at 04:46:25PM +0100, Thomas Gleixner a écrit :
> The handling of the timer overrun in the signal code is inconsistent as it
> takes previous overruns into account. This is just wrong as after the
> reprogramming of a timer the overrun count starts over from a clean state,
> i.e. 0.
> 
> Don't touch info::si_overrun in send_sigqueue() and only store the overrun
> value at signal delivery time, which is computed from the timer itself
> relative to the expiry time.
> 
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---
> V6: Fold the timer_overrun_to_int() cleanup from Frederic and remove all
>     overrun fiddling from the signal path.
> ---
>  kernel/signal.c            |    6 ------
>  kernel/time/posix-timers.c |   11 ++++++-----
>  2 files changed, 6 insertions(+), 11 deletions(-)
> ---
> 
> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -1968,15 +1968,9 @@ int send_sigqueue(struct sigqueue *q, st
>  
>  	ret = 0;
>  	if (unlikely(!list_empty(&q->list))) {
> -		/*
> -		 * If an SI_TIMER entry is already queue just increment
> -		 * the overrun count.
> -		 */
> -		q->info.si_overrun++;
>  		result = TRACE_SIGNAL_ALREADY_PENDING;
>  		goto out;
>  	}
> -	q->info.si_overrun = 0;

So it's not cleared anymore on signal queue?

Not sure if it's a big problem but if an interval timer gets a signal with
overruns and then the timer is reset later as non interval, the resulting
upcoming signals will still carry the previous non-zero overruns?

However it's better to keep the overrun update on a single place so
perhaps this?

diff --git a/kernel/time/posix-timers.c b/kernel/time/posix-timers.c
index 66ed49efc02f..f06c52731d65 100644
--- a/kernel/time/posix-timers.c
+++ b/kernel/time/posix-timers.c
@@ -282,6 +282,8 @@ bool posixtimer_deliver_signal(struct kernel_siginfo *info)
 		++timr->it_signal_seq;
 
 		info->si_overrun = timer_overrun_to_int(timr);
+	} else {
+		info->si_overrun = 0;
 	}
 	ret = true;
 
Other than that:

Reviewed-by: Frederic Weisbecker <frederic@kernel.org>

  reply	other threads:[~2024-11-01 12:52 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-31 15:46 [patch v6 00/20] posix-timers: Cure the SIG_IGN mess Thomas Gleixner
2024-10-31 15:46 ` [patch v6 01/20] posix-timers: Make signal delivery consistent Thomas Gleixner
2024-11-01 12:26   ` Frederic Weisbecker
2024-10-31 15:46 ` [patch v6 02/20] posix-timers: Make signal overrun accounting sensible Thomas Gleixner
2024-11-01 12:51   ` Frederic Weisbecker [this message]
2024-11-01 20:36     ` Thomas Gleixner
2024-11-02 19:41       ` Thomas Gleixner
2024-11-02 22:57         ` Frederic Weisbecker
2024-10-31 15:46 ` [patch v6 03/20] posix-cpu-timers: Cleanup the firing logic Thomas Gleixner
2024-11-01 13:14   ` Frederic Weisbecker
2024-10-31 15:46 ` [patch v6 04/20] posix-cpu-timers: Use dedicated flag for CPU timer nanosleep Thomas Gleixner
2024-10-31 15:46 ` [patch v6 05/20] posix-timers: Add a refcount to struct k_itimer Thomas Gleixner
2024-10-31 15:46 ` [patch v6 06/20] signal: Split up __sigqueue_alloc() Thomas Gleixner
2024-10-31 15:46 ` [patch v6 07/20] signal: Provide posixtimer_sigqueue_init() Thomas Gleixner
2024-10-31 15:46 ` [patch v6 08/20] posix-timers: Store PID type in the timer Thomas Gleixner
2024-10-31 15:46 ` [patch v6 09/20] signal: Refactor send_sigqueue() Thomas Gleixner
2024-10-31 15:46 ` [patch v6 10/20] signal: Replace resched_timer logic Thomas Gleixner
2024-11-01 13:25   ` Frederic Weisbecker
2024-10-31 15:46 ` [patch v6 11/20] posix-timers: Embed sigqueue in struct k_itimer Thomas Gleixner
2024-10-31 15:46 ` [patch v6 12/20] signal: Cleanup unused posix-timer leftovers Thomas Gleixner
2024-10-31 15:46 ` [patch v6 13/20] posix-timers: Move sequence logic into struct k_itimer Thomas Gleixner
2024-10-31 15:46 ` [patch v6 14/20] signal: Provide ignored_posix_timers list Thomas Gleixner
2024-10-31 15:46 ` [patch v6 15/20] posix-timers: Handle ignored list on delete and exit Thomas Gleixner
2024-11-01 13:47   ` Frederic Weisbecker
2024-11-01 20:38     ` Thomas Gleixner
2024-10-31 15:46 ` [patch v6 16/20] signal: Handle ignored signals in do_sigaction(action != SIG_IGN) Thomas Gleixner
2024-11-01 14:04   ` Frederic Weisbecker
2024-10-31 15:46 ` [patch v6 17/20] signal: Queue ignored posixtimers on ignore list Thomas Gleixner
2024-11-01 14:21   ` Frederic Weisbecker
2024-11-01 20:47     ` Thomas Gleixner
2024-11-02 14:49       ` Thomas Gleixner
2024-11-02 20:57         ` Thomas Gleixner
2024-11-02 23:46       ` Frederic Weisbecker
2024-11-03  9:44         ` Thomas Gleixner
2024-11-03 19:55           ` Frederic Weisbecker
2024-11-02 21:05   ` [patch v6.1 " Thomas Gleixner
2024-11-04 11:42     ` Frederic Weisbecker
2024-11-04 15:21       ` Thomas Gleixner
2024-11-04 21:31         ` Thomas Gleixner
2024-11-04 23:02           ` Frederic Weisbecker
2024-10-31 15:46 ` [patch v6 18/20] posix-timers: Cleanup SIG_IGN workaround leftovers Thomas Gleixner
2024-10-31 15:46 ` [patch v6 19/20] alarmtimers: Remove the throttle mechanism from alarm_forward_now() Thomas Gleixner
2024-10-31 15:46 ` [patch v6 20/20] alarmtimers: Remove return value from alarm functions Thomas Gleixner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZyTO7mFZWRZf7sNv@localhost.localdomain \
    --to=frederic@kernel.org \
    --cc=anna-maria@linutronix.de \
    --cc=ebiederm@xmission.com \
    --cc=jstultz@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=sboyd@kernel.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.