From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753109AbbJTAzk (ORCPT ); Mon, 19 Oct 2015 20:55:40 -0400 Received: from mail-wi0-f175.google.com ([209.85.212.175]:37556 "EHLO mail-wi0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751589AbbJTAzi (ORCPT ); Mon, 19 Oct 2015 20:55:38 -0400 Date: Tue, 20 Oct 2015 02:55:36 +0200 From: Frederic Weisbecker To: Davidlohr Bueso Cc: Thomas Gleixner , LKML , George Spelvin , Peter Zijlstra , Oleg Nesterov , "Paul E . McKenney" , Jason Low , Ingo Molnar Subject: Re: [PATCH] posix-cpu-timers: Merge running and checking_timer state in one field Message-ID: <20151020005535.GB22807@lerouge> References: <1445300334-25977-1-git-send-email-fweisbec@gmail.com> <20151020004108.GB27292@linux-uzut.site> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151020004108.GB27292@linux-uzut.site> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 19, 2015 at 05:41:08PM -0700, Davidlohr Bueso wrote: > On Tue, 20 Oct 2015, Frederic Weisbecker wrote: > > >- * @checking_timer: true when a thread in the group is in the > >- * process of checking for thread group timers. > >- * > >+ * @state: flags describing the current state of the cputimer. > >+ * CPUTIMER_STATE_RUNNING bit means the timers is elapsing. > > s/timers/timer > > >+ * CPUTIMER_STATE_CHECKING bit means that the cputimer has > >+ * expired and a thread in the group is checking the > >+ * callback list. > > These comments might be better served when defining CPUTIMER_STATE_* If it was defined as an emum I'd agree but here state is defined as an int (whose size is more readable in a struct than enum) and it's not obvious what kind of values it can take if we don't define them here. > > [...] > > >@@ -606,7 +606,7 @@ bool posix_cpu_timers_can_stop_tick(struct task_struct *tsk) > > return false; > > > > /* Check if cputimer is running. This is accessed without locking. */ > >- if (READ_ONCE(tsk->signal->cputimer.running)) > >+ if (READ_ONCE(tsk->signal->cputimer.state)) > > return false; > > Could we have cases, such as the above, where .state is set to CPUTIMER_STATE_CHECKING > and therefore the check is not equivalent? Nope we shouldn't. I added a WARN_ONCE somewhere to perform some related sanity checks. I could add more if needed. Thanks. > Thanks, > Davidlohr