lists.openwall.net   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  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Wed, 8 Nov 2017 08:26:51 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     David Howells <dhowells@...hat.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Network Development <netdev@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Is there a race between __mod_timer() and del_timer()?

On Wed, Nov 8, 2017 at 2:15 AM, David Howells <dhowells@...hat.com> wrote:
>
>  (2) Set timer->expires to jiffies in del_timer() - but since there's nothing
>      preventing the optimisation in __mod_timer() from occurring concurrently
>      with del_timer(), this probably won't help.

Right. The "race" is fundamental, and not in the timer code, but in the user.

If somebody does "del_timer()" at the same time somebody else modifies
the timer, it's not clear which one will win. The timer going away is
basically just "somebody modified it, but then immediately afterwards
another user deleted it".

So the modification was successful, but the end result is that the
timer is deleted, so it obviously isn't started.

I'm not even sure it merits a comment in the timer code, because the
timer code seems to do the right thing. The problem is in whoever
modifies and deletes a timer at the same time. It's fundamentally not
well-defined: either operation might happen "last", so you may end up
with a timer active or not, based purely on timing and luck.

              Linus

Powered by blists - more mailing lists