From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753131AbdBJLed (ORCPT ); Fri, 10 Feb 2017 06:34:33 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:60033 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752472AbdBJLeb (ORCPT ); Fri, 10 Feb 2017 06:34:31 -0500 Date: Fri, 10 Feb 2017 11:51:31 +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 Fri, 10 Feb 2017, Dmitry Vyukov wrote: > On Fri, Feb 10, 2017 at 11:13 AM, Thomas Gleixner wrote: > > ctx->might_cancel and ctx->clist are always in sync with the new lock and > > that's the only interesting thing. On destruction we don't look at clockid > > or such, we only care about might_cancel. > > > > What is not guaranteed to be in sync is the timer expiry time and the > > cancel stuff, if two threads operate on the same timerfd in > > parallel. That's what I do not care about at all. > > Ack. Thanks for looking at it bearing with me. Then: Thanks for asking the questions. It's always good if we need to think it over again. Thanks, tglx