Re: [PATCH v2] xen/arm: fix gnttab_need_iommu_mapping

From: Jan Beulich <jbeulich@suse.com>
To: Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>
Cc: lucmiccio@gmail.com, xen-devel@lists.xenproject.org,
	Bertrand.Marquis@arm.com, Volodymyr_Babchuk@epam.com,
	Rahul.Singh@arm.com,
	Stefano Stabellini <stefano.stabellini@xilinx.com>,
	Ian Jackson <iwj@xenproject.org>
Subject: Re: [PATCH v2] xen/arm: fix gnttab_need_iommu_mapping
Date: Tue, 9 Feb 2021 11:02:34 +0100	[thread overview]
Message-ID: <4df687cb-d3bc-ccb8-4e7c-a6429c37574e@suse.com> (raw)
In-Reply-To: <alpine.DEB.2.21.2102081214010.8948@sstabellini-ThinkPad-T480s>

On 08.02.2021 21:24, Stefano Stabellini wrote:
> On Mon, 8 Feb 2021, Julien Grall wrote:
>> On 08/02/2021 18:49, Stefano Stabellini wrote:
>>> Given the severity of the bug, I would like to request this patch to be
>>> backported to 4.12 too, even if 4.12 is security-fixes only since Oct
>>> 2020.
>>
>> I would agree that the bug is bad, but it is not clear to me why this would be
>> warrant for an exception for backporting. Can you outline what's the worse
>> that can happen?
>>
>> Correct me if I am wrong, if one can hit this error, then it should be pretty
>> reliable. Therefore, anyone wanted to use 4.12 in production should have seen
>> if the error on there setup by now (4.12 has been out for nearly two years).
>> If not, then they are most likely not affected.
>>
>> Any new users of Xen should use the latest stable rather than starting with an
>> old version.
> 
> Yes, the bug reproduces reliably but it takes more than a smoke test to
> find it. That's why it wasn't found by OSSTest and also our internal
> CI-loop at Xilinx.
> 
> Users can be very slow at upgrading, so I am worried that 4.12 might still
> be picked by somebody, especially given that it is still security
> supported for a while.
> 
> 
>> Other than the seriousness of the bug, I think there is also a fairness
>> concern.
>>
>> So far our rules says there is only security support backport allowed. If we
>> start granting exception, then we need a way to prevent abuse of it. To take
>> an extreme example, why one couldn't ask backport for 4.2?
>>
>> That said, I vaguely remember this topic was brought up a few time on
>> security@. So maybe it is time to have a new discussion about stable tree.
> 
> I wouldn't consider a backport for a tree that is closed even for
> security backports. So in your example, I'd say no to a backport to 4.2
> or 4.10.
> 
> I think there is a valid question for trees that are still open to
> security fixes but not general backports.
> 
> For these cases, I would just follow a simple rule of thumb:
> - is the submitter willing to provide the backport?
> - is the backport low-risk?
> - is the underlying bug important?
> 
> If the answer to all is "yes" then I'd go with it.

Personally I disagree, for the very simple reason of the question
going to become "Where do we draw the line?" The only non-security
backports that I consider acceptable are low-risk changes to allow
building with newer tool chains. I know other backports have
occurred in the past, and I did voice my disagreement with this
having happened.

But this is a community decision, so my opinion counts as just a
single vote.

Jan