[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



I wrote:
> Could we not do a smaller fix that would print something in the boot
> output, mabye ?  That would be a lower risk change.
> 
> 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...

On the question of backporting:

Jan Beulich:
> >Ian Jackson:
> >>>       Nevertheless it will then be a backporting candidate, so
> >>>       considering to take it right away can't simply be put off.
> > 
> > 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.

I didn't find this particularly convincing, TBH.

Despite the above exchanges, this patch is still marked 4.16? and the
release discussion inthe patch does not seem to have bene updated to
take into account this discussion.

In any case, I think at this stage of the freeze this patch is not a
good bet, particularly seeing as it has had to have another round.

Thanks,
Ian.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.