Re: preparations for 4.13.1 and 4.12.3

[Igor Druzhinin <igor.druzhinin@xxxxxxxxxx>]

On 14/04/2020 14:36, Jan Beulich wrote:
> On 14.04.2020 15:07, Andrew Cooper wrote:
>> On 09/04/2020 08:41, Jan Beulich wrote:
>>> All,
>>>
>>> the releases are due in a week or two. Please point out backports
>>> you find missing from the respective staging branches, but which
>>> you consider relevant. (Ian, I notice there haven't been any
>>> tools side backports at all so far. Julien, Stefano - same for
>>> Arm.)
>>
>> 540d4d60378c "cpu: sync any remaining RCU callbacks before CPU up/down"
>> which fixes crashes after vcpu hotplug in shim.
>>
>> It looks to depend on 53ddfc80a84a, a9b6dacf88fe, c301211a5111 and
>> 53594c7bd197 which are other RCU bugfixes.
> 
> And cef21210fb133 as well as a6fe79a5979a then. Iirc we had even
> talked about this on irc, and were largely in agreement that this
> is a little beyond what we'd normally backport.

Correct. Those 2 could be taken for completeness but not strictly necessary.
On the other hand, those mentioned by Andrew (maybe except for a9b6dacf88fe)
are necessary prerequisites.

> I have to admit that while I followed Igor's advice that there is
> a dependency of his patch on Jürgen's work, I'm still not really
> clear where that dependency actually lies. The patch merely moves
> where rcu_barrier() gets invoked from (thus covering previously
> uncovered places). If there hadn't been that named dependency, I
> would have taken Igor's patch already.

There is dependency in the fact after my patch is applied - rcu_barrier gets
invoked very frequently unlike before. This uncovers many issues in its
implementation that are addressed by RCU series. Without RCU series
rcu_barrier call is unstable and causes race condition induced crashes and
is incompatible with core-scheduling.

Igor