From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752579AbbIHUJl (ORCPT ); Tue, 8 Sep 2015 16:09:41 -0400 Received: from e37.co.us.ibm.com ([32.97.110.158]:48920 "EHLO e37.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752048AbbIHUJh (ORCPT ); Tue, 8 Sep 2015 16:09:37 -0400 X-Helo: d03dlp02.boulder.ibm.com X-MailFrom: paulmck@linux.vnet.ibm.com X-RcptTo: linux-kernel@vger.kernel.org Date: Tue, 8 Sep 2015 13:02:42 -0700 From: "Paul E. McKenney" To: Petr Mladek Cc: Josh Triplett , Steven Rostedt , Mathieu Desnoyers , Lai Jiangshan , Jiri Kosina , linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] rcu: Fix up timeouts for forcing the quiescent state Message-ID: <20150908200242.GY4029@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <1441368690-32345-1-git-send-email-pmladek@suse.com> <1441368690-32345-3-git-send-email-pmladek@suse.com> <20150904234946.GE4029@linux.vnet.ibm.com> <20150907152102.GC9577@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150907152102.GC9577@pathway.suse.cz> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15090820-0025-0000-0000-00001C0831C5 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 07, 2015 at 05:21:02PM +0200, Petr Mladek wrote: > On Fri 2015-09-04 16:49:46, Paul E. McKenney wrote: > > On Fri, Sep 04, 2015 at 02:11:30PM +0200, Petr Mladek wrote: > > > The deadline to force the quiescent state (jiffies_force_qs) is currently > > > updated only when the previous timeout passed. But the timeout used for > > > wait_event() is always the entire original timeout. This is strange. > > > > They tell me that kthreads aren't supposed to every catch signals, > > hence the WARN_ON() in the early-exit case stray-signal case. > > Yup, I have investigated this recently. All signals are really blocked > for kthreads by default. There are few threads that use signals but > they explicitly enable it by allow_signal(). Good! ;-) > > In the case where we were awakened with an explicit force-quiescent-state > > request, we do the scan, and then wait the full time for the next scan. > > So the point of the delay is to space out the scans, not to fit a > > pre-determined schedule. > > > > The reason we get awakened with an explicit force-quiescent-state > > request is that a given CPU just got inundated with RCU callbacks > > or that rcutorture wants to hammer this code path. > > > > So I am not seeing this as anything in need of fixing. > > > > Am I missing something subtle here? > > There is the commit 88d6df612cc3c99f5 ("rcu: Prevent spurious-wakeup > DoS attack on rcu_gp_kthread()"). It suggests that the spurious > wakeups are possible. > > I would consider this patch as a fix/clean up of this Dos attack fix. > Huh, I forgot to mention it in the commit message. > > To be honest, I personally do not know how to trigger the spurious > wakeup in the current state of the code. I am trying to convert > the kthread into the kthread worker API and there I got the spurious > wakeups but this is another story. You can do it via rcutorture, but that is not an in-production concern. You can also do it by having all CPUs invoke call_rcu() in a tight loop. > Thanks a lot for reviewing. And thank you for your interest in the Linux-kernel RCU implementation! Thanx, Paul