From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932731AbdEKNxD (ORCPT ); Thu, 11 May 2017 09:53:03 -0400 Received: from mx2.suse.de ([195.135.220.15]:48670 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755632AbdEKNwt (ORCPT ); Thu, 11 May 2017 09:52:49 -0400 Date: Thu, 11 May 2017 15:52:46 +0200 From: Petr Mladek To: Steven Rostedt Cc: Josh Poimboeuf , Jessica Yu , Jiri Kosina , Miroslav Benes , "Paul E. McKenney" , 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 Message-ID: <20170511135246.GN3452@pathway.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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170508151322.76e8e9db@gandalf.local.home> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 2017-05-08 15:13:22, Steven Rostedt wrote: > On Mon, 8 May 2017 11:51:08 -0500 > Josh Poimboeuf wrote: > > > Another idea would be to figure out a way to stop using RCU in > > klp_ftrace_handler() altogether. > > > > That may work if rcu_enter_irq() doesn't. But that's how NMIs use rcu. I am a bit confused by the above. Does it mean that RCU could not be used in NMI handlers? Anyway, a crazy idea is to use the livepatch consistency model instead of RCU to protect the function stack. The model makes sure that all tasks, including the idle ones, were not running any patched function (and their ftrace handlers) at some point. It should be safe but I am not sure if it is worth it. Alternatively, it might be enough to use the probably more lightwight solution that is used when ftrace handlers are deregistered, I mean: /* * We need to do a hard force of sched synchronization. * This is because we use preempt_disable() to do RCU, but * the function tracers can be called where RCU is not watching * (like before user_exit()). We can not rely on the RCU * infrastructure to do the synchronization, thus we must do it * ourselves. */ schedule_on_each_cpu(ftrace_sync); /* * When the kernel is preeptive, tasks can be preempted * while on a ftrace trampoline. Just scheduling a task on * a CPU is not good enough to flush them. Calling * synchornize_rcu_tasks() will wait for those tasks to * execute and either schedule voluntarily or enter user space. */ if (IS_ENABLED(CONFIG_PREEMPT)) synchronize_rcu_tasks(); Best Regards, Petr