Re: [PATCH 0/3] timer_migration: Fix a possible race and improvements

[Anna-Maria Behnsen]

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