From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934344AbdEKOut (ORCPT ); Thu, 11 May 2017 10:50:49 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:39557 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932441AbdEKOud (ORCPT ); Thu, 11 May 2017 10:50:33 -0400 Date: Thu, 11 May 2017 07:50:28 -0700 From: "Paul E. McKenney" To: Petr Mladek Cc: Steven Rostedt , Josh Poimboeuf , Jessica Yu , Jiri Kosina , Miroslav Benes , 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 Reply-To: paulmck@linux.vnet.ibm.com 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> <20170511135246.GN3452@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170511135246.GN3452@pathway.suse.cz> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 17051114-0024-0000-0000-0000026B1F73 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007047; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000211; SDB=6.00859174; UDB=6.00425794; IPR=6.00638649; BA=6.00005345; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00015413; XFM=3.00000015; UTC=2017-05-11 14:50:31 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17051114-0025-0000-0000-000043F5A341 Message-Id: <20170511145028.GD3956@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-05-11_11:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705110081 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 11, 2017 at 03:52:46PM +0200, Petr Mladek wrote: > 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? Only RCU readers can be used in NMI handlers, that is, rcu_read_lock(), rcu_read_unlock(), rcu_dereference(), and so on. Thanx, Paul > 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 >