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
| ||
|
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