All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Ben Levinsky" <ben.levinsky@amd.com>
Cc: Frank.Li@kernel.org, imx@lists.linux.dev,
	wsa+renesas@sang-engineering.com
Subject: Re: [PATCH v3 4/5] remoteproc: add helper for optional ELF resource tables
Date: Fri, 29 May 2026 04:31:23 +0000	[thread overview]
Message-ID: <20260529043124.30CA71F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260529021637.2077602-5-ben.levinsky@amd.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The macro `rproc_elf_load_rsc_table_optional` hides `return` statements inside a GNU C statement expression, forcing the caller to return immediately and creating dead code.
--

commit 97ca173b9ba2ed2c419cbe1a3f62d02db6f033c0
Author: Ben Levinsky <ben.levinsky@amd.com>

remoteproc: add helper for optional ELF resource tables

This commit introduces a helper macro around rproc_elf_load_rsc_table. It is
designed for drivers that treat a missing ELF resource table as optional while
allowing the caller to maintain local logging control.

> diff --git a/drivers/remoteproc/remoteproc_internal.h b/drivers/remoteproc/remoteproc_internal.h
> --- a/drivers/remoteproc/remoteproc_internal.h
> +++ b/drivers/remoteproc/remoteproc_internal.h
> @@ -149,6 +149,17 @@ static inline int rproc_mem_entry_iounmap(struct rproc *rproc,
>  	return 0;
>  }
>  
> +#define rproc_elf_load_rsc_table_optional(rproc, fw, dev_func, fmt, ...)	\
> +	({									\
> +		int ret = rproc_elf_load_rsc_table(rproc, fw);			\
> +		if (ret == -EINVAL) {						\
> +			dev_func(&rproc->dev, fmt, ##__VA_ARGS__);		\
> +			return 0;						\

[Severity: Medium]
Does this macro hide control flow in a way that forces the caller to return
unexpectedly?

Using explicit return statements inside a GNU C statement expression does not
yield a value to the expression itself. Instead, it forces the function
invoking the macro to return immediately.

If callers use this macro as though it evaluates to a return code, any trailing
statements in the caller will become unreachable dead code. Additionally, if a
calling function acquires a lock or allocates memory before using this macro,
the hidden return would skip the cleanup path and cause a resource leak.

Would it be safer to replace this macro with a standard inline function, or
change the statement expression to evaluate to the integer value rather than
forcing an explicit return?

> +		} else {							\
> +			return ret;						\
> +		}								\
> +	})

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260529021637.2077602-1-ben.levinsky@amd.com?part=4

  reply	other threads:[~2026-05-29  4:31 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-29  2:16 [PATCH v3 0/5] remoteproc: cleanup shared carveout and resource-table helpers Ben Levinsky
2026-05-29  2:16 ` [PATCH v3 1/5] remoteproc: add common wc-ioremap carveout callbacks Ben Levinsky
2026-05-29  2:51   ` sashiko-bot
2026-05-29  2:16 ` [PATCH v3 2/5] remoteproc: switch exact-match drivers to wc-ioremap callbacks Ben Levinsky
2026-05-29  3:34   ` sashiko-bot
2026-05-29  2:16 ` [PATCH v3 3/5] remoteproc: mark wc-ioremap carveouts as iomem Ben Levinsky
2026-05-29  4:16   ` sashiko-bot
2026-05-29  2:16 ` [PATCH v3 4/5] remoteproc: add helper for optional ELF resource tables Ben Levinsky
2026-05-29  4:31   ` sashiko-bot [this message]
2026-05-29  2:16 ` [PATCH v3 5/5] remoteproc: switch drivers to optional resource-table helper Ben Levinsky
2026-05-29  4:42   ` sashiko-bot
2026-05-29  8:42 ` [PATCH v3 0/5] remoteproc: cleanup shared carveout and resource-table helpers Wolfram Sang
2026-06-01 14:42 ` Mathieu Poirier
2026-06-06  3:43   ` Peng Fan

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=20260529043124.30CA71F00893@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=ben.levinsky@amd.com \
    --cc=imx@lists.linux.dev \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=wsa+renesas@sang-engineering.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.