Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp842770pxb; Fri, 22 Apr 2022 12:22:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwFuP20mUWLeoUDO5VI9WE2J8i4Bhgv42R+IyvzH0UIVWTbYc341ngPIwclonUYBi3hSPJJ X-Received: by 2002:a17:902:7d83:b0:158:c7e9:1ff3 with SMTP id a3-20020a1709027d8300b00158c7e91ff3mr6168600plm.55.1650655320731; Fri, 22 Apr 2022 12:22:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650655320; cv=none; d=google.com; s=arc-20160816; b=KMj9wC5WcflTDhKQo4t50plpB0kU2oWGVwaKMZait81e/AtD6qp7uGs6F3nkTxGytr vVwHeqc8ZwLcWGCXP0ecgOuhfc/pXspBResiC0dcCX1DZ//2uYwv4aTKv+uL0DFARUJ/ 9g3XE9yYRiRzvMMYEACJOfr6vvxJWStTMxa/OjZCHI8WLf46dWx0qd/MNpaQJ9eO73RP gp209hiascCfRQGzQbQXoc2tl8CMAz60ZB/zKP8DGxFp1RjlFyB0ra+lJA6x1ti6LdMm kVNL2VfS9B8faAUEbZFAaG9mAJ5u45xMtDOcTfiEMpg7sc4RBaHkNOn9kU87xH79l2lk kpzw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:message-id:date:cc:to:from:subject:dkim-signature; bh=jid1ertIY+kNLoBuDBFG3KQaMV1G0Zfd3tttC9KVfAg=; b=yB63IDzIc47l12bqe96e+B/7UvgAt8gjQOuTPCgaRAS+PSTlzGbPrDjcYbVlhpK6B/ SUNd5MjO8BnH35X4cik8JV4XHo0eXwtKSt+bYxfa32OuRCqEepWJZndXIv3LqWwKhgn3 tmQWSNWM6mMPdDOKoyQErYl7m7wpAiyepYohEXlISupeYK4C493u3cZQ++rqxf7C5VdF qTZzYn5WlikLYct28Q7SsY0D1zFdMdh7uPknaItSL/EERIID9ph6TV80li7xFmsdUX8V oPGUXgyU7UuHlX5dp5DvwLFElhs4llOBAX6fsC1c1BVS5YesKBTXMJT2eL8cPFwAVxQ5 OOPA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=MP27JmYe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id i1-20020a636d01000000b003816043f15bsi9827888pgc.848.2022.04.22.12.22.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Apr 2022 12:22:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=MP27JmYe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id AEFB68BF2B; Fri, 22 Apr 2022 11:35:12 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1390191AbiDUPja (ORCPT + 99 others); Thu, 21 Apr 2022 11:39:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35050 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1377040AbiDUPj0 (ORCPT ); Thu, 21 Apr 2022 11:39:26 -0400 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7B8DD47068; Thu, 21 Apr 2022 08:36:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1650555396; x=1682091396; h=subject:from:to:cc:date:message-id:mime-version: content-transfer-encoding; bh=HRjWqKMI48PJpBkmXwqNCKGbFsNs0ocG1yVkfojUm7A=; b=MP27JmYeuZWV0D/98q/TdozNiRDz+olBh5OH27YcnQy3zyiGRBJoWKuL iOpGyoTiO82+x4/hUXedCdIxVJ5DrA/7HV0y2u4k0gZe9fgcLCNSdAAhG oGuf88H/Zk0G3L8rCLhTfvaY0+0oTHGQGNT4B/sfkJZQ23IYBn0UuRNiT OkDaKnKJM1JFCA/9+cc8ZsG+LICU/lJtqW3U45HlWdWmXfOgvFIwvUu5r y2mksjxdH1QCavzknawXSyX1A5//LqysDYgLqFA4M9lECnboa9uDMM+fY Nd5N5FsD5sBKN2aR5qH+ssJue26i11Pvr6WcxPw392Jx/CCu+9YZQEnb1 Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10324"; a="264159909" X-IronPort-AV: E=Sophos;i="5.90,279,1643702400"; d="scan'208";a="264159909" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Apr 2022 08:33:08 -0700 X-IronPort-AV: E=Sophos;i="5.90,279,1643702400"; d="scan'208";a="593708723" Received: from dwillia2-desk3.jf.intel.com (HELO dwillia2-desk3.amr.corp.intel.com) ([10.54.39.25]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Apr 2022 08:33:08 -0700 Subject: [PATCH v3 0/8] device-core: Enable device_lock() lockdep validation From: Dan Williams To: linux-cxl@vger.kernel.org Cc: Ira Weiny , Ben Widawsky , Will Deacon , Jonathan Cameron , Vishal Verma , Dave Jiang , Alison Schofield , Boqun Feng , Ingo Molnar , Greg Kroah-Hartman , Peter Zijlstra , Waiman Long , "Rafael J. Wysocki" , nvdimm@lists.linux.dev, linux-kernel@vger.kernel.org Date: Thu, 21 Apr 2022 08:33:08 -0700 Message-ID: <165055518776.3745911.9346998911322224736.stgit@dwillia2-desk3.amr.corp.intel.com> User-Agent: StGit/0.18-3-g996c MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Changes since v2 [1] - Use lockdep_set_class(), lockdep_set_class_and_subclass(), and lock_set_class() instead of a 'lockdep_mutex' in 'struct device'. (Peter and Waiman) - Include a fix identifed by this new infrastructure [1]: https://lore.kernel.org/r/164982968798.684294.15817853329823976469.stgit@dwillia2-desk3.amr.corp.intel.com The device_lock() uses lockdep_set_novalidate_class() because it is taken in too many contexts that cannot be described by a single mutex lock class. The lack of lockdep coverage leads to deadlock scenarios landing upstream. To mitigate that problem the lockdep_mutex was added [2]. The lockdep_mutex, however, is an unscalable hack that overlooks advancements in the lockdep API to change a given lock's lock class [3]. With lockdep_set_class() a device subsystem can initialize a dedicated lock class per device type at device creation time, with lock_set_class() a device-driver can temporarily override a lockdep class after-the-fact. Use lockdep class assignment APIs to replace the usage of lockdep_mutex in the CXL and NVDIMM subsystems, and delete lockdep_mutex. [2]: commit 87a30e1f05d7 ("driver-core, libnvdimm: Let device subsystems add local lockdep coverage") [3]: https://lore.kernel.org/r/Ylf0dewci8myLvoW@hirez.programming.kicks-ass.net --- Dan Williams (8): cxl: Replace lockdep_mutex with local lock classes cxl/acpi: Add root device lockdep validation cxl: Drop cxl_device_lock() nvdimm: Replace lockdep_mutex with local lock classes ACPI: NFIT: Drop nfit_device_lock() nvdimm: Drop nd_device_lock() device-core: Kill the lockdep_mutex nvdimm: Fix firmware activation deadlock scenarios drivers/acpi/nfit/core.c | 30 ++++++++------- drivers/acpi/nfit/nfit.h | 24 ------------ drivers/base/core.c | 3 -- drivers/cxl/acpi.c | 15 ++++++++ drivers/cxl/core/memdev.c | 3 ++ drivers/cxl/core/pmem.c | 10 ++++- drivers/cxl/core/port.c | 68 ++++++++++++++++------------------ drivers/cxl/cxl.h | 78 --------------------------------------- drivers/cxl/mem.c | 4 +- drivers/cxl/pmem.c | 12 +++--- drivers/nvdimm/btt_devs.c | 23 +++++++----- drivers/nvdimm/bus.c | 38 ++++++++----------- drivers/nvdimm/core.c | 14 +++---- drivers/nvdimm/dax_devs.c | 4 +- drivers/nvdimm/dimm_devs.c | 12 ++++-- drivers/nvdimm/namespace_devs.c | 46 ++++++++++++++--------- drivers/nvdimm/nd-core.h | 68 +--------------------------------- drivers/nvdimm/pfn_devs.c | 31 +++++++++------- drivers/nvdimm/pmem.c | 2 + drivers/nvdimm/region.c | 2 + drivers/nvdimm/region_devs.c | 20 ++++++---- include/linux/device.h | 30 +++++++++++++-- lib/Kconfig.debug | 23 ------------ 23 files changed, 209 insertions(+), 351 deletions(-) base-commit: ce522ba9ef7e2d9fb22a39eb3371c0c64e2a433e