Re: [PATCH v3 2/4] of: overlay: global sysfs enable attribute

[Pantelis Antoniou]

Hi Greg,

> On Apr 27, 2015, at 21:39 , Greg KH <greg@xxxxxxxxx> wrote:
> 
> On Mon, Apr 27, 2015 at 09:13:56PM +0300, Pantelis Antoniou wrote:
>> Hi Greg,
>> 
>>> On Apr 24, 2015, at 23:29 , Greg KH <greg@xxxxxxxxx> wrote:
>>> 
>>> On Fri, Apr 24, 2015 at 12:45:42PM +0300, Pantelis Antoniou wrote:
>>>> A throw once master enable switch to protect against any
>>>> further overlay applications if the administrator desires so.
>>>> 
>>>> Signed-off-by: Pantelis Antoniou <pantelis.antoniou@xxxxxxxxxxxx>
>>>> ---
>>>> drivers/of/overlay.c | 45 ++++++++++++++++++++++++++++++++++++++++++++-
>>>> 1 file changed, 44 insertions(+), 1 deletion(-)
>>>> 
>>>> diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
>>>> index f17f5ef..c335809 100644
>>>> --- a/drivers/of/overlay.c
>>>> +++ b/drivers/of/overlay.c
>>>> @@ -21,6 +21,7 @@
>>>> #include <linux/err.h>
>>>> #include <linux/idr.h>
>>>> #include <linux/sysfs.h>
>>>> +#include <linux/atomic.h>
>>>> 
>>>> #include "of_private.h"
>>>> 
>>>> @@ -55,8 +56,12 @@ struct of_overlay {
>>>> 	struct kobject kobj;
>>>> };
>>>> 
>>>> +/* master enable switch; once set to 0 can't be re-enabled */
>>>> +static atomic_t ov_enable = ATOMIC_INIT(1);
>>>> +
>>>> static int of_overlay_apply_one(struct of_overlay *ov,
>>>> 		struct device_node *target, const struct device_node *overlay);
>>>> +static int overlay_removal_is_ok(struct of_overlay *ov);
>>>> 
>>>> static int of_overlay_apply_single_property(struct of_overlay *ov,
>>>> 		struct device_node *target, struct property *prop)
>>>> @@ -339,6 +344,37 @@ void of_overlay_release(struct kobject *kobj)
>>>> 	kfree(ov);
>>>> }
>>>> 
>>>> +static ssize_t enable_show(struct kobject *kobj,
>>>> +		struct kobj_attribute *attr, char *buf)
>>>> +{
>>>> +	return snprintf(buf, PAGE_SIZE, "%d\n", atomic_read(&ov_enable));
>>>> +}
>>>> +
>>>> +static ssize_t enable_store(struct kobject *kobj,
>>>> +		struct kobj_attribute *attr, const char *buf, size_t count)
>>>> +{
>>>> +	int ret;
>>>> +	long new_enable;
>>>> +
>>>> +	ret = kstrtol(buf, 10, &new_enable);
>>>> +	if (ret != 0)
>>>> +		return ret;
>>>> +	if ((unsigned long)new_enable > 1)
>>>> +		return -EINVAL;
>>>> +	/* if we've disabled it, no going back */
>>>> +	if (atomic_read(&ov_enable) == 0)
>>>> +		return -EPERM;
>>>> +	atomic_set(&ov_enable, (int)new_enable);
>>>> +	return count;
>>>> +}
>>>> +
>>>> +static struct kobj_attribute enable_attr = __ATTR_RW(enable);
>>>> +
>>>> +static const struct attribute *overlay_global_attrs[] = {
>>>> +	&enable_attr.attr,
>>>> +	NULL
>>>> +};
>>> 
>>> Why not make this an attribute group and then attach it to the kobj_type
>>> to create the files in a race-free manner?
>>> 
>> 
>> Err, these are the global attributes. They are attached to the
>> parent of the overlay objects which is a kset object itself.
> 
> Ick, no, never attach attributes to a kobject that you don't create
> yourself, otherwise it's a race that you lost.
> 

Err, it is created by me. Itâs a kset by the following call:

> ov_kset = kset_create_and_add("overlays", NULL, &of_kset->kobj);
> 

What is the problem with this?

>>>> +
>>>> static struct kobj_type of_overlay_ktype = {
>>>> 	.release = of_overlay_release,
>>>> };
>>>> @@ -360,6 +396,10 @@ int of_overlay_create(struct device_node *tree)
>>>> 	struct of_overlay *ov;
>>>> 	int err, id;
>>>> 
>>>> +	/* administratively disabled */
>>>> +	if (!atomic_read(&ov_enable))
>>>> +		return -EPERM;
>>>> +
>>>> 	/* allocate the overlay structure */
>>>> 	ov = kzalloc(sizeof(*ov), GFP_KERNEL);
>>>> 	if (ov == NULL)
>>>> @@ -596,5 +636,8 @@ int of_overlay_init(void)
>>>> 	if (!ov_kset)
>>>> 		return -ENOMEM;
>>>> 
>>>> -	return 0;
>>>> +	rc = sysfs_create_files(&ov_kset->kobj, overlay_global_attrs);
>>>> +	WARN(rc, "%s: error adding global attributes\n", __func__);
>>> 
>>> What can a user do with this warning message?  If nothing, then don't
>>> print it out, right?
>>> 
>>> You are creating sysfs files _after_ the kobject has been announced to
>>> userspace, causing nasty race conditions.  Please don't do that.
>>> 
>> 
>> This is at overlay_init() time, which is way way before userspace ever
>> has a chance to start. If thereâs a different way to attach a attribute
>> group to a kset object Iâd like to find out how :)
> 
> You can't load this as a module?  Where exactly in sysfs is this
> kobject, and who creates it?
> 

No, thereâs no way to load this as a module, itâs in /sys/firmware/devicetree

And itâs created by the call to kset_create_and_add()

> thanks,
> 
> greg k-h

Regards

â Pantelis


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/