All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
To: Erick Karanja <karanja99erick@gmail.com>
Cc: <manivannan.sadhasivam@linaro.org>, <kw@linux.com>,
	<kishon@kernel.org>, <bhelgaas@google.com>,
	<linux-pci@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<julia.lawall@inria.fr>
Subject: Re: [PATCH 2/2] PCI: endpoint: Use scoped_guard for manual mutex lock/unlock
Date: Fri, 2 May 2025 09:43:13 +0100	[thread overview]
Message-ID: <20250502094313.000055d1@huawei.com> (raw)
In-Reply-To: <88bf352aab2b3ba68b2381b23706513e4cdea155.1746114596.git.karanja99erick@gmail.com>

On Thu,  1 May 2025 18:56:12 +0300
Erick Karanja <karanja99erick@gmail.com> wrote:

> This refactor replaces manual mutex lock/unlock with scoped_guard()
> in places where early exits use goto. Using scoped_guard()
> avoids error-prone unlock paths and simplifies control flow.
> 
> Signed-off-by: Erick Karanja <karanja99erick@gmail.com>
> ---
>  drivers/pci/endpoint/pci-epc-core.c | 53 +++++++++++++----------------
>  1 file changed, 24 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/pci/endpoint/pci-epc-core.c b/drivers/pci/endpoint/pci-epc-core.c
> index beabea00af91..3f3ff36fa8ab 100644
> --- a/drivers/pci/endpoint/pci-epc-core.c
> +++ b/drivers/pci/endpoint/pci-epc-core.c
> @@ -709,7 +709,6 @@ int pci_epc_add_epf(struct pci_epc *epc, struct pci_epf *epf,
>  {
>  	struct list_head *list;
>  	u32 func_no;
> -	int ret = 0;
>  
>  	if (IS_ERR_OR_NULL(epc) || epf->is_vf)
>  		return -EINVAL;
> @@ -720,36 +719,32 @@ int pci_epc_add_epf(struct pci_epc *epc, struct pci_epf *epf,
>  	if (type == SECONDARY_INTERFACE && epf->sec_epc)
>  		return -EBUSY;
>  
> -	mutex_lock(&epc->list_lock);
> -	func_no = find_first_zero_bit(&epc->function_num_map,
> -				      BITS_PER_LONG);
> -	if (func_no >= BITS_PER_LONG) {
> -		ret = -EINVAL;
> -		goto ret;
> -	}
> -
> -	if (func_no > epc->max_functions - 1) {
> -		dev_err(&epc->dev, "Exceeding max supported Function Number\n");
> -		ret = -EINVAL;
> -		goto ret;
> +	scoped_guard(mutex, &epc->list_lock) {
This one is better, but using
	guard(mutex)(&epc->list_lock);
Is going to make for an easier to read patch and lower indent etc.

Unless there is some subsystem related reason that scoped_guard() is
preferred then I'd go that way.

> +		func_no = find_first_zero_bit(&epc->function_num_map,
> +					      BITS_PER_LONG);
> +		if (func_no >= BITS_PER_LONG)
> +			return -EINVAL;
> +
> +		if (func_no > epc->max_functions - 1) {
> +			dev_err(&epc->dev, "Exceeding max supported Function Number\n");
> +			return -EINVAL;
> +		}
> +
> +		set_bit(func_no, &epc->function_num_map);
> +		if (type == PRIMARY_INTERFACE) {
> +			epf->func_no = func_no;
> +			epf->epc = epc;
> +			list = &epf->list;
> +		} else {
> +			epf->sec_epc_func_no = func_no;
> +			epf->sec_epc = epc;
> +			list = &epf->sec_epc_list;
> +		}
> +
> +		list_add_tail(list, &epc->pci_epf);
>  	}
>  
> -	set_bit(func_no, &epc->function_num_map);
> -	if (type == PRIMARY_INTERFACE) {
> -		epf->func_no = func_no;
> -		epf->epc = epc;
> -		list = &epf->list;
> -	} else {
> -		epf->sec_epc_func_no = func_no;
> -		epf->sec_epc = epc;
> -		list = &epf->sec_epc_list;
> -	}
> -
> -	list_add_tail(list, &epc->pci_epf);
> -ret:
> -	mutex_unlock(&epc->list_lock);
> -
> -	return ret;
> +	return 0;
>  }
>  EXPORT_SYMBOL_GPL(pci_epc_add_epf);
>  


      reply	other threads:[~2025-05-02  8:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-01 15:56 [PATCH 0/2] Use scoped_guard to safely manage mutex locking Erick Karanja
2025-05-01 15:56 ` [PATCH 1/2] PCI: endpoint: Replace manual mutex handling with scoped_guard() Erick Karanja
2025-05-02  8:41   ` Jonathan Cameron
2025-05-01 15:56 ` [PATCH 2/2] PCI: endpoint: Use scoped_guard for manual mutex lock/unlock Erick Karanja
2025-05-02  8:43   ` Jonathan Cameron [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250502094313.000055d1@huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=bhelgaas@google.com \
    --cc=julia.lawall@inria.fr \
    --cc=karanja99erick@gmail.com \
    --cc=kishon@kernel.org \
    --cc=kw@linux.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=manivannan.sadhasivam@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.