[PATCH] of: fix of_update_property()

[PATCH] of: fix of_update_property()

[Xiubo Li]

The of_update_property() is intent to update a property in a node
and if the property does not exist, will add it to the node.

The second search of the property is possibly won't be found, that
maybe removed by other thread just before the second search begain,
if so just retry it.

Signed-off-by: Xiubo Li <Li.Xiubo@freescale.com>
---
 drivers/of/base.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index f807d0e..d0c53bc 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1572,6 +1572,7 @@ int of_update_property(struct device_node *np, struct property *newprop)
 	if (!newprop->name)
 		return -EINVAL;
 
+retry:
 	oldprop = of_find_property(np, newprop->name, NULL);
 	if (!oldprop)
 		return of_add_property(np, newprop);
@@ -1593,7 +1594,7 @@ int of_update_property(struct device_node *np, struct property *newprop)
 	raw_spin_unlock_irqrestore(&devtree_lock, flags);
 
 	if (!found)
-		return -ENODEV;
+		goto retry;
 
 #ifdef CONFIG_PROC_DEVICETREE
 	/* try to add to proc as well if it was initialized */
-- 
1.8.4

Re: [PATCH] of: fix of_update_property()

[Rob Herring]

On Thu, Jan 16, 2014 at 10:46 PM, Xiubo Li <Li.Xiubo@freescale.com> wrote:
> The of_update_property() is intent to update a property in a node

s/intent/indended/

> and if the property does not exist, will add it to the node.
>
> The second search of the property is possibly won't be found, that
> maybe removed by other thread just before the second search begain,
> if so just retry it.

How did you find this problem? Actual use or some artificial stress test?

> Signed-off-by: Xiubo Li <Li.Xiubo@freescale.com>
> ---
>  drivers/of/base.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index f807d0e..d0c53bc 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -1572,6 +1572,7 @@ int of_update_property(struct device_node *np, struct property *newprop)
>         if (!newprop->name)
>                 return -EINVAL;
>
> +retry:
>         oldprop = of_find_property(np, newprop->name, NULL);
>         if (!oldprop)
>                 return of_add_property(np, newprop);

Isn't there also a race that if you do 2 updates for a non-existent
property and both threads try to add the property, the first one will
succeed and the 2nd will fail. The 2nd one needs to retry as well.

Also, couldn't the node itself be removed while trying to do the update?

There seem to be multiple problems with this code, but doing multiple
simultaneous, conflicting updates seems like an unlikely case.

Rob

> @@ -1593,7 +1594,7 @@ int of_update_property(struct device_node *np, struct property *newprop)
>         raw_spin_unlock_irqrestore(&devtree_lock, flags);
>
>         if (!found)
> -               return -ENODEV;
> +               goto retry;
>
>  #ifdef CONFIG_PROC_DEVICETREE
>         /* try to add to proc as well if it was initialized */
> --
> 1.8.4
>
>

Re: [PATCH] of: fix of_update_property()

[Pantelis Antoniou]

Hi Rob,


On Jan 17, 2014, at 4:49 PM, Rob Herring wrote:

> On Thu, Jan 16, 2014 at 10:46 PM, Xiubo Li <Li.Xiubo@freescale.com> wrote:
>> The of_update_property() is intent to update a property in a node
> 
[ snip ]

>>                return of_add_property(np, newprop);
> 
> Isn't there also a race that if you do 2 updates for a non-existent
> property and both threads try to add the property, the first one will
> succeed and the 2nd will fail. The 2nd one needs to retry as well.
> 
> Also, couldn't the node itself be removed while trying to do the update?
> 
> There seem to be multiple problems with this code, but doing multiple
> simultaneous, conflicting updates seems like an unlikely case.
> 

There are multiple problems with this function.

First of all, the firing of the notifier at the beginning with OF_RECONFIG_UPDATE_PROPERTY
even though we have no idea if the property is found.

The locking is no good; the lock should be taken before the search by switching to using
__of_find_property. Threading is just not handled well at all at the moment. 
Retrying is just bogus.

The biggest problem is the semantics; IMHO we should just remove the option to create
a property if it doesn't exist. I don't think there are many callers that use update property
expecting to be created if it doesn't exist.

> Rob
> 
>> @@ -1593,7 +1594,7 @@ int of_update_property(struct device_node *np, struct property *newprop)
>>        raw_spin_unlock_irqrestore(&devtree_lock, flags);
>> 
>>        if (!found)
>> -               return -ENODEV;
>> +               goto retry;
>> 
>> #ifdef CONFIG_PROC_DEVICETREE
>>        /* try to add to proc as well if it was initialized */
>> --
>> 1.8.4
>> 
>> 

Regards

-- Pantelis

RE: [PATCH] of: fix of_update_property()

[Li.Xiubo]

> Subject: Re: [PATCH] of: fix of_update_property()
> 
> On Thu, Jan 16, 2014 at 10:46 PM, Xiubo Li <Li.Xiubo@freescale.com> wrote:
> > The of_update_property() is intent to update a property in a node
> 
> s/intent/indended/
> 
> > and if the property does not exist, will add it to the node.
> >
> > The second search of the property is possibly won't be found, that
> > maybe removed by other thread just before the second search begain,
> > if so just retry it.
> 
> How did you find this problem? Actual use or some artificial stress test?
>

Some artificial stress test at home.

 
> > Signed-off-by: Xiubo Li <Li.Xiubo@freescale.com>
> > ---
> >  drivers/of/base.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/of/base.c b/drivers/of/base.c
> > index f807d0e..d0c53bc 100644
> > --- a/drivers/of/base.c
> > +++ b/drivers/of/base.c
> > @@ -1572,6 +1572,7 @@ int of_update_property(struct device_node *np, struct
> property *newprop)
> >         if (!newprop->name)
> >                 return -EINVAL;
> >
> > +retry:
> >         oldprop = of_find_property(np, newprop->name, NULL);
> >         if (!oldprop)
> >                 return of_add_property(np, newprop);
> 
> Isn't there also a race that if you do 2 updates for a non-existent
> property and both threads try to add the property, the first one will
> succeed and the 2nd will fail. The 2nd one needs to retry as well.
> 

Well, yes, that will happen.

Maybe we could add one __of_add_property() without any locks, like
__of_find_property(). And then in of_update_prperty() move the searching
and adding operations to between lock and unlock, like:

	raw_spin_lock_irqsave();
	oldprop = __of_find_property();
      	if (!oldprop) {
              rc = __of_add_property(np, newprop);
		 ...
	}
	...
	replace the node...
	...
	raw_spin_unlock_irqrestore();

> Also, couldn't the node itself be removed while trying to do the update?
> 

For this is between the lock operations. I think this doesn't matter here.

> There seem to be multiple problems with this code, but doing multiple
> simultaneous, conflicting updates seems like an unlikely case.
> 

Yes, but this will happen in theory. 

Thanks,

Best Regards,
Xiubo

RE: [PATCH] of: fix of_update_property()

[Grant Likely]

On Mon, 20 Jan 2014 05:50:17 +0000, "Li.Xiubo@freescale.com" <Li.Xiubo@freescale.com> wrote:
> > Subject: Re: [PATCH] of: fix of_update_property()
> > 
> > On Thu, Jan 16, 2014 at 10:46 PM, Xiubo Li <Li.Xiubo@freescale.com> wrote:
> > > The of_update_property() is intent to update a property in a node
> > 
> > s/intent/indended/
> > 
> > > and if the property does not exist, will add it to the node.
> > >
> > > The second search of the property is possibly won't be found, that
> > > maybe removed by other thread just before the second search begain,
> > > if so just retry it.
> > 
> > How did you find this problem? Actual use or some artificial stress test?
> >
> 
> Some artificial stress test at home.

Can you reproduce those tests? It would be nice to have the selftests in
the kernel so that we can regression test for problems like this.

g.