All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Marc Zyngier <maz@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>, Nishanth Menon <nm@ti.com>,
	"Dhruva Gole" <d-gole@ti.com>, Tero Kristo <kristo@kernel.org>,
	Santosh Shilimkar <ssantosh@kernel.org>,
	Logan Gunthorpe <logang@deltatee.com>,
	Dave Jiang <dave.jiang@intel.com>, Jon Mason <jdmason@kudzu.us>,
	Allen Hubbe <allenbh@gmail.com>, <ntb@lists.linux.dev>,
	Bjorn Helgaas <bhelgaas@google.com>, <linux-pci@vger.kernel.org>,
	Michael Kelley <mhklinux@outlook.com>,
	Wei Liu <wei.liu@kernel.org>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	<linux-hyperv@vger.kernel.org>, Wei Huang <wei.huang2@amd.com>,
	Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
	"James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	<linux-scsi@vger.kernel.org>,
	Jonathan Cameron <Jonathan.Cameron@huwei.com>
Subject: Re: [patch V2 01/10] cleanup: Provide retain_ptr()
Date: Thu, 13 Mar 2025 15:24:13 +0000	[thread overview]
Message-ID: <20250313152413.0000581b@huawei.com> (raw)
In-Reply-To: <20250313130321.442025758@linutronix.de>

On Thu, 13 Mar 2025 14:03:38 +0100 (CET)
Thomas Gleixner <tglx@linutronix.de> wrote:

> In cases where an allocation is consumed by another function, the
> allocation needs to be retained on success or freed on failure. The code
> pattern is usually:
> 
> 	struct foo *f = kzalloc(sizeof(*f), GFP_KERNEL);
> 	struct bar *b;
> 
> 	,,,
> 	// Initialize f
> 	...
> 	if (ret)
> 		goto free;
>         ...
> 	bar = bar_create(f);
> 	if (!bar) {
> 		ret = -ENOMEM;
> 	   	goto free;
> 	}
> 	...
> 	return 0;
> free:
> 	kfree(f);
> 	return ret;
> 
> This prevents using __free(kfree) on @f because there is no canonical way
> to tell the cleanup code that the allocation should not be freed.
> 
> Abusing no_free_ptr() by force ignoring the return value is not really a
> sensible option either.
> 
> Provide an explicit macro retain_ptr(), which NULLs the cleanup
> pointer. That makes it easy to analyze and reason about.
> 
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Cc: Peter Zijlstra <peterz@infradead.org>

Seems sensible to me and the resulting code is reasonably easy to
follow / contained in a small region.

Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

> ---
>  include/linux/cleanup.h |   17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> --- a/include/linux/cleanup.h
> +++ b/include/linux/cleanup.h
> @@ -216,6 +216,23 @@ const volatile void * __must_check_fn(co
>  
>  #define return_ptr(p)	return no_free_ptr(p)
>  
> +/*
> + * Only for situations where an allocation is handed in to another function
> + * and consumed by that function on success.
> + *
> + *	struct foo *f __free(kfree) = kzalloc(sizeof(*f), GFP_KERNEL);
> + *
> + *	setup(f);
> + *	if (some_condition)
> + *		return -EINVAL;
> + *	....
> + *	ret = bar(f);
> + *	if (!ret)
> + *		retain_ptr(f);
> + *	return ret;
> + */
> +#define retain_ptr(p)				\
> +	__get_and_null(p, NULL)
>  
>  /*
>   * DEFINE_CLASS(name, type, exit, init, init_args...):
> 


  reply	other threads:[~2025-03-13 15:24 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-13 13:03 [patch V2 00/10] genirq/msi: Spring cleaning Thomas Gleixner
2025-03-13 13:03 ` [patch V2 01/10] cleanup: Provide retain_ptr() Thomas Gleixner
2025-03-13 15:24   ` Jonathan Cameron [this message]
2025-03-14  9:37   ` Peter Zijlstra
2025-03-14 14:04   ` Frank Li
2025-03-13 13:03 ` [patch V2 02/10] genirq/msi: Use lock guards for MSI descriptor locking Thomas Gleixner
2025-03-13 15:26   ` Jonathan Cameron
2025-03-13 13:03 ` [patch V2 03/10] soc: ti: ti_sci_inta_msi: Switch MSI descriptor locking to guard() Thomas Gleixner
2025-03-13 13:03 ` [patch V2 04/10] NTB/msi: Switch MSI descriptor locking to lock guard() Thomas Gleixner
2025-03-13 13:03 ` [patch V2 05/10] PCI/MSI: Switch to MSI descriptor locking to guard() Thomas Gleixner
2025-03-13 15:50   ` Jonathan Cameron
2025-03-13 17:55     ` Thomas Gleixner
2025-03-14  9:42       ` Peter Zijlstra
2025-03-13 13:03 ` [patch V2 06/10] PCI: hv: Switch " Thomas Gleixner
2025-03-13 13:03 ` [patch V2 07/10] PCI/MSI: Provide a sane mechanism for TPH Thomas Gleixner
2025-03-13 13:03 ` [patch V2 08/10] PCI/TPH: Replace the broken MSI-X control word update Thomas Gleixner
2025-03-13 13:03 ` [patch V2 09/10] scsi: ufs: qcom: Remove the MSI descriptor abuse Thomas Gleixner
2025-03-28 10:00   ` Dan Carpenter
2025-03-28 14:05     ` Thomas Gleixner
2025-03-13 13:03 ` [patch V2 10/10] genirq/msi: Rename msi_[un]lock_descs() Thomas Gleixner

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=20250313152413.0000581b@huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=Jonathan.Cameron@huwei.com \
    --cc=allenbh@gmail.com \
    --cc=bhelgaas@google.com \
    --cc=d-gole@ti.com \
    --cc=dave.jiang@intel.com \
    --cc=haiyangz@microsoft.com \
    --cc=jdmason@kudzu.us \
    --cc=kristo@kernel.org \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=logang@deltatee.com \
    --cc=manivannan.sadhasivam@linaro.org \
    --cc=martin.petersen@oracle.com \
    --cc=maz@kernel.org \
    --cc=mhklinux@outlook.com \
    --cc=nm@ti.com \
    --cc=ntb@lists.linux.dev \
    --cc=peterz@infradead.org \
    --cc=ssantosh@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=wei.huang2@amd.com \
    --cc=wei.liu@kernel.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.