From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751609AbdKHKPv (ORCPT ); Wed, 8 Nov 2017 05:15:51 -0500 Received: from mx1.redhat.com ([209.132.183.28]:52594 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750818AbdKHKPn (ORCPT ); Wed, 8 Nov 2017 05:15:43 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 670A73A266 Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=dhowells@redhat.com Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells To: tglx@linutronix.de cc: dhowells@redhat.com, torvalds@linux-foundation.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Is there a race between __mod_timer() and del_timer()? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20749.1510136141.1@warthog.procyon.org.uk> Date: Wed, 08 Nov 2017 10:15:41 +0000 Message-ID: <20750.1510136141@warthog.procyon.org.uk> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Wed, 08 Nov 2017 10:15:43 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Is there a race between the optimisation for networking code in __mod_timer() and del_timer() - or, at least, a race that matters? Consider: CPU A CPU B =============================== =============================== [timer X is active] ==>__mod_timer(X) if (timer_pending(timer)) [Take the true path] -- IRQ -- ==>del_timer(X) <== if (timer->expires == expires) [Take the true path] <==return 1 [timer X is not active] There's no locking to prevent this, but __mod_timer() returns without restarting the timer. I'm not sure this is a problem exactly, however, since del_timer() *was* issued, and could've deleted the timer after __mod_timer() returned. A couple of possible alleviations: (1) Recheck timer_pending() before returning from __mod_timer(). (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. I think it might just be best to put a note in the comments in __mod_timer(). Thoughts? David