From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752779AbbFHKzt (ORCPT ); Mon, 8 Jun 2015 06:55:49 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:51118 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752716AbbFHKze (ORCPT ); Mon, 8 Jun 2015 06:55:34 -0400 Date: Mon, 8 Jun 2015 12:55:14 +0200 From: Peter Zijlstra To: Oleg Nesterov Cc: umgwanakikbuti@gmail.com, mingo@elte.hu, ktkhai@parallels.com, rostedt@goodmis.org, tglx@linutronix.de, juri.lelli@gmail.com, pang.xunlei@linaro.org, wanpeng.li@linux.intel.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 08/14] hrtimer: Allow hrtimer::function() to free the timer Message-ID: <20150608105514.GV18673@twins.programming.kicks-ass.net> References: <20150605084836.364306429@infradead.org> <20150605085205.723058588@infradead.org> <20150607223317.GA5193@redhat.com> <20150608091417.GM19282@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150608091417.GM19282@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 08, 2015 at 11:14:17AM +0200, Peter Zijlstra wrote: > On Mon, Jun 08, 2015 at 12:33:17AM +0200, Oleg Nesterov wrote: > > Not sure I read this patch correctly, it doesn't apply to Linus's tree. > > I was working on tip/master, there's a number of timer patches in there. > > > And I simply can not understand the complication in hrtimer_active(), > > please help! > > > > On 06/05, Peter Zijlstra wrote: > > > > > > +bool hrtimer_active(const struct hrtimer *timer) > > > +{ > > > + struct hrtimer_cpu_base *cpu_base; > > > + unsigned int seq; > > > + bool active; > > > + > > > + do { > > > + active = false; > > > + cpu_base = READ_ONCE(timer->base->cpu_base); > > > + seq = raw_read_seqcount(&cpu_base->seq); > > > + > > > + if (timer->state != HRTIMER_STATE_INACTIVE || > > > + cpu_base->running == timer) > > > + active = true; > > > > Why we can't simply return true in this case? > > > > Unless you lock this timer, hrtimer_active() is inherently racy anyway. > > Granted, it must not wrongly return False if the timer is pending or > > running. > > > > But "false positive" does not differ from the case when (say) the > > running timer->function() finishes right after hrtimer_active() returns > > True. OK I can't read; you asked why delay the return true inside that loop. Yes we can as per your argument. I think I ended up being too paranoid or something.