On Mon, Apr 27, 2015 at 09:13:56PM +0300, Pantelis Antoniou wrote:
> Hi Greg,
>
> > On Apr 24, 2015, at 23:29 , Greg KH <g...@kroah.com> 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.anton...@konsulko.com>
> >> ---
> >> 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.
> >> +
> >> 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?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
