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

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

  • To: Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • From: George Dunlap <George.Dunlap@xxxxxxxxxx>
  • Date: Wed, 10 Feb 2021 11:04:37 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=S4VMAbTurNdKPv2oUY6KDHCWiyvUpxAAlhweQL8RLkI=; b=Iko1sqIUDuokEXmEi56MFnSoOVtn0q0+ynY3WPccvqmA2EiUnAhhRBCbjos8IZfrgdvM3Iu6n65wS0p2WdzJcnL3Hp/2FVjvCs7Du3+DIxULo/Rw0jcJ8bsHvd+3lG9d16goZw3HQ0HTD4/7yfACbmsvXeXaRU8Vabd6lbsFFlYw2Tckhx0gvr/Gg+DhJGcEbFMqghiz2HVEU4LMl1Wx9o1yqypxZKnkqHw3r0QdzaET4ZhZ3L4GIfUVPwJE0uBY8pm07N6I5zyINkD6/PnD9GY7hh3M0R581OhNONb52WSkDMtUJUZxMvALd6V9T0xWbdbIs0i0likAp2UIDftV8w==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IYVaTtKSBgfHIdmh1ZrIO4t6EQGfWOfVKdufECDCgMu6YBffrsIvvzFDJmmFUBmVxpFK6Q4MAPRdtufWkjm7I83s4lOET0LWxdcwu67fK2WTwwBLzCz8ClWrRJO1TWTS4QqjJ67DK/Z2ka4vDf/7ueeVleu0ITS8UF/jnHZsimx8slCVDOrHWFEPTOD7socWDDBQPREyZ8qSB91zeHjvxXc/VDA0YWhaznFMjLH4+0nmpawGSHl+dNe2Qww8R4QKY7EcWvEdGmv81usJKtsKDzftQ9sxbfHrBECVYTMmrz0TJDfraT8G2LnuYFqwQ42Aexjiw3AwBi7gR96DbcjUAA==
  • Authentication-results: esa4.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Ian Jackson <iwj@xxxxxxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, "Julien Grall" <julien@xxxxxxx>, "lucmiccio@xxxxxxxxx" <lucmiccio@xxxxxxxxx>, "open list:X86" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, "Volodymyr_Babchuk@xxxxxxxx" <Volodymyr_Babchuk@xxxxxxxx>, "Rahul.Singh@xxxxxxx" <Rahul.Singh@xxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxx>
  • Delivery-date: Wed, 10 Feb 2021 11:05:09 +0000
  • Ironport-sdr: AMRtoFChYKtnOihXL2f67m3GKBjVdoebzNDwlXElaFp/sq1c+kKqV7wHUwgNG580B5H4GNHb6G clJ3GYSwx6mDyJEc0pebWZFU8eSDDSVYEDKJr4yqwXpkxzfFhfAIW8nAM4fHxK19keWb5oLYDm WaPgyPlyDSJJfPp+YO8oHr9WqRHjy8iR0bciMs59uEQXF7STisgiJkq04rRvujL/TuPCTED31m cAutjGgBq5+KYhWHjWUPFVrwyQ69DDQdqdKKA+trk6xDkbKUhrwe6L23l46GlyAjrrW7hLvzy1 tkE=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHW/wlm+vwmTie2HEebCGdpHuZ0HapROvYA
  • Thread-topic: [PATCH v2] xen/arm: fix gnttab_need_iommu_mapping

> On Feb 9, 2021, at 5:31 PM, Stefano Stabellini <sstabellini@xxxxxxxxxx> wrote:
> On Tue, 9 Feb 2021, Ian Jackson wrote:
>> Jan Beulich writes ("Re: [PATCH v2] xen/arm: fix gnttab_need_iommu_mapping"):
>>> On 08.02.2021 21:24, Stefano Stabellini wrote:
>> ...
>>>> 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.
>> I think I take a more relaxed view than Jan, but still a much more
>> firm line than Stefano.  My opinion is that we should make exceptions
>> for only bugs of exceptional severity.
>> I don't think I have seen an argument that this bug is exceptionally
>> severe.
>> For me the fact that you can only experience this bug if you upgrade
>> the hardware or significantly change the configuration, means that
>> this isn't so serious a bug.
> Yeah, I think that's really the core of this issue. If somebody is
> already using 4.12 happily, there is really no reason for them to take
> the fix. If somebody is about to use 4.12, then it is a severe issue.
> The view of the group is that nobody should be switching to 4.12 now
> because there are newer releases out there. I don't know if that is
> true.

I don’t think we have to tell people what to do; rather, we need to tell people 
what *we* are going to do.  We’ve told people that we’ll provide normal 
bug-fixes until 2020-10-02, and security bugfixes until 2022-04-02. Anyone is 
welcome to use 4.12 whenever they want to; but if they do, they take the risk 
that there will be a “normal” bug that doesn’t get fixed by upstream.  The 
patch is available, anyone who wants to can apply it themselves (at their own 
risk, of course).

We don’t seem to have anything explicitly written down anywhere, but whenever 
someone has come to us using some obsolete version of Xen, we’ve recommended 
they use the most recent stable release.

The one reason someone might use 4.12 over a newer version is if that’s still 
the one packaged by their distro.  In that case, the distro should either 
update to a newer version, or take on the effort of supporting the old version 
by backporting bugfixes.  If such a distro chooses not to do so, then a user 
should consider switching to a different distro.

The purpose of having such a policy is to avoid needing to have this discussion 
about every single patch that comes up; and the number was chosen to balance 
effort for testing and maintainers against value to downstreams.  Certainly 
backposting Just This One patch won’t be a huge amount of work; but I 
completely sympathize with Jan’s point of view that if we start to make 
exceptions, people will begin to expect them.  We’ve said what we’re going to 
do, we should just stick with it.

Now maybe the 18-month “full-support" window is too small.  We seem to have 
lots of downstreams (at least SuSE and XenServer) who support much older 
versions; coordinating on versions to designate LTS releases to avoid 
duplication of effort and share the benefits of that effort with the wider 
community might be something worth considering.  But that’s a completely 
different discussion.




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