Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp4233577ybz; Tue, 28 Apr 2020 07:56:18 -0700 (PDT) X-Google-Smtp-Source: APiQypKBPmqVdt7nD1YG+wvJNmXGqTr5rNF8J1/XKKU51UpjXVh3FvxT/XEkzHCz7kspkpa/ZLQB X-Received: by 2002:a17:907:2142:: with SMTP id rk2mr25870859ejb.356.1588085778698; Tue, 28 Apr 2020 07:56:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588085778; cv=none; d=google.com; s=arc-20160816; b=VQ2VIQ+aDhuay145wvChuJU3e844OP+68hmVgD4BEO0SmtwrQqmhDYNLqlCi4zplLn oQTQvG6gs6V0l46iYNCFY9xKIy1hLDsq2rIKwSlIZUdPjsRU8GnXZOLpNZaaEsXb73j5 T9fBnFdW1067Kx7AXsHz2mFQImvNmcISQXnNsHuE3e0ecypkigxoe90JBYMk+ypG1BpM txWS/d65K+SZZHY4FJ3XDhmZiM8rB2L40hI7Q+vlI+OMjl2qLIg/7fL0uoMuUgDOPHIN NYIJliSy0TIxtUxbWSPB5sf6dDckdPllhpjhGediflgf8tDliPuWCsvfcP2X5FWUWn/S iMZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=MUW05d30Ozsy6t7MI/6lCctZnWOQlkQnzVkp5TqlJ4w=; b=GIC4MNTHJYN+LvU8Mn9xwOOjTBgpa2IYmRGlf92zAQFSCfY2LUjC3w0h+6RmtQoSRt p4+eRu4jDzJPTLrSeYwb3xuHtF1LiwkYPl4uAuzTzsDKsR+mzYjvCF2igOv5Qtw4LWrP PMxF5huc/JBiiJiszQ7V0CvQJO76eVFQACj9opgLOtx5WUQzKhU6/fH3IuALRvXulnrJ BmdChYVzT9elIXGuDi9cu/gdhcW2TJlhJmaTao/qn8S0UfK7ix/HAP5BUwtYBjTJPlnN TLbWw4aMkBu6zxWo1rAaEiVvVW1lCXYW0E2ZSA+85YOfyc2qOxIiYY+BijlnUr/Ydken Pw7A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e21si1797859edq.508.2020.04.28.07.55.55; Tue, 28 Apr 2020 07:56:18 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728112AbgD1Oxk (ORCPT + 99 others); Tue, 28 Apr 2020 10:53:40 -0400 Received: from mail.kernel.org ([198.145.29.99]:51674 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727775AbgD1Oxh (ORCPT ); Tue, 28 Apr 2020 10:53:37 -0400 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 936FB205C9; Tue, 28 Apr 2020 14:53:36 +0000 (UTC) Date: Tue, 28 Apr 2020 10:53:35 -0400 From: Steven Rostedt To: Rasmus Villemoes Cc: linux-kernel@vger.kernel.org, linux-rt-users@vger.kernel.org, Thomas Gleixner , Carsten Emde , Sebastian Andrzej Siewior , Tom Zanussi , Julien Grall , Daniel Wagner , John Kacur Subject: Re: [PATCH -rt] hrtimer: fix logic for when grabbing softirq_expiry_lock can be elided Message-ID: <20200428105335.16011a4a@gandalf.local.home> In-Reply-To: <20200428144026.5882-1-rasmus.villemoes@prevas.dk> References: <20200428144026.5882-1-rasmus.villemoes@prevas.dk> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 28 Apr 2020 16:40:26 +0200 Rasmus Villemoes wrote: > Commit > > hrtimer: Add a missing bracket and hide `migration_base' on !SMP > > which is 47b6de0b7f22 in 5.2-rt and 40aae5708e7a in 4.19-rt, > inadvertently changed the logic from base != &migration_base to base > == &migration_base. > > On !CONFIG_SMP, the effect was to effectively always elide this > lock/unlock pair (since is_migration_base() is unconditionally false), > which for me consistently causes lockups during reboot, and reportedly > also often causes a hang during boot. > > Adding this logical negation (or, what is effectively the same thing > on !CONFIG_SMP, reverting the above commit as well as "hrtimer: > Prevent using hrtimer_grab_expiry_lock() on migration_base") fixes > that lockup. > > Fixes: 40aae5708e7a (hrtimer: Add a missing bracket and hide `migration_base' on !SMP) # 4.19-rt > Fixes: 47b6de0b7f22 (hrtimer: Add a missing bracket and hide `migration_base' on !SMP) # 5.2-rt > Signed-off-by: Rasmus Villemoes > --- > Something like this? I wasn't sure what Fixes: tag(s) to include, if > any. It's quite possible the same fix is needed on earlier -rt > kernels, I didn't check. > > kernel/time/hrtimer.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c > index e54a95de8b79..c3966c090246 100644 > --- a/kernel/time/hrtimer.c > +++ b/kernel/time/hrtimer.c > @@ -953,7 +953,7 @@ void hrtimer_grab_expiry_lock(const struct hrtimer *timer) > { > struct hrtimer_clock_base *base = READ_ONCE(timer->base); > > - if (timer->is_soft && is_migration_base(base)) { > + if (timer->is_soft && !is_migration_base(base)) { That was my sloppiness in not seeing that 5.2-rt had == and 4.19 had !=. Thanks for tracking this down! Reviewed-by: Steven Rostedt (VMware) -- Steve > spin_lock(&base->cpu_base->softirq_expiry_lock); > spin_unlock(&base->cpu_base->softirq_expiry_lock); > }