From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2B7EFC433E6 for ; Mon, 11 Jan 2021 11:51:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D536A224BD for ; Mon, 11 Jan 2021 11:51:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730035AbhAKLvK (ORCPT ); Mon, 11 Jan 2021 06:51:10 -0500 Received: from mail.kernel.org ([198.145.29.99]:37826 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729755AbhAKLvJ (ORCPT ); Mon, 11 Jan 2021 06:51:09 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 7A351224BD; Mon, 11 Jan 2021 11:50:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1610365829; bh=NP9L6a6Mu9+yVb7bcao5sARkOO84Twaf5gsOxbxTCz4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=B8xIUnRGbG+eiLmhAKkTAsjfXbTYgQ8uYAVSl4bxG+leFEqHaXhtNHSdrT/Wg1Qby p4mox/VJcbAsuChYQKfGUT5MPWDclBa+Vs7ZVCHgzgwZTMKAXZrYdMnyvnA5WocTZq WIsSg74NkVIy04joBEPJ+vveTpsaKvpRXhyxJqeiQfpb8QAKII/LGOxXH8yURCs6ir pL7MdfM1R4DPUVN7j5G+5GUEv09h1wMLcbtLNnDgfjJ0m6u+F5i39hpxXXUPFKAdIr mhkehV98MT98x0YSJ+QMhYPW1hMtXk66Ehc1HAUArzwLoGYfiQTX9DHFDuC2fsyzGI 3CleWD3eEwxMw== Date: Mon, 11 Jan 2021 12:50:26 +0100 From: Frederic Weisbecker To: "Paul E. McKenney" Cc: Peter Zijlstra , LKML , "Rafael J . Wysocki" , Ingo Molnar , Thomas Gleixner , stable@vger.kernel.org Subject: Re: [RFC PATCH 5/8] entry: Explicitly flush pending rcuog wakeup before last rescheduling points Message-ID: <20210111115026.GC242508@lothringen> References: <20210109020536.127953-1-frederic@kernel.org> <20210109020536.127953-6-frederic@kernel.org> <20210111004014.GA242508@lothringen> <20210111051318.GZ2743@paulmck-ThinkPad-P72> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210111051318.GZ2743@paulmck-ThinkPad-P72> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Jan 10, 2021 at 09:13:18PM -0800, Paul E. McKenney wrote: > On Mon, Jan 11, 2021 at 01:40:14AM +0100, Frederic Weisbecker wrote: > > On Sat, Jan 09, 2021 at 03:05:33AM +0100, Frederic Weisbecker wrote: > > > Following the idle loop model, cleanly check for pending rcuog wakeup > > > before the last rescheduling point on resuming to user mode. This > > > way we can avoid to do it from rcu_user_enter() with the last resort > > > self-IPI hack that enforces rescheduling. > > > > > > Signed-off-by: Frederic Weisbecker > > > Cc: Peter Zijlstra > > > Cc: Thomas Gleixner > > > Cc: Ingo Molnar > > > Cc: Paul E. McKenney > > > Cc: Rafael J. Wysocki > > > --- > > > kernel/entry/common.c | 6 ++++++ > > > kernel/rcu/tree.c | 12 +++++++----- > > > 2 files changed, 13 insertions(+), 5 deletions(-) > > > > > > diff --git a/kernel/entry/common.c b/kernel/entry/common.c > > > index 378341642f94..8f3292b5f9b7 100644 > > > --- a/kernel/entry/common.c > > > +++ b/kernel/entry/common.c > > > @@ -178,6 +178,9 @@ static unsigned long exit_to_user_mode_loop(struct pt_regs *regs, > > > /* Architecture specific TIF work */ > > > arch_exit_to_user_mode_work(regs, ti_work); > > > > > > + /* Check if any of the above work has queued a deferred wakeup */ > > > + rcu_nocb_flush_deferred_wakeup(); > > > > So this needs to be moved to the IRQs disabled section, just a few lines later, > > otherwise preemption may schedule another task that in turn do call_rcu() and create > > new deferred wake up (thank Paul for the warning). Not to mention moving to > > another CPU with its own deferred wakeups to flush... > > > > I'll fix that for the next version. > > Ah, so it was not just my laptop dying, then! ;-) Note that it fixes the "smp_processor_id() in preemptible" warnings you reported but it shouldn't fix the other issues.