Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp38477pxf; Wed, 17 Mar 2021 14:42:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwwZsDG+gUMYITh3uEWPjVJjKc6C13CE+U3BxmXjQd+8dnbv/BJTXxnBmUkxcSasuZ4FjIx X-Received: by 2002:a05:6402:c88:: with SMTP id cm8mr44471136edb.62.1616017374503; Wed, 17 Mar 2021 14:42:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616017374; cv=none; d=google.com; s=arc-20160816; b=x8o8MYjlt/On24rG5R7a7R+SVAcKg0SqKape4YpPnSpCo0EAv2UyRDsVrJjt/veBkr /UAypgr0eQtHcdkWC1G8UmZh6aR2318vFUyRNHSaOO8qfpw9OlxHVNy0emoOrabWssM0 xdYtXrRLoLEFtA0IGlTJW3vwOcFDCniljMUynJmHc2g2vZ1Zo4xdjvTR7XM9/xUuJE2r UclYudTjh6AMyKZo0K4vc/SGOoQ30PPfJXMLeSxoRBvfbRNxXuBAe1XWsPQLdlHLILtd mpg41xHH6R9Di+4V+CnjOP8SVBhaG63urxNYLvFZ3jFAY0KFx/pjItNb7J4YflajdHuY TFcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:message-id:organization :from:references:cc:to:subject:dkim-signature; bh=Pj0R5VrQedcfD5YEftKL4qdHxeZ+Ev/Ff2XmPsp8Sw4=; b=x6NeXmH6gTG9m/a+ok+ARzgDHX9kJbvxn17Hf76V0ezecoDMlPuhDfjnAS3Brh2m2D 0qx2FJTTvti2SC85rMD80nZfzBh4RjKKkFEi6mwO3EUokCR1rIS93A4LMSpk9oRWnk58 BQylHeCNRsHsaV+t0Q+86WjbHy5p8M3PJifrme0qneq57Tj8t2XmZQmDVtVX2AkT6OaO 6m4IUpAuHnxqAgVIywfHWPdPNnAvHBo/wDGxwgdx1MdhmuChTU1F97VZXafQkHELHmUm 7VM+Ywri+9PmXSRuy4PXjydElrNDqQstSBdaz2QTGSTS0rQDyM0NXKFTAxS1nNPH+xcG D+9g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=GRcdEdLL; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l19si58433eje.274.2021.03.17.14.42.31; Wed, 17 Mar 2021 14:42:54 -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; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=GRcdEdLL; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232920AbhCQScs (ORCPT + 99 others); Wed, 17 Mar 2021 14:32:48 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:42704 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232860AbhCQScc (ORCPT ); Wed, 17 Mar 2021 14:32:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1616005951; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Pj0R5VrQedcfD5YEftKL4qdHxeZ+Ev/Ff2XmPsp8Sw4=; b=GRcdEdLLpxhS3gqyKIn+SC0dtE7O2xFkhzhWcot/NCeun8opnSFX77/+yrWv3BzRwJx8In ETs7UhgH4ZqbgmJGRz7sRzTokJkyBnZkBTcnQ41hO8BRnHKXgZtTVKUO0FQqmdeQ1/QEwC wxNl/eya7ZKrW8TXaL+6/zR6SwYRxb4= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-219-1XAU-iLUOb-_ZtsCHaXK7w-1; Wed, 17 Mar 2021 14:32:29 -0400 X-MC-Unique: 1XAU-iLUOb-_ZtsCHaXK7w-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 20EA018C89C4; Wed, 17 Mar 2021 18:32:28 +0000 (UTC) Received: from llong.remote.csb (ovpn-117-171.rdu2.redhat.com [10.10.117.171]) by smtp.corp.redhat.com (Postfix) with ESMTP id 88EEE5D9C0; Wed, 17 Mar 2021 18:32:27 +0000 (UTC) Subject: Re: [tip: locking/urgent] locking/ww_mutex: Treat ww_mutex_lock() like a trylock To: Peter Zijlstra Cc: linux-kernel@vger.kernel.org, linux-tip-commits@vger.kernel.org, Ingo Molnar , x86@kernel.org References: <20210316153119.13802-4-longman@redhat.com> <161598470197.398.8903908266426306140.tip-bot2@tip-bot2> From: Waiman Long Organization: Red Hat Message-ID: <36d26109-f08a-6254-2fd3-ad1a28fcc260@redhat.com> Date: Wed, 17 Mar 2021 14:32:27 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/17/21 1:45 PM, Peter Zijlstra wrote: > On Wed, Mar 17, 2021 at 06:40:27PM +0100, Peter Zijlstra wrote: >> On Wed, Mar 17, 2021 at 05:48:48PM +0100, Peter Zijlstra wrote: >> >>> I think you'll find that if you use ww_mutex_init() it'll all work. Let >>> me go and zap this patch, and then I'll try and figure out why >>> DEFINE_WW_MUTEX() is buggered. >> Moo, I can't get the compiler to do as I want :/ >> >> The below is so close but doesn't actually compile.. Maybe we should >> just give up on DEFINE_WW_MUTEX and simply remove it. >> >> --- >> diff --git a/include/linux/mutex.h b/include/linux/mutex.h >> index 0cd631a19727..85f50538f26a 100644 >> --- a/include/linux/mutex.h >> +++ b/include/linux/mutex.h >> @@ -129,12 +129,15 @@ do { \ >> # define __DEP_MAP_MUTEX_INITIALIZER(lockname) >> #endif >> >> -#define __MUTEX_INITIALIZER(lockname) \ >> +#define ___MUTEX_INITIALIZER(lockname, depmap) \ >> { .owner = ATOMIC_LONG_INIT(0) \ >> , .wait_lock = __SPIN_LOCK_UNLOCKED(lockname.wait_lock) \ >> , .wait_list = LIST_HEAD_INIT(lockname.wait_list) \ >> __DEBUG_MUTEX_INITIALIZER(lockname) \ >> - __DEP_MAP_MUTEX_INITIALIZER(lockname) } >> + depmap } >> + >> +#define __MUTEX_INITIALIZER(lockname) \ >> + ___MUTEX_INITIALIZER(lockname, __DEP_MAP_MUTEX_INITIALIZER(lockname)) >> >> #define DEFINE_MUTEX(mutexname) \ >> struct mutex mutexname = __MUTEX_INITIALIZER(mutexname) >> diff --git a/include/linux/ww_mutex.h b/include/linux/ww_mutex.h >> index 6ecf2a0220db..c62a030652b4 100644 >> --- a/include/linux/ww_mutex.h >> +++ b/include/linux/ww_mutex.h >> @@ -50,9 +50,17 @@ struct ww_acquire_ctx { >> >> #ifdef CONFIG_DEBUG_LOCK_ALLOC >> # define __WW_CLASS_MUTEX_INITIALIZER(lockname, class) \ >> - , .ww_class = class >> + , .ww_class = &(class) >> + >> +# define __DEP_MAP_WW_MUTEX_INITIALIZER(lockname, class) \ >> + , .dep_map = { \ >> + .key = &(class).mutex_key, \ >> + .name = (class).mutex_name, \ > ,name = #class "_mutex", \ > > and it 'works', but shees! The name string itself may be duplicated for multiple instances of DEFINE_WW_MUTEX(). Do you want to keep DEFINE_WW_MUTEX() or just use ww_mutex_init() for all? I notice that the problem with DEFINE_WW_MUTEX is that the ww_mutex themselves has null key instead of the same key from the ww_class as with ww_mutex_init(). Cheers, Longman