Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp3624099imj; Tue, 12 Feb 2019 01:47:53 -0800 (PST) X-Google-Smtp-Source: AHgI3IabkM2DDItLkhht2ORGh132Y/qkDkvP6Mh1vL+fWcfpr/xmoRG0sijLLp0xhq5zrb1JWxNJ X-Received: by 2002:a62:6f49:: with SMTP id k70mr3073624pfc.7.1549964873310; Tue, 12 Feb 2019 01:47:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549964873; cv=none; d=google.com; s=arc-20160816; b=wsPisqZ/IkisI9dgWzKH0szFLNzr5OkWk9ZvRwrpbxILihHsfGuLwhvuzB9Xb61Olm RkAuR1n5krsztDWeVg2MFmWupfEU3YZRFAt+z8EJx0ob5zhcauFs+dGZDfA6cCcuSBiO 9fTDmqWglSdIRBlaeveab+VRAnlB/FCqCHbdyUcx3Y3d/OntNIb0Lt1o2EuKeLF53urd jGc+KrMqFxKIanwQKKW6rkg1jkaU8pv2wsqnDbrEoYTgGW2oL2Y8CB9l3JKGR7xfxg2u fYE/HJugI9v2xo2SFV9mXHA5qfut3MVFmXeS2Bu+tjbkuDop2BuDyom9SFjtu2UglHH1 vpOg== 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; bh=qdbVjOb1UGIXeAWCx2oLuCJjPp+qBnJCH5yvjZopaYQ=; b=pxXb5Dk9MplSE8FLRTnZ576lwzuwiSNlddOTmRrSUHY8Ntxg1GixCDU8vJg5z4d5+U oDwnoL3z7+Ty12rraByxGFoDNzutEGL4rm1FI05YSTMatyR9MJSAiIV4eiidqtlbEWPG pDQcEUVC6Mi1SIUmvg1rAQJkNWpI22Er+h0acUOs9pxayhzEDK7bEQW7S5hYF4/afX3B x+4QHqw5HEnEOtpF/9YVh/dW1CsrfkzxCmGdITlbqWYgshYUYXgrVLO/HEBONK22VzY7 cSJByPWmu/hy42plEq45GGT5SQarO9VfKT3E80N4on3n/xseNFpWXoT2StOCd2ujvGU2 HUcA== 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 z17si9695481pgf.267.2019.02.12.01.47.37; Tue, 12 Feb 2019 01:47:53 -0800 (PST) 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 S1728087AbfBLJqK (ORCPT + 99 others); Tue, 12 Feb 2019 04:46:10 -0500 Received: from mx2.suse.de ([195.135.220.15]:59762 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726238AbfBLJqK (ORCPT ); Tue, 12 Feb 2019 04:46:10 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 0E042B016; Tue, 12 Feb 2019 09:46:09 +0000 (UTC) Date: Tue, 12 Feb 2019 10:46:08 +0100 From: Petr Mladek To: Josh Poimboeuf Cc: Kamalesh Babulal , live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, Miroslav Benes , Jiri Kosina Subject: Re: [PATCH] livepatch: Enforce reliable stack trace as config dependency Message-ID: <20190212094608.bzwc26j67daqnx6x@pathway.suse.cz> References: <20190209091728.23046-1-kamalesh@linux.vnet.ibm.com> <20190211140813.z7kap634gz3gp6a4@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190211140813.z7kap634gz3gp6a4@treble> User-Agent: NeoMutt/20170421 (1.8.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 2019-02-11 08:08:13, Josh Poimboeuf wrote: > Anyway, I'm not sure about this approach. This patch makes the s390 > livepatch code no longer compilable, turning it into completely dead > code. So if something changes in the s390 code which causes it to stop > compiling, nobody will notice. Good point. Well, it is only small win when a code is buildable but it could not get really used. Also the amount of arch-specific code is really minimal. > I think I'd rather go in the opposite direction: allow the patches to be > loaded. Then they can be forced, if needed. That enables both compile > and runtime testing. That way we don't make any backward progress, > until such arches get reliable stacktraces. Do you mean to convert the error into warning? For example, the change below. Note that I did not mention the possibility to force the transition by intention. It is risky and people should not get used to it. Heh, I think that this was the main reason why it was the error. We did not want to get people used to forcing livepatches. diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c index d1af69e9f0e3..8d9bce251516 100644 --- a/kernel/livepatch/core.c +++ b/kernel/livepatch/core.c @@ -1035,11 +1035,10 @@ int klp_enable_patch(struct klp_patch *patch) return -ENODEV; if (!klp_have_reliable_stack()) { - pr_err("This architecture doesn't have support for the livepatch consistency model.\n"); - return -EOPNOTSUPP; + pr_warn("This architecture doesn't have support for the livepatch consistency model.\n"); + pr_warn("Only one livepatch can be installed.\n"); } - mutex_lock(&klp_mutex); ret = klp_init_patch_early(patch); Best Regards, Petr