Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2081952imu; Tue, 6 Nov 2018 08:49:49 -0800 (PST) X-Google-Smtp-Source: AJdET5fekVffv/jL/0XlG0Iiag1lc5D9OgE4yHIcn4SjKM1fPju9ejkSH3NMg1utJb4eammAGVFz X-Received: by 2002:a17:902:b405:: with SMTP id x5-v6mr20730693plr.4.1541522989026; Tue, 06 Nov 2018 08:49:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541522989; cv=none; d=google.com; s=arc-20160816; b=ukr/DrafI3jBMMCYVM017AA5/xXCE9SK7DPYUzIKpwlQrHfhmG0jB4ZuoCXt9YV+Ut ChS+OWkCxfMg0k81J6JIagaap+/GLh8zqule7JKooF4jJT5qAqDjXvcoI9j8PmSS3vBL ckAlpEb8xH+M9AuwD4bDz4tRUZkv/Juo/dEzzvanptMWwZc4LtQc4gURPvXibI4vFH6F A8hGcc2OgmVSbpJoRhpAAfLV/WCaqkBpNAy2bWyLkK3xkExyuAdSiMxc5TJOWCoJAApH dpZDjUsKzQv4f/XgqxNCDV+oP/RZW17bqX41t8wGykQnpLroPaQ5LOGajbK96lefGP3M Nseg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=FyDv+8646cUoxr7fSX+Cf/+wnAJiQqQEWwQDnfYo8bM=; b=XHgLGQwS6CX2lP3UVxS/QOC7timeRY4kdfHGmG8qxK1+auzdkSyjj25tNSfEQgMbzu AXUOZz7pj45UtayZgmOL3fFlr+R205rmm+9Hn02jolM63OYJdBz3rCkH7lcbj/4TQTvU XDb/gCbXeeGmy//asH0dmoRwZWJL/31QCjAmByB8/2vXeneGk6Ny2mvcQv2wbYiP4gSM nGe6cU4ZLACXRNPvfUxUHo884tFPEbILZ+sgOyeGE85y2oDj75w3DVS7FGoGcNeZVO4F F91daHH0VF3MpOxAQwapP7cYhFbfPE25liRKeUQMS7+OXzxCFp5Vl5jFxEMpfUnnSkw/ V/ag== 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 i13-v6si46679391pgd.311.2018.11.06.08.49.33; Tue, 06 Nov 2018 08:49:48 -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 S2389376AbeKGCPO (ORCPT + 99 others); Tue, 6 Nov 2018 21:15:14 -0500 Received: from mx2.suse.de ([195.135.220.15]:42018 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2389241AbeKGCPO (ORCPT ); Tue, 6 Nov 2018 21:15:14 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 7001DB71C; Tue, 6 Nov 2018 16:49:08 +0000 (UTC) Date: Tue, 6 Nov 2018 17:49:07 +0100 (CET) From: Miroslav Benes To: Torsten Duwe cc: Will Deacon , Catalin Marinas , Julien Thierry , Steven Rostedt , Josh Poimboeuf , Ingo Molnar , Ard Biesheuvel , Arnd Bergmann , AKASHI Takahiro , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, live-patching@vger.kernel.org Subject: Re: [PATCH v4 2/3] arm64: implement live patching In-Reply-To: <20181026142152.5F0D868C95@newverein.lst.de> Message-ID: References: <20181026142008.D922868C94@newverein.lst.de> <20181026142152.5F0D868C95@newverein.lst.de> User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Fri, 26 Oct 2018, Torsten Duwe wrote: > Based on ftrace with regs, do the usual thing. > (see Documentation/livepatch/livepatch.txt) > > Use task flag bit 6 to track patch transisiton state for the consistency > model. Add it to the work mask so it gets cleared on all kernel exits to > userland. > > Tell livepatch regs->pc is the place to change the return address. > Make sure the graph tracer call hook is only called on the final function > entry in case regs->pc gets modified after an interception. > > Signed-off-by: Torsten Duwe It looks good now apart from arm64 asm part which should be reviewed by someone else. However, could you summarize our analysis regarding post-module-load calls of apply_relocate_add() in the commit log, please? It is important for future reference. Thanks, Miroslav