devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Clément Léger" <clement.leger@bootlin.com>
To: Rob Herring <robh@kernel.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Frank Rowand <frowand.list@gmail.com>,
	Nathan Lynch <nathanl@linux.ibm.com>,
	Laurent Dufour <ldufour@linux.ibm.com>,
	Daniel Henrique Barboza <danielhb413@gmail.com>,
	David Gibson <david@gibson.dropbear.id.au>,
	Andrew Morton <akpm@linux-foundation.org>,
	David Hildenbrand <david@redhat.com>,
	Ohhoon Kwon <ohoono.kwon@samsung.com>,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
	YueHaibing <yuehaibing@huawei.com>,
	linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	devicetree@vger.kernel.org,
	Allan Nielsen <allan.nielsen@microchip.com>,
	Horatiu Vultur <horatiu.vultur@microchip.com>,
	Steen Hegelund <steen.hegelund@microchip.com>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Bjorn Helgaas <helgaas@kernel.org>,
	Lizhi Hou <lizhi.hou@xilinx.com>
Subject: Re: [PATCH v2 4/4] powerpc/pseries: use of_property_alloc/free() and of_node_alloc()
Date: Mon, 6 Jun 2022 10:45:31 +0200	[thread overview]
Message-ID: <20220606104531.6ec997ef@fixe.home> (raw)
In-Reply-To: <20220603201407.GA688883-robh@kernel.org>

Le Fri, 3 Jun 2022 15:14:07 -0500,
Rob Herring <robh@kernel.org> a écrit :

> >  static struct device_node *dlpar_parse_cc_node(struct cc_workarea *ccwa)
> >  {
> > -	struct device_node *dn;
> >  	const char *name;
> >  
> > -	dn = kzalloc(sizeof(*dn), GFP_KERNEL);
> > -	if (!dn)
> > -		return NULL;
> > -
> >  	name = (const char *)ccwa + be32_to_cpu(ccwa->name_offset);
> > -	dn->full_name = kstrdup(name, GFP_KERNEL);
> > -	if (!dn->full_name) {
> > -		kfree(dn);
> > -		return NULL;
> > -	}
> >  
> > -	of_node_set_flag(dn, OF_DYNAMIC);
> > -	of_node_init(dn);
> > -
> > -	return dn;
> > +	return of_node_alloc(name, GFP_KERNEL);  
> 
> Do you have any need for different flags? I can't really see a need for 
> atomic or dma allocs or ???, so drop it I think.

Hum no, i copied this behavior from an existing function. I'll remove
that.

> 
> >  }
> >  
> >  static void dlpar_free_one_cc_node(struct device_node *dn)
> > @@ -102,11 +66,10 @@ static void dlpar_free_one_cc_node(struct device_node *dn)
> >  	while (dn->properties) {
> >  		prop = dn->properties;
> >  		dn->properties = prop->next;
> > -		dlpar_free_cc_property(prop);
> > +		of_property_free(prop);  
> 
> We should be able to just put the node and all the properties already 
> attached will be freed.

Indeed !

> 
> Looking at the history of this code, it originally did the kref_init 
> much later in dlpar_attach_node(). So there was a window of allocating 
> the node and adding properties where you'd need to manually free 
> everything. Now that the node is referenced from the start, a put should 
> free everything.
> 
> > @@ -91,9 +82,7 @@ static void release_prop_list(const struct property *prop)
> >  	struct property *next;
> >  	for (; prop; prop = next) {
> >  		next = prop->next;
> > -		kfree(prop->name);
> > -		kfree(prop->value);
> > -		kfree(prop);
> > +		of_property_free(prop);  
> 
> Looks like you need this because code does: alloc properties, alloc 
> node, add properties, attach node. It would need to be refactored to 
> alloc the node first, but that's a bit more complex needing someone to 
> test on pSeries.

Acked.

> 
> >  	}
> >  
> >  }
> > @@ -167,27 +156,17 @@ static char * parse_next_property(char *buf, char *end, char **name, int *length
> >  static struct property *new_property(const char *name, const int length,
> >  				     const unsigned char *value, struct property *last)
> >  {
> > -	struct property *new = kzalloc(sizeof(*new), GFP_KERNEL);
> > +	struct property *prop;
> >  
> > -	if (!new)
> > +	prop = of_property_alloc(name, NULL, length + 1, GFP_KERNEL);
> > +	if (!prop)
> >  		return NULL;
> >  
> > -	if (!(new->name = kstrdup(name, GFP_KERNEL)))
> > -		goto cleanup;
> > -	if (!(new->value = kmalloc(length + 1, GFP_KERNEL)))
> > -		goto cleanup;
> > -
> > -	memcpy(new->value, value, length);
> > -	*(((char *)new->value) + length) = 0;
> > -	new->length = length;
> > -	new->next = last;
> > -	return new;
> > -
> > -cleanup:
> > -	kfree(new->name);
> > -	kfree(new->value);
> > -	kfree(new);
> > -	return NULL;
> > +	memcpy(prop->value, value, length);
> > +	*(((char *)prop->value) + length) = 0;  
> 
> Looks to me like this could be avoided with this change:
> 
> diff --git a/arch/powerpc/platforms/pseries/reconfig.c b/arch/powerpc/platforms/pseries/reconfig.c
> index cad7a0c93117..614753fc5f27 100644
> --- a/arch/powerpc/platforms/pseries/reconfig.c
> +++ b/arch/powerpc/platforms/pseries/reconfig.c
> @@ -148,7 +148,7 @@ static char * parse_next_property(char *buf, char *end, char **name, int *length
>         /* now we're on the value */
>         *value = tmp;
>         tmp += *length;
> -       if (tmp > end) {
> +       if (tmp >= end) {
>                 printk(KERN_ERR "property parse failed in %s at line %d\n",
>                        __func__, __LINE__);
>                 return NULL;
> @@ -158,6 +158,7 @@ static char * parse_next_property(char *buf, char *end, char **name, int *length
>                        __func__, __LINE__);
>                 return NULL;
>         }
> +       *tmp = '\0';
>         tmp++;
>  
>         /* and now we should be on the next name, or the end */
> 
> 
> Based on the comments, 'buf' should be nul terminated, so I would think 
> that tmp == end would be an error. But I really don't know.
> 
> Really need some pSeries people to comment on all this.
> 
> Another option is if value is NULL, then of_property_alloc() should 
> ensure the buffer is zeroed. Then you just need the memcpy.

Probably looks like a safe behavior anyway to zero the value buffer.
I'll add that.

Thanks,

Clément

> 
> Rob



-- 
Clément Léger,
Embedded Linux and Kernel engineer at Bootlin
https://bootlin.com

      reply	other threads:[~2022-06-06  8:50 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-01  8:17 [PATCH v2 0/4] of: add of_property_alloc/free() and of_node_alloc() Clément Léger
2022-06-01  8:17 ` [PATCH v2 1/4] of: constify of_property_check_flags() prop argument Clément Léger
2022-06-03 20:24   ` Rob Herring
2022-06-01  8:17 ` [PATCH v2 2/4] of: dynamic: add of_property_alloc() and of_property_free() Clément Léger
2022-06-01 22:32   ` Tyrel Datwyler
2022-06-02  6:58     ` Clément Léger
2022-06-02 18:10       ` Tyrel Datwyler
2022-06-01  8:18 ` [PATCH v2 3/4] of: dynamic: add of_node_alloc() Clément Léger
2022-06-01  8:18 ` [PATCH v2 4/4] powerpc/pseries: use of_property_alloc/free() and of_node_alloc() Clément Léger
2022-06-03 20:14   ` Rob Herring
2022-06-06  8:45     ` Clément Léger [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=20220606104531.6ec997ef@fixe.home \
    --to=clement.leger@bootlin.com \
    --cc=akpm@linux-foundation.org \
    --cc=allan.nielsen@microchip.com \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=danielhb413@gmail.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=david@redhat.com \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=helgaas@kernel.org \
    --cc=horatiu.vultur@microchip.com \
    --cc=ldufour@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=lizhi.hou@xilinx.com \
    --cc=mpe@ellerman.id.au \
    --cc=nathanl@linux.ibm.com \
    --cc=ohoono.kwon@samsung.com \
    --cc=paulus@samba.org \
    --cc=robh@kernel.org \
    --cc=steen.hegelund@microchip.com \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=yuehaibing@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).