From patchwork Wed Dec 13 23:02:35 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dan Williams X-Patchwork-Id: 178342 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:3b04:b0:fb:cd0c:d3e with SMTP id c4csp8148264dys; Wed, 13 Dec 2023 15:02:45 -0800 (PST) X-Google-Smtp-Source: AGHT+IGCEILhn5XxZ/3AWCQgDLndcsn34Qo3TM3oqbPB4z1TIWOHrTzDBWDXWUuDJXm7yAV2d7it X-Received: by 2002:a17:90a:af98:b0:28a:7a68:d08f with SMTP id w24-20020a17090aaf9800b0028a7a68d08fmr3474346pjq.97.1702508564933; Wed, 13 Dec 2023 15:02:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702508564; cv=none; d=google.com; s=arc-20160816; b=W+TKAKFkPOz2dDmrYxiZMmZvUqO3qwGiCaY9TMAhslv1gYmJYDlJzaKcoQk/Oaw+ff ldpH9UU0bE53XWdjexO5nOp7JF8LwXGos9uCEqpaXDt2mG08RurW6V3iuKgbYa72tNlj wUr5v5PoaXhZja5eH8nYpaxyY3q1AaW+LQBiP1i0GrEynSFzhnu8W4vH1lwu5TS0QPOw 9k1FSRQSlxTmyiGEfy5nvs7gkhuuDf7Dor+EDcMq84STtzSNPWYYz7wdqj+26FsdwCoe VuMbdPUei7EnmqZUJRM/ghRbVfivUYQv79kBnTw8fQzICXNvdPFLoozytnz6ZHDk1bW0 uQmA== 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=49Ui/pz3TVYziDydJLnevL3lo9vDRUX005JOhRBY5Ns=; fh=8Un1MynqdcDKC9Akn5WOUn0sdk2WvA8vH/SisW5paCI=; b=pwTCkjsz4xvn54P3Sd0kVoFnz5hyvZy+pescB0FV3Uw50CHOD6R8AMFSWUvwK/0Tsg yPphaKRu2yl8erjTwlI995Az1eLMHr3FuqcyHXZLv6BJVVyBXD6sheJRkJ/KVd8AuIPP N3u9uRn4N9/C5jAEMnpnkCDKsgIBA56jS9Ji+RrqwUInGJtOkfk3ixnygl+xlaivAOWI CiuM1qAFoz4jkZ6Z1SadDRw/JDASd3ntjyfFicIuLfDxWWdwTseJAfZjqEKXjwnGG8gc tLk81W39cqlCnblqFN+apm/9KPv9OIX8MgQPWN/4Qd1TXTc6JlvqAG5krVFFVYGv6VQi uIYg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=QiA1c+AR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 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 snail.vger.email (snail.vger.email. [2620:137:e000::3:7]) by mx.google.com with ESMTPS id kx16-20020a17090b229000b0028865aca280si11224623pjb.189.2023.12.13.15.02.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Dec 2023 15:02:44 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=QiA1c+AR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 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 out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id EFF85802D51C; Wed, 13 Dec 2023 15:02:43 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229835AbjLMXCc (ORCPT + 99 others); Wed, 13 Dec 2023 18:02:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34910 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229763AbjLMXCa (ORCPT ); Wed, 13 Dec 2023 18:02:30 -0500 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.10]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D678599; Wed, 13 Dec 2023 15:02:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1702508557; x=1734044557; h=subject:from:to:cc:date:message-id:mime-version: content-transfer-encoding; bh=E7M26yPTY6+vjqYd5Bj0fpUoHUYe+VEtT6WJdnLb2Gg=; b=QiA1c+ARNSf64K2IW/hpuCI7QIOjYBBUA0yJpBJekWk3BmcvqEh+5Z28 GRi9e6Ys94QQJlED+G4ZxFRgR6wNVKrZ6oEgdG+eJMWIW0FHYOw0emN/S McjSKhevmG52Y9diI6CHc+0goSz8C3enhSWDI+jRDC/t4OQFijye3e/Q0 0NTIZ9XWuPQuaFJyZdSDiLV5SlPV4e1RlNSjCLTkIoPmk70xAKkeBbv0l ZMyyfR/pRfKITk/u6MTd+OZwN0WuFfY6JvfwuIkN/lai7l1gWBF8eVgIk NMqzZUbYV8V9JySq/JDtTjwC0Cjl82FACN9UJZCwfXSxEn4dFhyUsYtYi w==; X-IronPort-AV: E=McAfee;i="6600,9927,10923"; a="2210629" X-IronPort-AV: E=Sophos;i="6.04,274,1695711600"; d="scan'208";a="2210629" Received: from fmviesa001.fm.intel.com ([10.60.135.141]) by fmvoesa104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Dec 2023 15:02:37 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.04,274,1695711600"; d="scan'208";a="17692849" Received: from wardsamx-mobl.amr.corp.intel.com (HELO dwillia2-xfh.jf.intel.com) ([10.209.81.197]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Dec 2023 15:02:36 -0800 Subject: [PATCH] driver core: Add a guard() definition for the device_lock() From: Dan Williams To: gregkh@linuxfoundation.org Cc: Vishal Verma , Ira Weiny , Peter Zijlstra , Andrew Morton , linux-kernel@vger.kernel.org, linux-cxl@vger.kernel.org, nvdimm@lists.linux.dev Date: Wed, 13 Dec 2023 15:02:35 -0800 Message-ID: <170250854466.1522182.17555361077409628655.stgit@dwillia2-xfh.jf.intel.com> User-Agent: StGit/0.18-3-g996c MIME-Version: 1.0 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham 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 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Wed, 13 Dec 2023 15:02:44 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1785209620962918939 X-GMAIL-MSGID: 1785209620962918939 At present there are ~200 usages of device_lock() in the kernel. Some of those usages lead to "goto unlock;" patterns which have proven to be error prone. Define a "device" guard() definition to allow for those to be cleaned up and prevent new ones from appearing. Link: http://lore.kernel.org/r/657897453dda8_269bd29492@dwillia2-mobl3.amr.corp.intel.com.notmuch Link: http://lore.kernel.org/r/6577b0c2a02df_a04c5294bb@dwillia2-xfh.jf.intel.com.notmuch Cc: Vishal Verma Cc: Ira Weiny Cc: Peter Zijlstra Cc: Greg Kroah-Hartman Cc: Andrew Morton Signed-off-by: Dan Williams Reviewed-by: Ira Weiny Reviewed-by: Vishal Verma Reviewed-by: Dave Jiang --- Hi Greg, I wonder if you might include this change in v6.7-rc to ease some patch sets alternately going through my tree and Andrew's tree. Those discussions are linked above. Alternately I can can just take it through my tree with your ack and the other use case can circle back to it in the v6.9 cycle. I considered also defining a __free() helper similar to __free(mutex), but I think "__free(device)" would be a surprising name for something that drops a lock. Also, I like the syntax of guard(device) over something like guard(device_lock) since a 'struct device *' is the argument, not a lock type, but I'm open to your or Peter's thoughts on the naming. include/linux/device.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/device.h b/include/linux/device.h index d7a72a8749ea..6c83294395ac 100644 --- a/include/linux/device.h +++ b/include/linux/device.h @@ -1007,6 +1007,8 @@ static inline void device_unlock(struct device *dev) mutex_unlock(&dev->mutex); } +DEFINE_GUARD(device, struct device *, device_lock(_T), device_unlock(_T)) + static inline void device_lock_assert(struct device *dev) { lockdep_assert_held(&dev->mutex);