Re: [Xen-devel] [PATCH 0/3] x86: fixes/improvements for scratch cpumask

[Jan Beulich <jbeulich@xxxxxxxx>]

On 12.02.2020 22:05, Julien Grall wrote:
> On 12/02/2020 17:49, Roger Pau Monne wrote:
>> Commit:
>>
>> 5500d265a2a8fa63d60c08beb549de8ec82ff7a5
>> x86/smp: use APIC ALLBUT destination shorthand when possible
> 
> There is a more subtle problem introduced by this patch. I thought I 
> would mention it here just in case this affect the approach you have 
> chosen in this series.
> 
> get_cpu_maps() is used by stop_machine_run() to serialize the callers. 
> If the latter fails to acquire the lock, it will bail out. 
> Unfortunately, rcu_barrier() is implemented using stop_machine_run() and 
> will be turned to pretty much a NOP if the latter fails (e.g the lock 
> cannot be acquired).
> 
> This means that the rcu_barrier() will not do the expected job and 
> potentially introduce unknown issues (e.g use-after-free...).
> 
> Before your patch, it would have been pretty hard to hit the problem 
> above. After, you can race more easily with rcu_barrier() as sending IPI 
> is pretty common.
> 
> Sadly, I don't have a suggestion yet how to fix this problem.

A frequent use like on the IPI sending path suggests the lock may
want to become an r/w one, where both parties you mention want to
acquire it in read mode.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel