From patchwork Wed Nov 27 08:54:30 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Thomas_Hellstr=C3=B6m?= X-Patchwork-Id: 13886720 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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 562EAD609B0 for ; Wed, 27 Nov 2024 09:01:46 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id D245310EA3E; Wed, 27 Nov 2024 09:01:45 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="RbpjAyuw"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.20]) by gabe.freedesktop.org (Postfix) with ESMTPS id 4CB2810EA3B; Wed, 27 Nov 2024 09:01:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1732698105; x=1764234105; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=h3CMnL4eliTX9gzLSTV1y6gHQDFmYxmyCKxh3w3Jy2k=; b=RbpjAyuw3lYcFNu2ZxeO71Q5f6VsMdSTbvKYZAtpllbrjbvYwOXIDqki qeJNq3mR2TZo8Y/Yz2oKYEfaTj1T02KPQNWPuOfKdqJB5bJGmYky3SAHf dZydJjo/FqhcmhnzVM8NCksvu15SZ3dVBWLmAWy/sjT2je282uMcMS+zh laVGBX13h72XfvRJ3GoNbPllrqmmu8fdSMvoBo8Ze5SoBo5EvfrQGR6SO gqnjYDJ9cEKNZfYBVbCRzQZxlG0BDwDKiKr1YKOacrDdxE8pT6tsK1ATV 9d2K4gjyN1NN0QPKWey8NOa/86uOnsEyx9pskXGvFRML4UXgqS8+z+9RI Q==; X-CSE-ConnectionGUID: /pYye/4hRP6FipCQ9YIWNg== X-CSE-MsgGUID: urUFDL6ITDejduE/58Js4A== X-IronPort-AV: E=McAfee;i="6700,10204,11268"; a="32642289" X-IronPort-AV: E=Sophos;i="6.12,189,1728975600"; d="scan'208";a="32642289" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Nov 2024 00:54:47 -0800 X-CSE-ConnectionGUID: gornYM1SR22nc/eA2n46mw== X-CSE-MsgGUID: L7UM9o2cQUaYxolxdRcCog== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.12,189,1728975600"; d="scan'208";a="91826973" Received: from klitkey1-mobl1.ger.corp.intel.com (HELO fedora..) ([10.245.246.103]) by orviesa009-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Nov 2024 00:54:44 -0800 From: =?utf-8?q?Thomas_Hellstr=C3=B6m?= To: intel-xe@lists.freedesktop.org Cc: =?utf-8?q?Thomas_Hellstr=C3=B6m?= , Peter Zijlstra , Ingo Molnar , Will Deacon , Waiman Long , Boqun Feng , Maarten Lankhorst , =?utf-8?q?Christian_K=C3=B6nig?= , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: [PATCH] locking/ww_mutex: Fix ww_mutex dummy lockdep map selftest warnings Date: Wed, 27 Nov 2024 09:54:30 +0100 Message-ID: <20241127085430.3045-1-thomas.hellstrom@linux.intel.com> X-Mailer: git-send-email 2.47.0 MIME-Version: 1.0 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" The below commit introduces a dummy lockdep map, but didn't get the initialization quite right (it should mimic the initialization of the real ww_mutex lockdep maps). It also introduced a separate locking api selftest failure. Fix these. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Will Deacon Cc: Waiman Long Cc: Boqun Feng Cc: Maarten Lankhorst Cc: Christian König Cc: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Suggested-by: Boqun Feng Reported-by: Boqun Feng Closes: https://lore.kernel.org/lkml/Zw19sMtnKdyOVQoh@boqun-archlinux/ Fixes: 823a566221a5 ("locking/ww_mutex: Adjust to lockdep nest_lock requirements") Signed-off-by: Thomas Hellström --- include/linux/ww_mutex.h | 4 ++-- lib/locking-selftest.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/include/linux/ww_mutex.h b/include/linux/ww_mutex.h index a401a2f31a77..45ff6f7a872b 100644 --- a/include/linux/ww_mutex.h +++ b/include/linux/ww_mutex.h @@ -156,8 +156,8 @@ static inline void ww_acquire_init(struct ww_acquire_ctx *ctx, debug_check_no_locks_freed((void *)ctx, sizeof(*ctx)); lockdep_init_map(&ctx->dep_map, ww_class->acquire_name, &ww_class->acquire_key, 0); - lockdep_init_map(&ctx->first_lock_dep_map, ww_class->mutex_name, - &ww_class->mutex_key, 0); + lockdep_init_map_wait(&ctx->first_lock_dep_map, ww_class->mutex_name, + &ww_class->mutex_key, 0, LD_WAIT_SLEEP); mutex_acquire(&ctx->dep_map, 0, 0, _RET_IP_); mutex_acquire_nest(&ctx->first_lock_dep_map, 0, 0, &ctx->dep_map, _RET_IP_); #endif diff --git a/lib/locking-selftest.c b/lib/locking-selftest.c index 6e0c019f71b6..ed99344317f5 100644 --- a/lib/locking-selftest.c +++ b/lib/locking-selftest.c @@ -1720,8 +1720,6 @@ static void ww_test_normal(void) { int ret; - WWAI(&t); - /* * None of the ww_mutex codepaths should be taken in the 'normal' * mutex calls. The easiest way to verify this is by using the @@ -1770,6 +1768,8 @@ static void ww_test_normal(void) ww_mutex_base_unlock(&o.base); WARN_ON(o.ctx != (void *)~0UL); + WWAI(&t); + /* nest_lock */ o.ctx = (void *)~0UL; ww_mutex_base_lock_nest_lock(&o.base, &t);