From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S932848AbdEKMuD (ORCPT <rfc822;w@1wt.eu>);
        Thu, 11 May 2017 08:50:03 -0400
Received: from mx2.suse.de ([195.135.220.15]:44501 "EHLO mx1.suse.de"
        rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP
        id S932212AbdEKMuC (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 11 May 2017 08:50:02 -0400
Date: Thu, 11 May 2017 14:50:00 +0200 (CEST)
From: Miroslav Benes <mbenes@suse.cz>
To: Steven Rostedt <rostedt@goodmis.org>
cc: Josh Poimboeuf <jpoimboe@redhat.com>, Petr Mladek <pmladek@suse.com>,
        Jessica Yu <jeyu@redhat.com>, Jiri Kosina <jikos@kernel.org>,
        "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
        live-patching@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is broken
 in RCU code
In-Reply-To: <20170508161816.4243340e@gandalf.local.home>
Message-ID: <alpine.LSU.2.20.1705111440580.20501@pobox.suse.cz>
References: <1493895316-19165-1-git-send-email-pmladek@suse.com> <1493895316-19165-3-git-send-email-pmladek@suse.com> <20170508165108.d3vd4h6ffa25bfui@treble> <20170508151322.76e8e9db@gandalf.local.home> <20170508194729.jjq7qrc7gkiq2s5v@treble>
 <20170508161816.4243340e@gandalf.local.home>
User-Agent: Alpine 2.20 (LSU 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, 8 May 2017, Steven Rostedt wrote:

> On Mon, 8 May 2017 14:47:29 -0500
> Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> 
> > > Although you should have:
> > > 
> > > 	if (WARN_ONCE(!rcu_is_watching,
> > > 			"Livepatch ..."))
> > > 		return;
> > > 
> > > or something to not cause any damage.  
> > 
> > My understanding is that returning would be more dangerous than
> > continuing here.
> > 
> > By continuing to run, there's only a small chance that it will get stale
> > data, which would break the consistency model by executing an old
> > version of the function and possibly crashing the system.
> > 
> > On the other hand, returning would unconditionally break the consistency
> > model by *always* executing an old version of the function.  So that
> > greatly increases the risk of a crash.
> 
> I was being oversimplified by saying 'return', perhaps go into a
> critical mode that can try again, or perhaps even back out the patch.
> As in a transaction style. Yes, this will need to be thought through to
> know how to get out. My comment wasn't meant to be simple.

Well, live patching is in fact transactional. To some extent. If we fail 
during ftrace registration we abort the action gracefully. After the 
registration it gets more interesting because the whole system is 
"asynchronously" migrated to a final patched state. Even during this stage 
we can reverse the process (klp_reverse_transition()), but it was not easy 
to get it right...

... and to implement or start this logic from the handler sends shivers 
down my spine.

We still can try.

Thanks,
Miroslav