Date: Thu, 11 Jan 2018 11:00:42 +0100 (CET)
From: Jiri Kosina <jikos@kernel.org>
To: Miroslav Benes <mbenes@suse.cz>
cc: jpoimboe@redhat.com, jeyu@kernel.org, linux-kernel@vger.kernel.org,
        live-patching@vger.kernel.org, pmladek@suse.com, jbaron@akamai.com
Subject: Re: [PATCH v2] livepatch: Remove immediate feature
In-Reply-To: <20180110100128.25505-1-mbenes@suse.cz>
Message-ID: <nycvar.YFH.7.76.1801111059400.11852@cbobk.fhfr.pm>
References: <20180110100128.25505-1-mbenes@suse.cz>
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

On Wed, 10 Jan 2018, Miroslav Benes wrote:

> Immediate flag has been used to disable per-task consistency and patch
> all tasks immediately. It could be useful if the patch doesn't change any
> function or data semantics.
> 
> However, it causes problems on its own. The consistency problem is
> currently broken with respect to immediate patches.
> 
> func            a
> patches         1i
>                 2i
>                 3
> 
> When the patch 3 is applied, only 2i function is checked (by stack
> checking facility). There might be a task sleeping in 1i though. Such
> task is migrated to 3, because we do not check 1i in
> klp_check_stack_func() at all.
> 
> Coming atomic replace feature would be easier to implement and more
> reliable without immediate.
> 
> Thus, remove immediate feature completely and save us from the problems.
> 
> Note that force feature has the similar problem. However it is
> considered as a last resort. If used, administrator should not apply any
> new live patches and should plan for reboot into an updated kernel.
> 
> The architectures would now need to provide HAVE_RELIABLE_STACKTRACE to
> fully support livepatch.
> 
> Signed-off-by: Miroslav Benes <mbenes@suse.cz>
> ---
> v2 changes:
> - 2/2 from v1 dropped
> - documentation

It's very refreshing to have to handle something non-toxic (no PTI, no 
retpolines) finally :)

Applied to for-4.16/remove-immediate, thanks.

-- 
Jiri Kosina
SUSE Labs