linux-kernel - Re: [PATCH 1/3] hrtimers: Force migrate away hrtimers queued after CPUHP_AP_HRTIMERS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z2YBFQ_WNm60HTx4@pavilion.home>
Date: Sat, 21 Dec 2024 00:43:17 +0100
From: Frederic Weisbecker <frederic@...nel.org>
To: Usama Arif <usamaarif642@...il.com>
Cc: Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>, vlad.wing@...il.com,
	rcu@...r.kernel.org, boqun.feng@...il.com, joel@...lfernandes.org,
	neeraj.upadhyay@....com, urezki@...il.com,
	qiang.zhang1211@...il.com, Cheng-Jui.Wang@...iatek.com,
	leitao@...ian.org, kernel-team@...a.com, paulmck@...nel.org,
	Anna-Maria Behnsen <anna-maria@...utronix.de>
Subject: Re: [PATCH 1/3] hrtimers: Force migrate away hrtimers queued after
 CPUHP_AP_HRTIMERS_DYING

Le Thu, Dec 19, 2024 at 10:00:12PM +0300, Usama Arif a écrit :
> > @@ -1240,6 +1280,12 @@ static int __hrtimer_start_range_ns(struct hrtimer *timer, ktime_t tim,
> >  
> >  	hrtimer_set_expires_range_ns(timer, tim, delta_ns);
> >  
> > +	if (unlikely(!this_cpu_base->online)) {
> > +		enqueue_hrtimer_offline(timer, base, mode);
> 
> Thanks for the fix!
> 
> It looks good to me, maybe as a follow up, we could rename switch_hrtimer_base to 
> enqueue_hrtimer_local? (or maybe something more appropriate)
> There are now 2 different paths that switch hrtimer base (enqueue_hrtimer_offline and
> switch_hrtimer_base).

I considered extending switch_hrtimer_base() instead to handle offline
CPU from there but that turned out ugly since what follows assumes to either
queue locally and possibly reprogram or queue remotely and not reprogram.

enqueue_hrtimer_global() does only enqueue remotely and possibly
trigger a reprogram.

And indeed we could move switch_hrtimer_base() + enqueue_hrtimer() +
hrtimer_force_reprogram() to a enqueue_hrtimer_online() for example.

Perhaps that would clarify things a bit, I don't know...

Thanks.

> 
> > +		return 0;
> > +	}
> > +
> > +
> nit: extra new line above.
> >  	/* Switch the timer base, if necessary: */
> >  	if (!force_local) {
> >  		new_base = switch_hrtimer_base(timer, base,
>