lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 15 Sep 2021 11:41:42 -0700
From:   Linus Torvalds <>
To:     Frederic Weisbecker <>
Cc:     "Alan J. Wylie" <>,
        Greg Kroah-Hartman <>,
        Linux Kernel Mailing List <>,
        stable <>
Subject: Re: Regression in posix-cpu-timers.c (was Re: Linux 5.14.4)

On Wed, Sep 15, 2021 at 11:31 AM Frederic Weisbecker
<> wrote:
> Right, this should fix the issue:


Can you explain why the fix isn't just to revert that original commit?

It looks like the only real difference is that now it does *extra
work* with all that tick_nohz_dep_set_signal().

Isn't it easier to just leave any old timer ticking, and not do the
extra work until it expires and you notice "ok, it's not important"?

IOW, that original commit explicitly broke the only case it changed -
the timer being disabled.  So why isn't it just reverted? What is it
that kleeps us wanting to do the extra work for the disabled timer

As long as it's fixed, I'm all ok with this, but I'm looking at the
commit message for that broken commit, and I'm looking at the commit
message for the fix, and I'm not seeing an actual _explanation_ for
this churn.


Powered by blists - more mailing lists