Re: [PATCH 0/3] timer_migration: Fix a possible race and improvements
From: Anna-Maria Behnsen
Date: Mon Jun 24 2024 - 10:55:56 EST
Frederic Weisbecker <frederic@xxxxxxxxxx> writes:
> On Mon, Jun 24, 2024 at 10:58:26AM +0200, Anna-Maria Behnsen wrote:
>> Frederic Weisbecker <frederic@xxxxxxxxxx> 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