From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752015AbbIGPVI (ORCPT ); Mon, 7 Sep 2015 11:21:08 -0400 Received: from mx2.suse.de ([195.135.220.15]:60984 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750850AbbIGPVF (ORCPT ); Mon, 7 Sep 2015 11:21:05 -0400 Date: Mon, 7 Sep 2015 17:21:02 +0200 From: Petr Mladek To: "Paul E. McKenney" 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: <20150907152102.GC9577@pathway.suse.cz> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150904234946.GE4029@linux.vnet.ibm.com> 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 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(). > 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. Thanks a lot for reviewing. Best Regards, Petr