All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: <linux-cxl@vger.kernel.org>, <stable@vger.kernel.org>,
	Breno Leitao <leitao@debian.org>,
	Alison Schofield <alison.schofield@intel.com>,
	"Vishal Verma" <vishal.l.verma@intel.com>,
	<linux-acpi@vger.kernel.org>
Subject: Re: [PATCH] cxl/acpi: Fix load failures due to single window creation failure
Date: Mon, 26 Feb 2024 14:10:25 +0000	[thread overview]
Message-ID: <20240226141025.00001acf@Huawei.com> (raw)
In-Reply-To: <65da43d38df20_2bca029483@dwillia2-mobl3.amr.corp.intel.com.notmuch>

On Sat, 24 Feb 2024 11:30:27 -0800
Dan Williams <dan.j.williams@intel.com> wrote:

> Dan Williams wrote:
> > Dan Williams wrote:
> > [..]  
> > > > This is definitely not nice to read.  We are randomly setting an
> > > > apparently unrelated pointer to NULL.  At very least the __free
> > > > should operating on cxld then we can use  
> > 
> > So, how about this... I don't hate it:  
> 
> ...and the version that actually compiles, fixed up cxl_root_decoder
> declaration and dropped the BUILD_BUG_ON() since it will naturally fail
> to compile if more than the supported number of variables is passed to
> cond_no_free_ptr():
> 
> -- 8< --
> diff --git a/drivers/cxl/acpi.c b/drivers/cxl/acpi.c
> index 1a3e6aafbdcc..5c1dc4adf80d 100644
> --- a/drivers/cxl/acpi.c
> +++ b/drivers/cxl/acpi.c
> @@ -316,6 +316,8 @@ static const struct cxl_root_ops acpi_root_ops = {
>  	.qos_class = cxl_acpi_qos_class,
>  };
>  
> +DEFINE_FREE(put_cxlrd, struct cxl_root_decoder *,
> +	    if (!IS_ERR_OR_NULL(_T)) put_device(&_T->cxlsd.cxld.dev))
>  static int __cxl_parse_cfmws(struct acpi_cedt_cfmws *cfmws,
>  			     struct cxl_cfmws_context *ctx)
>  {
> @@ -323,21 +325,15 @@ static int __cxl_parse_cfmws(struct acpi_cedt_cfmws *cfmws,


>  	/* add to the local resource tracking to establish a sort order */
>  	rc = insert_resource(cxl_res, res);
> -	if (rc)
> -		goto err_insert;
> +	cond_no_free_ptr(rc == 0, return rc, res, name);

I'm not convinced this is that much clearer than
	rc = insert_resource(cxl_res, res);
	if (rc)
		return rc;
	no_check_no_free_ptrs(res);
	no_check_no_free_ptrs(name);

with better naming and with that being defined in similar way to your
__cond_no_free_ptrs()

Just keeping them in the same code block is probably enough to indicate
that these are there because of success of insert_resource()
+ no need to handle bigger and bigger sets of params in the future.


Rest looks good to me

Jonathan

 
	

...

> diff --git a/include/linux/cleanup.h b/include/linux/cleanup.h
> index c2d09bc4f976..e156fed88f51 100644
> --- a/include/linux/cleanup.h
> +++ b/include/linux/cleanup.h
> @@ -77,6 +77,28 @@ const volatile void * __must_check_fn(const volatile void *val)
>  
>  #define return_ptr(p)	return no_free_ptr(p)
>  
> +#define __cond_no_free_ptrs(p) ({__auto_type __always_unused __ptr = no_free_ptr(p);})

Nasty ;)

> +#define __cond_no_free_ptrs1(p, ...) __cond_no_free_ptrs(p)
> +#define __cond_no_free_ptrs2(p, ...) \
> +	__cond_no_free_ptrs(p), __cond_no_free_ptrs1(__VA_ARGS__)
> +#define __cond_no_free_ptrs3(p, ...) \
> +	__cond_no_free_ptrs(p), __cond_no_free_ptrs2(__VA_ARGS__)
> +
> +/*
> + * When an object is built up by an amalgamation of multiple allocations
> + * each of those need to be cleaned up on error, but there are occasions
> + * where once the object is registered all of those cleanups can be
> + * cancelled.  cond_no_free_ptr() arranges to call no_free_ptr() on all
> + * its arguments (up to 3) if @condition is true and runs @_fail
> + * otherwise (typically to return and trigger auto-cleanup).
> + */
> +#define cond_no_free_ptr(condition, _fail, ...)                           \
> +	if (condition) {                                                  \
> +		CONCATENATE(__cond_no_free_ptrs, COUNT_ARGS(__VA_ARGS__)) \
> +		(__VA_ARGS__);                                            \
> +	} else {                                                          \
> +		_fail;                                                    \
> +	}
>  
>  /*
>   * DEFINE_CLASS(name, type, exit, init, init_args...):


  reply	other threads:[~2024-02-26 14:10 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-17 20:29 [PATCH] cxl/acpi: Fix load failures due to single window creation failure Dan Williams
2024-02-19 12:40 ` Jonathan Cameron
2024-02-21 17:31   ` Dan Williams
2024-02-23 13:28     ` Jonathan Cameron
2024-02-23 19:14       ` Dan Williams
2024-02-24  6:07         ` Dan Williams
2024-02-24 19:30           ` Dan Williams
2024-02-26 14:10             ` Jonathan Cameron [this message]
2024-02-26 16:49               ` Dan Williams

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=20240226141025.00001acf@Huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=alison.schofield@intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=leitao@debian.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-cxl@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=vishal.l.verma@intel.com \
    /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.