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 S1752788AbbCWQhr (ORCPT <rfc822;w@1wt.eu>);
	Mon, 23 Mar 2015 12:37:47 -0400
Received: from cantor2.suse.de ([195.135.220.15]:54649 "EHLO mx2.suse.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752485AbbCWQhp (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 23 Mar 2015 12:37:45 -0400
Date: Mon, 23 Mar 2015 17:38:06 +0100
From: Petr Mladek <pmladek@suse.cz>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Ingo Molnar <mingo@kernel.org>,
        Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
        "David S. Miller" <davem@davemloft.net>,
        Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>,
        Ananth NMavinakayanahalli <ananth@in.ibm.com>,
        Frederic Weisbecker <fweisbec@gmail.com>,
        Ingo Molnar <mingo@redhat.com>, Jiri Kosina <jkosina@suse.cz>,
        linux-kernel@vger.kernel.org,
        "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Subject: Re: [PATCH v3] kprobes: Disable Kprobe when ftrace arming fails
Message-ID: <20150323163805.GF15177@pathway.suse.cz>
References: <1426860127-7896-1-git-send-email-pmladek@suse.cz>
 <20150323085426.GB28965@gmail.com>
 <20150323101253.GN11869@pathway.suse.cz>
 <20150323103327.GA12213@gmail.com>
 <20150323123955.GE15177@pathway.suse.cz>
 <20150323093013.15b6070b@gandalf.local.home>
 <20150323133442.GC23145@gmail.com>
 <20150323094317.38dcb601@gandalf.local.home>
 <20150323135306.GA25233@gmail.com>
 <20150323095853.56eae095@gandalf.local.home>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150323095853.56eae095@gandalf.local.home>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon 2015-03-23 09:58:53, Steven Rostedt wrote:
> On Mon, 23 Mar 2015 14:53:06 +0100
> Ingo Molnar <mingo@kernel.org> wrote:
> 
> 
> > > I think it has to do with their RCU like patching functionality, 
> > > where some tasks are still executing the old function and others are 
> > > executing the new function. [...]
> > 
> > That would be the 'function with pending patch' state in my 
> > description above.
> 
> That could be considered a bit confusing too, because the patch isn't
> pending, it's already applied. But this is getting off topic, as the
> code for this isn't even in mainline yet, so I agree that the use of
> terminology that has not been upstreamed yet should be avoided.

I am sorry for confusion. I will be more careful about the terminology
in my mails.

Anyway, I did not use the word because I wanted to be special. I
joined the team working on kGraft (SUSE live patch implementation)
when the work was already in progress. This term was used there
heavily. You know, I have used it for too long and somehow forgot
that many other people were not familiar with it.

And yes, it is similar to RCU terminology. If we added support
for patches that modify semantic of functions, there would be
three states as well:

  1. no patch

  2. patch is added; ftrace handler is added but it does _not_
     redirect the code; the old function is still used because there has
     not been a safe point for the switch yet

  3. patch is added; ftrace handler is added and it redirects the call
     to the new implementation from the patch


The second state is similar to RCU intermediate state. A list has
been modified but some thread might still see the old state.


Best Regards,
Petr