From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752019AbdBBSy7 (ORCPT ); Thu, 2 Feb 2017 13:54:59 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:42593 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751443AbdBBSyy (ORCPT ); Thu, 2 Feb 2017 13:54:54 -0500 Date: Thu, 2 Feb 2017 19:54:48 +0100 (CET) From: Thomas Gleixner To: Dmitry Vyukov cc: Al Viro , "linux-fsdevel@vger.kernel.org" , LKML , syzkaller Subject: Re: [PATCH] timerfd: Protect the might cancel mechanism proper In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 1 Feb 2017, Dmitry Vyukov wrote: > > Can't we still end up with an inconsistently setup timer? > do_timerfd_settime executes timerfd_setup_cancel and timerfd_setup as > two separate non-atomic actions. So if there are 2 concurrent > timerfd_settime calls, one that needs cancel and another that does not > need cancel, can't we end up with inconsistent setup? E.g. setup timer > that needs cancel, but it won't be in cancel_list. Or vice versa. Do we really care? If an application arms the timer with cancel in one thread and the same timer without cancel in another thread, then it's probably completely irrelevant whether the state pair timeout/cancel is correct or not. That's clearly an application bug and I don't want to add more locking just to make something which is broken by definition pseudo 'atomic'. Thanks, tglx