Return-path: Received: from aserp2130.oracle.com ([141.146.126.79]) by Galois.linutronix.de with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fJdqQ-0008Qb-Cn for speck@linutronix.de; Fri, 18 May 2018 13:46:47 +0200 Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w4IBemD2192538 for ; Fri, 18 May 2018 11:46:39 GMT Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2130.oracle.com with ESMTP id 2hxpvd3qap-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 18 May 2018 11:46:38 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w4IBkcSU026816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 18 May 2018 11:46:38 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w4IBkbIE007220 for ; Fri, 18 May 2018 11:46:37 GMT Date: Fri, 18 May 2018 07:46:36 -0400 From: Konrad Rzeszutek Wilk Subject: [MODERATED] Re: [PATCH v17.1 2/2] [PATCH v17.1 2/2] SSB Fix #2 Message-ID: <20180518114636.GV18423@char.us.oracle.com> References: <20180517031815.016936086@localhost.localdomain> <20180518082036.GA6330@kroah.com> MIME-Version: 1.0 In-Reply-To: <20180518082036.GA6330@kroah.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: > > 2.14.3 > > Why is this a part of this series? Shouldn't this just go into the tree > through the "normal" patch process if this really is an issue? And if > so, please cc: stable as the patch you are trying to "fix" here has been > backported already to stable kernel releases. It certainly can; I thought it made more sense to have it as part of this series as this series is the one that git bisection is going to finger. > > I really hate the "open coding" here though, it feels odd that the xen > developers feel that it is needed and they can't trust the fact that > since the kernel works fine today with this, it will continue to work ok > in the future (and if it breaks then, great, we can fix it...) The open coding was done b/c they expected push back from Thomas on doing the proper fix and instead ended with band-aid solution in their back-yard. > > thanks, > > greg k-h