From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 28679C19759 for ; Thu, 1 Aug 2019 07:34:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EC38A206A2 for ; Thu, 1 Aug 2019 07:34:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1564644892; bh=oCubh7Cb+deCvDcmZg9vFwBuc4+abNFtLvJvRi/oQQk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=0KO6GR4UTXV+LFDOQ+hIBBEpnTsORKuDukEwBSv9OIo2nRLiOL0dteeVYLiovQhpk QPbg8zFPNQVw/traZtUFc8v708aOmP8xMfYMYfsIAk2j+HgLzyUnMT3DhaPkDJiBML YhfKgc8smLGppVOWTWPFHfnEPy90dK6KUK2laHIQ= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729661AbfHAHev (ORCPT ); Thu, 1 Aug 2019 03:34:51 -0400 Received: from mail.kernel.org ([198.145.29.99]:46580 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725946AbfHAHev (ORCPT ); Thu, 1 Aug 2019 03:34:51 -0400 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 81130205F4; Thu, 1 Aug 2019 07:34:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1564644890; bh=oCubh7Cb+deCvDcmZg9vFwBuc4+abNFtLvJvRi/oQQk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=LJKpg5ujtimcG0q3vt17cCHRCeqkYqVdFX3WBgkPJB6ycDpNolRW8M587y2eQMS/u 7WeauE9TNOYUXm9X07zTqg66i5n93heatoZda8br62ExmWPlMEy5GmDgQtYgf4t+L2 oU6N9bnSmoy879K7pZhOWhwVnipiVE6nfN+Y8dLM= Date: Thu, 1 Aug 2019 08:34:45 +0100 From: Will Deacon To: Viresh Kumar Cc: Greg KH , Mark Rutland , Julien Thierry , Marc Zyngier , Catalin Marinas , Will Deacon , stable@vger.kernel.org, mark.brown@arm.com, julien.thierry.kdev@gmail.com, Russell King , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v4.4 V2 25/43] arm64: Move BP hardening to check_and_switch_context Message-ID: <20190801073444.4n45h6kcbmejvzte@willie-the-truck> References: <59b252cf-9cb7-128b-4887-c21a8b9b92a9@arm.com> <20190801050940.h65crfawrdifsrgg@vireshk-i7> <86354576-fc54-a8b7-4dc9-bc613d59fb17@arm.com> <20190801063544.ruw444isj5uojjdx@vireshk-i7> <20190801065700.GA17391@kroah.com> <20190801070541.hpmadulgp45txfem@vireshk-i7> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190801070541.hpmadulgp45txfem@vireshk-i7> User-Agent: NeoMutt/20170113 (1.7.2) Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Thu, Aug 01, 2019 at 12:35:41PM +0530, Viresh Kumar wrote: > On 01-08-19, 08:57, Greg KH wrote: > > On Thu, Aug 01, 2019 at 12:05:44PM +0530, Viresh Kumar wrote: > > > On 01-08-19, 07:30, Julien Thierry wrote: > > > > I must admit I am not familiar with backport/stable process enough. But > > > > personally I think the your suggestion seems more sensible than > > > > backporting 4 patches. > > > > > > > > Or you can maybe ignore patch 25 and say in patch 24 that among the > > > > changes made for the 4.4 codebase, the call arm64_apply_bp_hardening() > > > > was moved from post_ttbr_update_workaround as it doesn't exist and > > > > placed in check_and_switch_context() as it is its final destination. > > > > > > Done that and dropped the other two patches. > > > > > > > However, I really don't know what's the best way to proceed according to > > > > existing practices. So input from someone else would be welcome. > > > > > > Lets see if someone comes up and ask me to do something else :) > > > > Keeping the same patches that upstream has is almost always the better > > thing to do in the long-run. > > That would require two additional patches to be backported, 22 and 23 > from this series. From your suggestion it seems that keeping them is > better here ? Yes. Backporting individual patches as they appear upstream is definitely the preferred method for -stable. It makes the relationship to mainline crystal clear, as well as any dependencies between patches that have been backported. Everytime we tweak something unecessarily in a stable backport, it just creates the potential for confusion and additional conflicts in future backports, so it's best to follow the shape of upstream as closely as possible, even if it results in additional patches. So I wouldn't worry about total number of patches. I'd worry more about things like conflicts, deviation from mainline and overall testing coverage. Will