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 S1754068AbbCBJVj (ORCPT <rfc822;w@1wt.eu>);
	Mon, 2 Mar 2015 04:21:39 -0500
Received: from cantor2.suse.de ([195.135.220.15]:42600 "EHLO mx2.suse.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751537AbbCBJVh (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 2 Mar 2015 04:21:37 -0500
Date: Mon, 2 Mar 2015 10:21:35 +0100
From: Petr Mladek <pmladek@suse.cz>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Jiri Kosina <jkosina@suse.cz>, mingo@kernel.org, rusty@rustcorp.com.au,
        mathieu.desnoyers@efficios.com, oleg@redhat.com,
        paulmck@linux.vnet.ibm.com, linux-kernel@vger.kernel.org,
        andi@firstfloor.org, rostedt@goodmis.org, tglx@linutronix.de,
        Seth Jennings <sjenning@redhat.com>,
        Josh Poimboeuf <jpoimboe@redhat.com>,
        Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
        Miroslav Benes <mbenes@suse.cz>
Subject: Re: [RFC][PATCH 1/9] klp: Fix obvious RCU fail
Message-ID: <20150302092134.GE3703@dhcp128.suse.cz>
References: <20150228212447.381543289@infradead.org>
 <20150228213109.893891745@infradead.org>
 <alpine.LNX.2.00.1503012108270.9089@pobox.suse.cz>
 <20150302083530.GD5029@twins.programming.kicks-ass.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150302083530.GD5029@twins.programming.kicks-ass.net>
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-02 09:35:30, Peter Zijlstra wrote:
> On Sun, Mar 01, 2015 at 09:09:24PM +0100, Jiri Kosina wrote:
> > On Sat, 28 Feb 2015, Peter Zijlstra wrote:
> > 
> > > While one must hold RCU-sched (aka. preempt_disable) for find_symbol()
> > > one must equally hold it over the use of the object returned.
> > > 
> > > The moment you release the RCU-sched read lock, the object can be dead
> > > and gone.
> > > 
> > > Cc: Seth Jennings <sjenning@redhat.com>
> > > Cc: Josh Poimboeuf <jpoimboe@redhat.com>
> > > Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
> > > Cc: Miroslav Benes <mbenes@suse.cz>
> > > Cc: Petr Mladek <pmladek@suse.cz>
> > > Cc: Jiri Kosina <jkosina@suse.cz>
> > > Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> > > Cc: Rusty Russell <rusty@rustcorp.com.au>
> > > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> > 
> > Acked-by: Jiri Kosina <jkosina@suse.cz>
> > 
> > I guess you'll be taking this together with the series, so I am not 
> > applying it.
> 
> Feel free to take it; this series might take a wee while longer to
> mature.
> 
> That said; I do have a follow up question on that code. So now you've
> successfully obtained an address in module space; but the moment you
> release that RCU-sched lock, the module can be gone.
> 
> How does the whole live patching stuff deal with module removal during
> patching?

There is a notifier, see klp_module_notify(). It applies existing
patches when an affected module is loaded. Also it removes patches
when an affected module is going. It is serialized with the other
operations using the klp_mutex lock.

Hmm, when I think about it. I am afraid that there is a race. For
example, the going module might be unpatched by the notifier but
a new patch might get applied when it is still visible by kallsyms.
I am going to look at it.

Best Regards,
Petr