Linus,
Please pull the latest timers-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers-urgent-for-linus
# HEAD: 0e334db6bb4b1fd1e2d72c1f3d8f004313cd9f94 posix-timers: Fix division by zero bug
Fix a division by zero crash in the posix-timers code.
Thanks,
Ingo
------------------>
Thomas Gleixner (1):
posix-timers: Fix division by zero bug
kernel/time/posix-timers.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/kernel/time/posix-timers.c b/kernel/time/posix-timers.c
index bd62b5eeb5a0..31f49ae80f43 100644
--- a/kernel/time/posix-timers.c
+++ b/kernel/time/posix-timers.c
@@ -289,9 +289,6 @@ static void common_hrtimer_rearm(struct k_itimer *timr)
{
struct hrtimer *timer = &timr->it.real.timer;
- if (!timr->it_interval)
- return;
-
timr->it_overrun += hrtimer_forward(timer, timer->base->get_time(),
timr->it_interval);
hrtimer_restart(timer);
@@ -317,7 +314,7 @@ void posixtimer_rearm(struct kernel_siginfo *info)
if (!timr)
return;
- if (timr->it_requeue_pending == info->si_sys_private) {
+ if (timr->it_interval && timr->it_requeue_pending == info->si_sys_private) {
timr->kclock->timer_rearm(timr);
timr->it_active = 1;
The pull request you sent on Fri, 21 Dec 2018 13:34:53 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers-urgent-for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e572fa0e840154d33a69622af030dda551eee606
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
On Fri, Dec 21, 2018 at 01:34:53PM +0100, Ingo Molnar wrote:
> Linus,
>
> Please pull the latest timers-urgent-for-linus git tree from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers-urgent-for-linus
>
> # HEAD: 0e334db6bb4b1fd1e2d72c1f3d8f004313cd9f94 posix-timers: Fix division by zero bug
>
> Fix a division by zero crash in the posix-timers code.
>
> Thanks,
>
> Ingo
>
> ------------------>
> Thomas Gleixner (1):
> posix-timers: Fix division by zero bug
>
>
> kernel/time/posix-timers.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/kernel/time/posix-timers.c b/kernel/time/posix-timers.c
> index bd62b5eeb5a0..31f49ae80f43 100644
> --- a/kernel/time/posix-timers.c
> +++ b/kernel/time/posix-timers.c
> @@ -289,9 +289,6 @@ static void common_hrtimer_rearm(struct k_itimer *timr)
> {
> struct hrtimer *timer = &timr->it.real.timer;
>
> - if (!timr->it_interval)
> - return;
> -
> timr->it_overrun += hrtimer_forward(timer, timer->base->get_time(),
> timr->it_interval);
> hrtimer_restart(timer);
> @@ -317,7 +314,7 @@ void posixtimer_rearm(struct kernel_siginfo *info)
> if (!timr)
> return;
>
> - if (timr->it_requeue_pending == info->si_sys_private) {
> + if (timr->it_interval && timr->it_requeue_pending == info->si_sys_private) {
> timr->kclock->timer_rearm(timr);
FWIW, with this patch the vanilla glibc 2.28 self tests
rt/tst-cputimer1, rt/tst-cputimer2, and rt/tst-cputimer3
start to fail on s390:
rt/tst-cputimer1.out:
clock_gettime returned timespec = { 0, 117181 }
clock_getres returned timespec = { 0, 1 }
Timed out: killed the child process
rt/tst-cputimer1.test-result:
FAIL: rt/tst-cputimer1
original exit status 1
rt/tst-cputimer2.out:
clock_gettime returned timespec = { 0, 9686 }
clock_getres returned timespec = { 0, 1 }
Timed out: killed the child process
rt/tst-cputimer2.test-result:
FAIL: rt/tst-cputimer2
original exit status 1
rt/tst-cputimer3.out:
clock_gettime returned timespec = { 0, 0 }
clock_getres returned timespec = { 0, 1 }
Timed out: killed the child process
rt/tst-cputimer3.test-result:
FAIL: rt/tst-cputimer3
original exit status 1
I haven't looked any further into this, just reporting.. otherwise the
test systems seem to be healthy.
* Heiko Carstens <[email protected]> wrote:
> > - if (timr->it_requeue_pending == info->si_sys_private) {
> > + if (timr->it_interval && timr->it_requeue_pending == info->si_sys_private) {
> > timr->kclock->timer_rearm(timr);
>
> FWIW, with this patch the vanilla glibc 2.28 self tests
> rt/tst-cputimer1, rt/tst-cputimer2, and rt/tst-cputimer3
> start to fail on s390:
>
> rt/tst-cputimer1.out:
> clock_gettime returned timespec = { 0, 117181 }
> clock_getres returned timespec = { 0, 1 }
> Timed out: killed the child process
> rt/tst-cputimer1.test-result:
> FAIL: rt/tst-cputimer1
> original exit status 1
>
> rt/tst-cputimer2.out:
> clock_gettime returned timespec = { 0, 9686 }
> clock_getres returned timespec = { 0, 1 }
> Timed out: killed the child process
> rt/tst-cputimer2.test-result:
> FAIL: rt/tst-cputimer2
> original exit status 1
>
> rt/tst-cputimer3.out:
> clock_gettime returned timespec = { 0, 0 }
> clock_getres returned timespec = { 0, 1 }
> Timed out: killed the child process
> rt/tst-cputimer3.test-result:
> FAIL: rt/tst-cputimer3
> original exit status 1
>
> I haven't looked any further into this, just reporting.. otherwise the
> test systems seem to be healthy.
Could you please check whether the top commit in tip:timers/urgent fixes
it:
93ad0fc088c5: posix-cpu-timers: Unbreak timer rearming
?
It's in tip:master as well and should show up in linux-next tomorrow.
Thanks,
Ingo
On Thu, 17 Jan 2019, Heiko Carstens wrote:
> On Thu, Jan 17, 2019 at 10:51:02AM +0100, Ingo Molnar wrote:
> >
> > * Heiko Carstens <[email protected]> wrote:
> >
> > > > - if (timr->it_requeue_pending == info->si_sys_private) {
> > > > + if (timr->it_interval && timr->it_requeue_pending == info->si_sys_private) {
> > > > timr->kclock->timer_rearm(timr);
> > >
> > > FWIW, with this patch the vanilla glibc 2.28 self tests
> > > rt/tst-cputimer1, rt/tst-cputimer2, and rt/tst-cputimer3
> > > start to fail on s390:
> ...
> > > I haven't looked any further into this, just reporting.. otherwise the
> > > test systems seem to be healthy.
> >
> > Could you please check whether the top commit in tip:timers/urgent fixes
> > it:
> > 93ad0fc088c5: posix-cpu-timers: Unbreak timer rearming
>
> Yes, the test cases don't fail anymore. Thanks!
>
> A general question: since I reported this already last year, was the
> bug report not usable? I understand that x-mas holidays were in
> between, just wondering if new "glibc test case" fails are worth to be
> reported like I did.
I was on a 3 weeks vacation and I tend to clean out my inbox when I return
as it turned out in the past that playing catch up is hopeless. The
important stuff comes back by itself :)
Thanks,
tglx
On Thu, Jan 17, 2019 at 10:51:02AM +0100, Ingo Molnar wrote:
>
> * Heiko Carstens <[email protected]> wrote:
>
> > > - if (timr->it_requeue_pending == info->si_sys_private) {
> > > + if (timr->it_interval && timr->it_requeue_pending == info->si_sys_private) {
> > > timr->kclock->timer_rearm(timr);
> >
> > FWIW, with this patch the vanilla glibc 2.28 self tests
> > rt/tst-cputimer1, rt/tst-cputimer2, and rt/tst-cputimer3
> > start to fail on s390:
...
> > I haven't looked any further into this, just reporting.. otherwise the
> > test systems seem to be healthy.
>
> Could you please check whether the top commit in tip:timers/urgent fixes
> it:
> 93ad0fc088c5: posix-cpu-timers: Unbreak timer rearming
Yes, the test cases don't fail anymore. Thanks!
A general question: since I reported this already last year, was the
bug report not usable? I understand that x-mas holidays were in
between, just wondering if new "glibc test case" fails are worth to be
reported like I did.