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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 037CBC4332F for ; Fri, 16 Dec 2022 13:56:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229898AbiLPN4A (ORCPT ); Fri, 16 Dec 2022 08:56:00 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38412 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229547AbiLPNz5 (ORCPT ); Fri, 16 Dec 2022 08:55:57 -0500 Received: from outbound-smtp10.blacknight.com (outbound-smtp10.blacknight.com [46.22.139.15]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3AC491145B for ; Fri, 16 Dec 2022 05:55:54 -0800 (PST) Received: from mail.blacknight.com (pemlinmail06.blacknight.ie [81.17.255.152]) by outbound-smtp10.blacknight.com (Postfix) with ESMTPS id 4E9921C3C1E for ; Fri, 16 Dec 2022 13:55:53 +0000 (GMT) Received: (qmail 25094 invoked from network); 16 Dec 2022 13:55:53 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.198.246]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 16 Dec 2022 13:55:52 -0000 Date: Fri, 16 Dec 2022 13:55:48 +0000 From: Mel Gorman To: Will Deacon Cc: Sebastian Andrzej Siewior , Peter Zijlstra , Jan Kara , Thomas Gleixner , Ingo Molnar , Waiman Long , Boqun Feng , Pierre Gondois , Steven Rostedt , Catalin Marinas , Davidlohr Bueso , LKML , Linux-RT Subject: Re: [PATCH] rtmutex: Add acquire semantics for rtmutex lock acquisition Message-ID: <20221216135548.itw2xrqbvuldk35y@techsingularity.net> References: <20221202100223.6mevpbl7i6x5udfd@techsingularity.net> <20221202150158.xzgovoy7wuic6vvk@techsingularity.net> <20221216111412.GA8666@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20221216111412.GA8666@willie-the-truck> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 16, 2022 at 11:14:12AM +0000, Will Deacon wrote: > > diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c > > index 35212f260148..af0dbe4d5e97 100644 > > --- a/kernel/locking/rtmutex.c > > +++ b/kernel/locking/rtmutex.c > > @@ -238,6 +238,13 @@ static __always_inline void mark_rt_mutex_waiters(struct rt_mutex_base *lock) > > owner = *p; > > } while (cmpxchg_relaxed(p, owner, > > owner | RT_MUTEX_HAS_WAITERS) != owner); > > + > > + /* > > + * The cmpxchg loop above is relaxed to avoid back-to-back ACQUIRE > > + * operations in the event of contention. Ensure the successful > > + * cmpxchg is visible. > > + */ > > + smp_mb__after_atomic(); > > Could we use smp_acquire__after_ctrl_dep() instead? > It's might be sufficient but it's not as obviously correct. It lacks an obvious pairing that is definitely correct but the control dependency combined with the smp_acquire__after_ctrl_dep *should* be sufficient against the lock fast path based on the available documentation. However, I was unable to convince myself that this is definitely correct on all CPUs. Given that arm64 was trivial to crash on PREEMPT_RT before the patch (hackbench pipes also triggers the same problem), I'm reluctant to try and be too clever particularly as I didn't have a reproducer for a problem in this specific path. If someone can demonstrate a reasonable case where smp_mb__after_atomic() is too heavy and document that it can be safely relaxed then great. At least if that relaxing is wrong, there will be a bisection point between the fix and the reintroduction of damage. -- Mel Gorman SUSE Labs