[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <202404241639.3F455ECCD@keescook>
Date: Wed, 24 Apr 2024 16:41:13 -0700
From: Kees Cook <keescook@...omium.org>
To: Abhinav Jain <jain.abhinav177@...il.com>
Cc: tony.luck@...el.com, gpiccoli@...lia.com,
linux-hardening@...r.kernel.org, linux-kernel@...r.kernel.org,
skhan@...uxfoundation.org, javier.carrasco.cruz@...il.com,
Julia Lawall <julia.lawall@...ia.fr>
Subject: Re: [PATCH] pstore/ram: Replace of_node_put with __free() for
automatic cleanup
On Mon, Apr 15, 2024 at 04:14:09PM +0000, Abhinav Jain wrote:
> Add __free(device_node) to the parent_node struct declaration.
> Move declaration to initialization for ensuring scope sanity.
> Remove of_node_put from parent_node struct.
>
> Suggested-by: Julia Lawall <julia.lawall@...ia.fr>
> Signed-off-by: Abhinav Jain <jain.abhinav177@...il.com>
> ---
> fs/pstore/ram.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
> index b1a455f42e93..14f2f4864e48 100644
> --- a/fs/pstore/ram.c
> +++ b/fs/pstore/ram.c
> @@ -644,7 +644,6 @@ static int ramoops_parse_dt(struct platform_device *pdev,
> struct ramoops_platform_data *pdata)
> {
> struct device_node *of_node = pdev->dev.of_node;
> - struct device_node *parent_node;
> struct resource *res;
> u32 value;
> int ret;
> @@ -704,14 +703,13 @@ static int ramoops_parse_dt(struct platform_device *pdev,
> * we're not a child of "reserved-memory" and mimicking the
> * expected behavior.
> */
> - parent_node = of_get_parent(of_node);
> + struct device_node *parent_node __free(device_node) = of_node_parent(of_node);
Please don't move variable definitions into the middle of the function
body. :)
> if (!of_node_name_eq(parent_node, "reserved-memory") &&
> !pdata->console_size && !pdata->ftrace_size &&
> !pdata->pmsg_size && !pdata->ecc_info.ecc_size) {
> pdata->console_size = pdata->record_size;
> pdata->pmsg_size = pdata->record_size;
> }
> - of_node_put(parent_node);
So this change is functionally fine, but there's really no good reason
to do this -- there is no fancy error handling here, so there's no
benefit to making this change. It doesn't really help readability.
-Kees
>
> return 0;
> }
> --
> 2.34.1
>
--
Kees Cook
Powered by blists - more mailing lists