[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <871q4mflbl.fsf@somnus>
Date: Mon, 24 Jun 2024 16:48:46 +0200
From: Anna-Maria Behnsen <anna-maria@...utronix.de>
To: Frederic Weisbecker <frederic@...nel.org>
Cc: Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org,
Borislav Petkov <bp@...en8.de>, Narasimhan V <Narasimhan.V@....com>
Subject: Re: [PATCH 0/3] timer_migration: Fix a possible race and improvements
Frederic Weisbecker <frederic@...nel.org> writes:
> On Mon, Jun 24, 2024 at 10:58:26AM +0200, Anna-Maria Behnsen wrote:
>> Frederic Weisbecker <frederic@...nel.org> writes:
>> +static void tmigr_setup_active_up(struct tmigr_group *group, struct tmigr_group *child)
>> +{
>> + union tmigr_state curstate, childstate;
>> + bool walk_done;
>> +
>> + /*
>> + * FIXME: Memory barrier is required here as the child state
>> + * could have changed in the meantime
>> + */
>> + curstate.state = atomic_read_acquire(&group->migr_state);
>> +
>> + for (;;) {
>> + childstate.state = atomic_read(&child->migr_state);
>> + if (!childstate.active)
>> + return;
>
> Ok there could have been a risk that we miss the remote CPU going active. But
> again thanks to the lock this makes sure that either we observe the childstate
> as active or the remote CPU sees the link and propagates its active state. And
> the unlocked optimization tmigr_update_events() still works because either it
> sees the new parent and proceeds or it sees an intermediate parent and the next
> ones will be locked.
>
> Phew!
>
> I'll do a deeper review this evening but it _looks_ ok.
>
I will send you a v2 of the whole timer_migration series where the fix
is also splitted. And review should then be a little easier.
Thanks,
Anna-Maria
Powered by blists - more mailing lists