Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2382648imm; Thu, 16 Aug 2018 08:52:14 -0700 (PDT) X-Google-Smtp-Source: AA+uWPyff646zkIx8TI5n7vo7Nll+cSba9DV2jblaQwzoG3Vr9n5XkfJumfaImOTYu++ab/XlYnz X-Received: by 2002:a62:4898:: with SMTP id q24-v6mr32403900pfi.58.1534434733952; Thu, 16 Aug 2018 08:52:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534434733; cv=none; d=google.com; s=arc-20160816; b=IV9cNkTTKYC3p6v433i20qUxA2WUJXsK1eQGIoZiY6PBcDq1ct6isALp2q8NxRJRcv EfefltJ8SXjdszKlRae/nf8ypfabEfkx9shxX99b8BdfgEjS7m6jp56GWTN1NexpW3B1 4qqgn2o6PEF5R4XPdsusbkSHQXz2U7N6W+kdlr5I6RzWaLElm+azot7wTa1fE/dWiHD7 nGgq5SDdgsQlIj2j0687DIVskCM25R12NrXqQpouHrESHepc9OirSXv/1d6RuVYHTBG3 82nJg7yZogntj8OFwU0gvUi3T97f1jtt4jldcezPZmP/lKcLDbEeV4Z6ELevMTJPqmbQ FIbA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=EjeSJ4eY5mzdYOd83Ox+NyqGFzXhqOphmQReCMkAiGM=; b=s3pdPQ8BTL0WraVFML2KN3XFg42jM47NnG7sTEN1sBtAK8HePsmzZtsiHYA/7gLTAa szFuQbX2CjjdI9rzInB1+H3X15TUAdZe3FoGcpmsunS++SI+/66KX5TvDCAwx1fdr+uq o3Wl3nMrldptQNVD4Y1hhEaKM+s1GTYIZ4BMFcryAM5/VXFd39yntslD5/+4FiQbooqF d0ngW4Bsm1yYJsCgNACBB+GkqBhmVElsnHgJtZU21o0mtliqALn3GzyJS1KFGkm7K1OS RZKrt9wpihEzQpXb4xa9uwchJCtMCRwngC15ZzX3KWyszSbhQwcn/PtnODgKVmNJwm8y ZMFQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z16-v6si2487663pgi.252.2018.08.16.08.51.56; Thu, 16 Aug 2018 08:52:13 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389933AbeHPLRb (ORCPT + 99 others); Thu, 16 Aug 2018 07:17:31 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:34778 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388202AbeHPLRa (ORCPT ); Thu, 16 Aug 2018 07:17:30 -0400 Received: from localhost (unknown [194.244.16.108]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 914569D2; Thu, 16 Aug 2018 08:20:37 +0000 (UTC) Date: Thu, 16 Aug 2018 10:20:35 +0200 From: Greg Kroah-Hartman To: Dave Young Cc: Yannik Sembritzki , Linus Torvalds , David Howells , Thomas Gleixner , Ingo Molnar , Peter Anvin , the arch/x86 maintainers , Linux Kernel Mailing List , Baoquan He , Justin Forbes , Peter Jones , James Bottomley , Matthew Garrett , Vivek Goyal Subject: Re: [PATCH 2/2] [FIXED v2] Replace magic for trusting the secondary keyring with #define Message-ID: <20180816082035.GA4905@kroah.com> References: <20180815194244.29564-3-yannik@sembritzki.me> <201808160443.5h16PxVs%fengguang.wu@intel.com> <1bfa03ed-c9f8-d0f2-700c-c93e96d5b99c@sembritzki.me> <20180816011106.GC5915@dhcp-128-65.nay.redhat.com> <7834c175-7480-d5bd-d964-a4dd783af1f3@sembritzki.me> <20180816080259.GA6241@dhcp-128-65.nay.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180816080259.GA6241@dhcp-128-65.nay.redhat.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 16, 2018 at 04:02:59PM +0800, Dave Young wrote: > On 08/16/18 at 09:43am, Yannik Sembritzki wrote: > > On 16.08.2018 03:11, Dave Young wrote: > > > Instead of fix your 1st patch in 2nd patch, I would suggest to > > > switch the patch order. In 1st patch change the common code to use > > > the new macro and in 2nd patch you can directly fix the kexec code > > > with TRUST_SECONDARY_KEYRING. > > My reasoning for doing it in this order was that the first patch which > > fixes the bug itself should be merged into stable, while the refactoring > > doesn't necessarily have to. I'm not familiar with the linux development > > process, so please correct me if this should be done in another fashion. > > Frankly I'm not sure about the stable process. But personally I do not > like the order. > > Cced Greg for opinions about stable concern. It's up to what the maintainer of the subsystem wants to do here. I will take what they recommend. thanks, greg k-h