Re: [PATCH v2 1/6][4.16?] x86/x2APIC: defer probe until after IOMMU ACPI table parsing

[Jan Beulich <jbeulich@xxxxxxxx>]

On 08.11.2021 16:04, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH v2 1/6][4.16?] x86/x2APIC: defer probe until 
> after IOMMU ACPI table parsing"):
>> On 05.11.2021 16:47, Ian Jackson wrote:
>>> This part confused me.  Under what circumstances would we backport
>>> this ?  AIUI it would be backporting a potentially-fragile and
>>> not-readily-testable bugfix, for a theoretical scenario with a
>>> straightforward workaround.
>>
>> Well, I've said "candidate" for this very reason: To me, every bug
>> fix is a candidate. Whether risks outweigh the potential benefits is
>> then influencing whether to _actually_ take the change. A reason to
>> take it despite the available workaround might be that
>> "straightforward" doesn't also mean "obvious" here. IOW once you
>> know what to do, doing so is easy. But one first needs to arrive
>> there.
> 
> Could we not do a smaller fix that would print something in the boot
> output, mabye ?  That would be a lower risk change.

Hmm, maybe something could be done, but at the risk of getting the
conditions there wrong (and hence having false positives and/or
false negatives, confusing users at best) and with likely a clumsy
log message ("abc ran before xyz"), suggesting that we actually
know how to do better. IOW - I'd rather not go this route, and it
would feel better to me to simply defer this change to post-4.16
if we deem it too risky to put it in now.

> So far, I think the tradeoff here isn't looking very good: a risk of
> unclear magnitude for many users, vs a hard crash at boot for a set of
> users we believe to be empty.
> 
> As ever, feel free to contradict me if I have the wrong end of one of
> the many sticks here...

I think you've got it quite right. I did put the question mark in the
tag specifically to make clear that while I'd like this to be
considered, I'm myself not convinced the risks outweigh the benefits.

Jan