linux-kernel - Re: [PATCH v10 18/20] timers: Implement the hierarchical pull model

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: <ZcJAflq1vLx3k-cl@localhost.localdomain>
Date: Tue, 6 Feb 2024 15:21:50 +0100
From: Frederic Weisbecker <frederic@...nel.org>
To: Anna-Maria Behnsen <anna-maria@...utronix.de>
Cc: linux-kernel@...r.kernel.org, Peter Zijlstra <peterz@...radead.org>,
	John Stultz <jstultz@...gle.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Eric Dumazet <edumazet@...gle.com>,
	"Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
	Arjan van de Ven <arjan@...radead.org>,
	"Paul E . McKenney" <paulmck@...nel.org>,
	Rik van Riel <riel@...riel.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Sebastian Siewior <bigeasy@...utronix.de>,
	Giovanni Gherdovich <ggherdovich@...e.cz>,
	Lukasz Luba <lukasz.luba@....com>,
	"Gautham R . Shenoy" <gautham.shenoy@....com>,
	Srinivas Pandruvada <srinivas.pandruvada@...el.com>,
	K Prateek Nayak <kprateek.nayak@....com>
Subject: Re: [PATCH v10 18/20] timers: Implement the hierarchical pull model

Le Tue, Feb 06, 2024 at 03:13:23PM +0100, Anna-Maria Behnsen a écrit :
> When remote is not set, and the group is not active (but it's not top
> level), walk_done will be set to true. Then goto check_toplevel. There
> walk_done and the groupstate migrator check is both true. But it is not
> top level... and the next goto unlock will also not happen and
> data->firstexp will be set. No?

Bah yes of course, walk_done doesn't mean we are in the top then, you're right.

> 
> >> 
> >> There is another issue in here. When the event could be ignored and it
> >> is propagated because of e.g. remote timer handling, then the timerqueue
> >> dance is done nevertheless. It's not a big problem (as the ignore flag
> >> is set and event is removed of queue when revisting the timer queue),
> >> but its obviously more work than it is required to have.
> >
> > Right. I guess it doesn't hurt to delete it from the timerqueue if present and
> > then update group->next_expiry accordingly. But it's certainly not useful
> > to requeue it :-)
> >
> 
> This would be the plan to keep the delete but drop the requeue in this
> case.
> 
> With those two things, the tmigr_update_events() wants to be changed a
> little more.

For the best!

Thanks.