All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: linux-kernel@vger.kernel.org, Julien Grall <julien.grall@arm.com>
Subject: Re: [PATCH] hrtimer: Add a missing bracket and hide `migration_base' on !SMP
Date: Wed, 4 Sep 2019 16:39:18 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.21.1909041633580.1902@nanos.tec.linutronix.de> (raw)
In-Reply-To: <20190904141540.xucehzbndjmgkrio@linutronix.de>

On Wed, 4 Sep 2019, Sebastian Andrzej Siewior wrote:

> Commit
>    68b2c8c1e4210 ("hrtimer: Don't take expiry_lock when timer is currently migrated")

That is the same information as in the fixes tag. So you can say something
like this:

The recent change to avoid taking the expiry lock when a timer is currently
migrated missed .....

> missed to add a bracket at the end of the if statement leading to
> compile errors.
> Since that commit the variable `migration_base' is always used but only
> available on SMP configuration thus leading to another compile error.
> The changelog says
>   "The timer base and base->cpu_base cannot be NULL in the code path"
> 
> so it is safe to limit this check to SMP configurations only.
> 
> Add the missing bracket to the if statement and hide `migration_base'
> behind CONFIG_SMP bars.
> 
> Fixes: 68b2c8c1e4210 ("hrtimer: Don't take expiry_lock when timer is currently migrated")
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
>  kernel/time/hrtimer.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
> index f5a1a5e16216c..bc84c74ae5b96 100644
> --- a/kernel/time/hrtimer.c
> +++ b/kernel/time/hrtimer.c
> @@ -1216,12 +1216,16 @@ void hrtimer_cancel_wait_running(const struct hrtimer *timer)
>  {
>  	/* Lockless read. Prevent the compiler from reloading it below */
>  	struct hrtimer_clock_base *base = READ_ONCE(timer->base);
> +	bool is_migration_base = false;
>  
>  	/*
>  	 * Just relax if the timer expires in hard interrupt context or if
>  	 * it is currently on the migration base.
>  	 */
> -	if (!timer->is_soft || base == &migration_base)
> +#ifdef CONFIG_SMP
> +	is_migration_base = base == &migration_base;
> +#endif

That's beyond ugly.

What's wrong with:

        if (!timer->is_soft || is_migration_base(base))

and have two helpers in the relevant ifdeffed section?

Thanks,

	tglx

  reply	other threads:[~2019-09-04 14:39 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-21  9:24 [RT PATCH 0/3] hrtimer: RT fixes for hrtimer_grab_expiry_lock() Julien Grall
2019-08-21  9:24 ` [RT PATCH 1/3] hrtimer: Use READ_ONCE to access timer->base in hrimer_grab_expiry_lock() Julien Grall
2019-08-21 13:44   ` Sebastian Andrzej Siewior
2019-08-21 13:50     ` Thomas Gleixner
2019-08-21 13:59       ` Sebastian Andrzej Siewior
2019-09-26 21:47       ` Eric Dumazet
2019-08-23  2:12   ` [tip: timers/core] hrtimer: Protect lockless access to timer->base tip-bot2 for Julien Grall
2019-08-21  9:24 ` [RT PATCH 2/3] hrtimer: Don't grab the expiry lock for non-soft hrtimer Julien Grall
2019-08-21 13:49   ` Sebastian Andrzej Siewior
2019-08-21  9:24 ` [RT PATCH 3/3] hrtimer: Prevent using uninitialized spin_lock in hrtimer_grab_expiry_lock() Julien Grall
2019-08-21 14:02   ` Thomas Gleixner
2019-08-22 10:59     ` Julien Grall
2019-08-23  2:12   ` [tip: timers/core] hrtimer: Don't take expiry_lock when timer is currently migrated tip-bot2 for Julien Grall
2019-09-04 14:15     ` [PATCH] hrtimer: Add a missing bracket and hide `migration_base' on !SMP Sebastian Andrzej Siewior
2019-09-04 14:39       ` Thomas Gleixner [this message]
2019-09-04 14:55         ` [PATCH v2] " Sebastian Andrzej Siewior

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.21.1909041633580.1902@nanos.tec.linutronix.de \
    --to=tglx@linutronix.de \
    --cc=bigeasy@linutronix.de \
    --cc=julien.grall@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.