Bug 1662602

Under 4.19.13, I got

futex(0x408228, FUTEX_WAIT_PRIVATE, 0, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGRT_2 {si_signo=SIGRT_2, si_code=SI_TIMER, si_timerid=0x2, si_overrun=0, si_value={int=1514201408, ptr=0x7ffc5a40e140}} ---
clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {tv_sec=1, tv_nsec=805172721}) = 0
rt_sigreturn({mask=[]})                 = -1 EINTR (Interrupted system call)
futex(0x408228, FUTEX_WAIT_PRIVATE, 0, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGRT_3 {si_signo=SIGRT_3, si_code=SI_TIMER, si_timerid=0x3, si_overrun=0, si_value={int=163, ptr=0x33333333000000a3}} ---
clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {tv_sec=1, tv_nsec=905074445}) = 0
rt_sigreturn({mask=[]})                 = -1 EINTR (Interrupted system call)
futex(0x408228, FUTEX_WAIT_PRIVATE, 0, NULL

It never returns.

This is caused by

ommit 82c8dbb376b9fa9b831c157cbb15664cb4a343e3
Author: Thomas Gleixner <tglx>
Date:   Mon Dec 17 13:31:05 2018 +0100

    posix-timers: Fix division by zero bug
    
    commit 0e334db6bb4b1fd1e2d72c1f3d8f004313cd9f94 upstream.
    
    The signal delivery path of posix-timers can try to rearm the timer even if
    the interval is zero. That's handled for the common case (hrtimer) but not
    for alarm timers. In that case the forwarding function raises a division by
    zero exception.
    
    The handling for hrtimer based posix timers is wrong because it marks the
    timer as active despite the fact that it is stopped.
    
    Move the check from common_hrtimer_rearm() to posixtimer_rearm() to cure
    both issues.

Hi,

(In reply to H.J. Lu from comment #2)
> This is caused by
> 
> ommit 82c8dbb376b9fa9b831c157cbb15664cb4a343e3
> Author: Thomas Gleixner <tglx>
> Date:   Mon Dec 17 13:31:05 2018 +0100
> 
>     posix-timers: Fix division by zero bug


Thank you for tracking this down, it is probably best if you directly report this problem upstream, by sending a mail directly to Thomas with the relevant mailinglists in the Cc.

Regards,

Hans

(In reply to Hans de Goede from comment #3)
> Thank you for tracking this down, it is probably best if you directly report
> this problem upstream, by sending a mail directly to Thomas with the
> relevant mailinglists in the Cc.

https://lkml.org/lkml/2018/12/30/169

*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 29 kernel bugs.

Fedora 29 has now been rebased to 4.20.5-200.fc29.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.

Will be fixed in the next 4.19 kernel by:

Subject: Patch "posix-cpu-timers: Unbreak timer rearming" has been added to the 4.19-stable tree
To: 20190111133500.840117406, gregkh, hjl.tools, john.stultz, peterz, tglx
Cc: <stable-commits.org>
From: <gregkh>
Date: Mon, 28 Jan 2019 17:20:22 +0100
Message-ID: <1548692422159200>
MIME-Version: 1.0
Content-Type: text/plain; charset=ANSI_X3.4-1968
Content-Transfer-Encoding: 8bit
X-stable: commit
X-Patchwork-Hint: ignore


This is a note to let you know that I've just added the patch titled

    posix-cpu-timers: Unbreak timer rearming

to the 4.19-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     posix-cpu-timers-unbreak-timer-rearming.patch
and it can be found in the queue-4.19 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable.org> know about it.


From 93ad0fc088c5b4631f796c995bdd27a082ef33a6 Mon Sep 17 00:00:00 2001
From: Thomas Gleixner <tglx>
Date: Fri, 11 Jan 2019 14:33:16 +0100
Subject: posix-cpu-timers: Unbreak timer rearming

From: Thomas Gleixner <tglx>

commit 93ad0fc088c5b4631f796c995bdd27a082ef33a6 upstream.

The recent commit which prevented a division by 0 issue in the alarm timer
code broke posix CPU timers as an unwanted side effect.

The reason is that the common rearm code checks for timer->it_interval
being 0 now. What went unnoticed is that the posix cpu timer setup does not
initialize timer->it_interval as it stores the interval in CPU timer
specific storage. The reason for the separate storage is historical as the
posix CPU timers always had a 64bit nanoseconds representation internally
while timer->it_interval is type ktime_t which used to be a modified
timespec representation on 32bit machines.

Instead of reverting the offending commit and fixing the alarmtimer issue
in the alarmtimer code, store the interval in timer->it_interval at CPU
timer setup time so the common code check works. This also repairs the
existing inconistency of the posix CPU timer code which kept a single shot
timer armed despite of the interval being 0.

The separate storage can be removed in mainline, but that needs to be a
separate commit as the current one has to be backported to stable kernels.

Fixes: 0e334db6bb4b ("posix-timers: Fix division by zero bug")
Reported-by: H.J. Lu <hjl.tools>
Signed-off-by: Thomas Gleixner <tglx>
Cc: John Stultz <john.stultz>
Cc: Peter Zijlstra <peterz>
Cc: stable.org
Link: https://lkml.kernel.org/r/20190111133500.840117406@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh>

---
 kernel/time/posix-cpu-timers.c |    1 +
 1 file changed, 1 insertion(+)

--- a/kernel/time/posix-cpu-timers.c
+++ b/kernel/time/posix-cpu-timers.c
@@ -685,6 +685,7 @@ static int posix_cpu_timer_set(struct k_
 	 * set up the signal and overrun bookkeeping.
 	 */
 	timer->it.cpu.incr = timespec64_to_ns(&new->it_interval);
+	timer->it_interval = ns_to_ktime(timer->it.cpu.incr);
 
 	/*
 	 * This acts as a modification timestamp for the timer,


Patches currently in stable-queue which might be from tglx are

queue-4.19/x86-pkeys-properly-copy-pkey-state-at-fork.patch
queue-4.19/x86-selftests-pkeys-fork-to-check-for-state-being-preserved.patch
queue-4.19/x86-entry-64-compat-fix-stack-switching-for-xen-pv.patch
queue-4.19/net-sun-cassini-cleanup-license-conflict.patch
queue-4.19/kvm-nvmx-do-not-validate-that-posted_intr_desc_addr-is-page-aligned.patch
queue-4.19/x86-kaslr-fix-incorrect-i8254-outb-parameters.patch
queue-4.19/posix-cpu-timers-unbreak-timer-rearming.patch

This is also queued for 4.20.6

I can confirm that this is fixed in kernel-4.20.6-200.fc29.x86_64.

Thanks for letting us know