Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp7986820rdb; Thu, 4 Jan 2024 14:37:37 -0800 (PST) X-Google-Smtp-Source: AGHT+IFYFLiUQeukVWL81GUemyvzBZkJkPxwQZHTeItRguZ/EVb7LQ0hk+Psxt1wGMOgUCkDH8ej X-Received: by 2002:a81:5d43:0:b0:5f3:2c5e:462f with SMTP id r64-20020a815d43000000b005f32c5e462fmr1381786ywb.51.1704407857031; Thu, 04 Jan 2024 14:37:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704407857; cv=none; d=google.com; s=arc-20160816; b=nGWft2VO3a3V8ga9Bh/KCFy8H9MIQGQN1QSkQBFmOZppwtoehCo5A/ixaRDZcwRw5g nPDKGADoIKwsDSqSMOGU7/0aBHjg7y/ZQKD38HORDCUn5G1oi1CFMj/XuG159Hgyu00f JRGuqZRJlnVQTjtf+ocH0VFx60EjnOuAb1qrrfHdL1+168HlnLaS2y4dwb6VJJurTreI eHhWW2ttHqN0pwDxb1QjWrTLr4W8vW65Kah4tIuFcmyfGtDcK5ph+Mj5z8/T5j1hc5ke 1jRD1HpS3f0KyzR0GIm8QM5RcRRVwPS44cPDSjfBYaA+hxi1Cnko90iPHfWP/LAIzHUQ qioQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:subject:cc:to:from :date:dkim-signature; bh=ant7DzbmdPqCcmNmBqZNNbjeRfXF/aL7EWfKx72Saj8=; fh=g/iP2p71unbpPM2Dv7rT3yLErGYZSLwT5tXeKvia+yw=; b=ecAHq/0Mm/cTfLNih6cPPwnr/umo3ffd0LtgqMofZ8x4oO5KQ1IFd1pBAirJSKQnvm TG0vYc390eEKTFiwsNdP451PYyJmnsGKFTRj/n90hUiqlWY9UKhJvjxaG0ebZnib/qUR KYFwAkTLMpvOLjepHQQpsP9I33n5AjLY4zbGaq9776FvzJQ+2+CfTlzjNHtUWsiH7v+r ep+BPdWZcEiyMKPxsQPphYPDgzzemSqaJ61c4DAX5Rw0e3D1Drg8kDvKqLguDW7pJVu4 ZI9/ml55GRsqPwS+fEac9zL705c6xbt8mPP26df2exUMsX0n017VH2HH9Tny2iCIz5Dm H9IQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="ScnU/miw"; spf=pass (google.com: domain of linux-kernel+bounces-17289-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-17289-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id h17-20020ac87d51000000b0042832637e20si503886qtb.240.2024.01.04.14.37.36 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Jan 2024 14:37:37 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-17289-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="ScnU/miw"; spf=pass (google.com: domain of linux-kernel+bounces-17289-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-17289-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id C514D1C225D6 for ; Thu, 4 Jan 2024 22:37:36 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 6A4AB2C866; Thu, 4 Jan 2024 22:37:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ScnU/miw" X-Original-To: linux-kernel@vger.kernel.org Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9141D2C6A6; Thu, 4 Jan 2024 22:37:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DCDACC433C7; Thu, 4 Jan 2024 22:37:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1704407847; bh=02xdEvkQgxl0QgYG12fhILXcS05r5JkyWJF03KY5he4=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=ScnU/miwdyVdmnQmUzdZjXLnbm15i7VEprvnkOTjtX5Al9T7AYsa7YgmbPx5nvJFc GEueXE2WQxaJXM7k20zgCUnVgMkXS8mEU9lTp2tdw+pOq0CblbrOMB+UyNwZoy1Ifs 2dzwv+SdihVFpfz9+LIyqki5krAbyzeyel2w/XTbyoc0HC6B1+tvRSjZkfVAbNQzxC NZQFAVEOwbbGersZbL/sWe13DsS7BzJhhL5KiFhpnTOmSbUWbmTChbzQJ4QkTeYwJY pr48rtHHAOJfA+yt2gNS4WnRGY8oDGkZmUXHVgtSThtdgticui7BVn52DABqJ3B104 6M7Y46I85QToA== Date: Thu, 4 Jan 2024 16:37:25 -0600 From: Bjorn Helgaas To: Ira Weiny Cc: Dan Williams , Bjorn Helgaas , Jonathan Cameron , Smita Koralahalli , Shiju Jose , Yazen Ghannam , Davidlohr Bueso , Dave Jiang , Alison Schofield , Vishal Verma , Ard Biesheuvel , linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, linux-cxl@vger.kernel.org, linux-pci@vger.kernel.org Subject: Re: [PATCH v5 8/9] PCI: Define scoped based management functions Message-ID: <20240104223725.GA1829769@bhelgaas> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6597275045fbf_267e82949d@iweiny-mobl.notmuch> On Thu, Jan 04, 2024 at 01:46:56PM -0800, Ira Weiny wrote: > Dan Williams wrote: > > Bjorn Helgaas wrote: > > [..] > > > > --- > > > > PCI: Introduce cleanup helpers for device reference counts and locks > > > > > > > > The "goto error" pattern is notorious for introducing subtle resource > > > > leaks. Use the new cleanup.h helpers for PCI device reference counts and > > > > locks. > > > > > > > > Similar to the new put_device() and device_lock() cleanup helpers, > > > > __free(put_device) and guard(device), define the same for PCI devices, > > > > __free(pci_dev_put) and guard(pci_dev). These helpers eliminate the > > > > need for "goto free;" and "goto unlock;" patterns. For example, A > > > > 'struct pci_dev *' instance declared as: > > > > > > > > struct pci_dev *pdev __free(pci_dev_put) = NULL; > > > > > > I see several similar __free() uses with NULL initializations in gpio, > > > but I think this idiom would be slightly improved if the __free() > > > function were more closely associated with the actual pci_dev_get(): > > > > > > struct pci_dev *pdev __free(pci_dev_put) = pci_get_device(...); > > > > > > Not always possible, I know, but easier to analyze when it is. > > > > I tend to agree, but it does lead to some long lines, for example: > > > > diff --git a/drivers/cxl/pci.c b/drivers/cxl/pci.c > > index 4fd1f207c84e..549ba4b8294e 100644 > > --- a/drivers/cxl/pci.c > > +++ b/drivers/cxl/pci.c > > @@ -975,15 +975,14 @@ static void cxl_cper_event_call(enum cxl_event_type ev_type, > > struct cxl_cper_event_rec *rec) > > { > > struct cper_cxl_event_devid *device_id = &rec->hdr.device_id; > > - struct pci_dev *pdev __free(pci_dev_put) = NULL; > > enum cxl_event_log_type log_type; > > struct cxl_dev_state *cxlds; > > unsigned int devfn; > > u32 hdr_flags; > > > > devfn = PCI_DEVFN(device_id->device_num, device_id->func_num); > > - pdev = pci_get_domain_bus_and_slot(device_id->segment_num, > > - device_id->bus_num, devfn); > > + struct pci_dev *pdev __free(pci_dev_put) = pci_get_domain_bus_and_slot( > > + device_id->segment_num, device_id->bus_num, devfn); > > if (!pdev) > > return; > > > > ...so I think people are choosing the "... __free(x) = NULL;" style for > > code density readability. > > > > Also in this case we need devfn assigned first. > > Is the above patch compliant with current style guidelines? > > Or would it be better to do? > > diff --git a/drivers/cxl/pci.c b/drivers/cxl/pci.c > index b14237f824cf..8a180c6abb67 100644 > --- a/drivers/cxl/pci.c > +++ b/drivers/cxl/pci.c > @@ -975,15 +975,14 @@ static void cxl_cper_event_call(enum cxl_event_type ev_type, > struct cxl_cper_event_rec *rec) > { > struct cper_cxl_event_devid *device_id = &rec->hdr.device_id; > - struct pci_dev *pdev __free(pci_dev_put) = NULL; > enum cxl_event_log_type log_type; > struct cxl_dev_state *cxlds; > - unsigned int devfn; > + unsigned int devfn = PCI_DEVFN(device_id->device_num, device_id->func_num); > + struct pci_dev *pdev __free(pci_dev_put) = pci_get_domain_bus_and_slot( > + device_id->segment_num, > + device_id->bus_num, devfn); I don't really care about this specific instance; my comment was more about the commit log for the "Define scope based management functions" patch, thinking maybe the example could encourage get/put togetherness when it's practical. Bjorn