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 527C9EB64DD for ; Fri, 23 Jun 2023 12:21:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230280AbjFWMV0 (ORCPT ); Fri, 23 Jun 2023 08:21:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49650 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229449AbjFWMVY (ORCPT ); Fri, 23 Jun 2023 08:21:24 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 29EE01BE4 for ; Fri, 23 Jun 2023 05:21:23 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C94B51042; Fri, 23 Jun 2023 05:22:06 -0700 (PDT) Received: from [192.168.178.6] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 760B33F59C; Fri, 23 Jun 2023 05:21:19 -0700 (PDT) Message-ID: <509d5ee4-45ec-1279-97da-a308ec7f51aa@arm.com> Date: Fri, 23 Jun 2023 14:21:16 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH v4 02/13] locking/ww_mutex: Remove wakeups from under mutex::wait_lock Content-Language: en-US To: John Stultz , LKML Cc: Peter Zijlstra , Joel Fernandes , Qais Yousef , Ingo Molnar , Juri Lelli , Vincent Guittot , Valentin Schneider , Steven Rostedt , Ben Segall , Zimuzo Ezeozue , Youssef Esmat , Mel Gorman , Daniel Bristot de Oliveira , Will Deacon , Waiman Long , Boqun Feng , "Paul E . McKenney" , kernel-team@android.com, Connor O'Brien References: <20230601055846.2349566-1-jstultz@google.com> <20230601055846.2349566-3-jstultz@google.com> From: Dietmar Eggemann In-Reply-To: <20230601055846.2349566-3-jstultz@google.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi John, On 01/06/2023 07:58, John Stultz wrote: > From: Peter Zijlstra > > In preparation to nest mutex::wait_lock under rq::lock we need to remove > wakeups from under it. [...] > Signed-off-by: Peter Zijlstra (Intel) > Signed-off-by: Connor O'Brien > Signed-off-by: John Stultz > --- > v2: > * Move wake_q_init() as suggested by Waiman Long > --- > include/linux/ww_mutex.h | 3 +++ > kernel/locking/mutex.c | 8 ++++++++ > kernel/locking/ww_mutex.h | 10 ++++++++-- > 3 files changed, 19 insertions(+), 2 deletions(-) > > diff --git a/include/linux/ww_mutex.h b/include/linux/ww_mutex.h > index bb763085479a..9335b2202017 100644 > --- a/include/linux/ww_mutex.h > +++ b/include/linux/ww_mutex.h > @@ -19,6 +19,7 @@ > > #include > #include > +#include > > #if defined(CONFIG_DEBUG_MUTEXES) || \ > (defined(CONFIG_PREEMPT_RT) && defined(CONFIG_DEBUG_RT_MUTEXES)) > @@ -58,6 +59,7 @@ struct ww_acquire_ctx { > unsigned int acquired; > unsigned short wounded; > unsigned short is_wait_die; > + struct wake_q_head wake_q; you told me that there is already an issue in this patch even w/o PE when running `insmod /lib/modules/test-ww_mutex.ko`. The issue is related to Connor's version (1): https://lkml.kernel.org/r/20221003214501.2050087-2-connoro@google.com struct ww_acquire_ctx { struct wake_q_head wake_q; __mutex_lock_common() if (ww_ctx) ww_ctx_wake(ww_ctx) wake_up_q(&ww_ctx->wake_q); wake_q_init(&ww_ctx->wake_q); Juri's version (2): https://lkml.kernel.org/r/20181009092434.26221-3-juri.lelli@redhat.com __mutex_lock_common() DEFINE_WAKE_Q(wake_q) <-- !!! __ww_mutex_check_waiters(..., wake_q) __ww_mutex_die(..., wake_q) wake_q_add(wake_q, waiter->task) wake_up_q(&wake_q) `insmod /lib/modules/test-ww_mutex.ko` runs fine with (2) but not with (1) (both w/o the remaining PE patches). So to test the PE issues we talked about already which come with `[PATCH v4 09/13] sched: Add proxy execution` and CONFIG_PROXY_EXEC=y we need to fix (1) or go back to (2). I haven't found any clues why (2) was changed to (1) so far. [...]