Re: [PATCH v6 2/3] sysfs: Add a attr_is_visible function to attribute_group

From: Dan Williams
Date: Sat Jan 27 2024 - 20:43:17 EST


Greg KH wrote:
[..]
> > diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
> > index 138676463336..90dd98c82776 100644
> > --- a/fs/sysfs/group.c
> > +++ b/fs/sysfs/group.c
> > @@ -31,6 +31,17 @@ static void remove_files(struct kernfs_node *parent,
> > kernfs_remove_by_name(parent, (*bin_attr)->attr.name);
> > }
> >
> > +static umode_t __first_visible(const struct attribute_group *grp, struct kobject *kobj)
> > +{
> > + if (grp->attrs && grp->is_visible)
> > + return grp->is_visible(kobj, grp->attrs[0], 0);
> > +
> > + if (grp->bin_attrs && grp->is_bin_visible)
> > + return grp->is_bin_visible(kobj, grp->bin_attrs[0], 0);
>
> This kind of makes sense, but why the first attribute only? I guess we
> have to pick one?

Yeah, to not confuse existing implementations is_visible() must always be
passed a valid @attr argument, so might as well pick first available.

> > +
> > + return 0;
> > +}
> > +
> > static int create_files(struct kernfs_node *parent, struct kobject *kobj,
> > kuid_t uid, kgid_t gid,
> > const struct attribute_group *grp, int update)
> > @@ -52,6 +63,7 @@ static int create_files(struct kernfs_node *parent, struct kobject *kobj,
> > kernfs_remove_by_name(parent, (*attr)->name);
> > if (grp->is_visible) {
> > mode = grp->is_visible(kobj, *attr, i);
> > + mode &= ~SYSFS_GROUP_VISIBLE_MASK;
> > if (!mode)
> > continue;
> > }
> > @@ -81,6 +93,7 @@ static int create_files(struct kernfs_node *parent, struct kobject *kobj,
> > (*bin_attr)->attr.name);
> > if (grp->is_bin_visible) {
> > mode = grp->is_bin_visible(kobj, *bin_attr, i);
> > + mode &= ~SYSFS_GROUP_VISIBLE_MASK;
> > if (!mode)
> > continue;
> > }
> > @@ -127,16 +140,35 @@ static int internal_create_group(struct kobject *kobj, int update,
> >
> > kobject_get_ownership(kobj, &uid, &gid);
> > if (grp->name) {
> > + umode_t mode = __first_visible(grp, kobj);
> > + bool has_group_visible = mode & SYSFS_HAS_GROUP_VISIBLE;
> > +
> > + if (has_group_visible && (mode & SYSFS_GROUP_INVISIBLE))
>
> These new SYSFS_*_GROUP values are confusing me, more below:

Ok, SYSFS_HAS_GROUP_VISIBLE is mainly about preserving the long standing
WARN() behavior that flags broken usage of sysfs. If you are open to
dropping strictness I think this can be simplified.

>
> > + mode = 0;
> > + else
> > + mode = S_IRWXU | S_IRUGO | S_IXUGO;
> > +
> > if (update) {
> > kn = kernfs_find_and_get(kobj->sd, grp->name);
> > if (!kn) {
> > - pr_warn("Can't update unknown attr grp name: %s/%s\n",
> > - kobj->name, grp->name);
> > - return -EINVAL;
> > + if (!has_group_visible) {
> > + pr_warn("Can't update unknown attr grp name: %s/%s\n",
> > + kobj->name, grp->name);
> > + return -EINVAL;
> > + }
> > + /* may have been invisible prior to this update */
> > + update = 0;
> > + } else if (!mode) {
> > + sysfs_remove_group(kobj, grp);
> > + kernfs_put(kn);
> > + return 0;
> > }
> > - } else {
> > - kn = kernfs_create_dir_ns(kobj->sd, grp->name,
> > - S_IRWXU | S_IRUGO | S_IXUGO,
> > + }
> > +
> > + if (!update) {
> > + if (!mode)
> > + return 0;
> > + kn = kernfs_create_dir_ns(kobj->sd, grp->name, mode,
> > uid, gid, kobj, NULL);
> > if (IS_ERR(kn)) {
> > if (PTR_ERR(kn) == -EEXIST)
> > @@ -262,6 +294,22 @@ int sysfs_update_group(struct kobject *kobj,
> > }
> > EXPORT_SYMBOL_GPL(sysfs_update_group);
> >
> > +static void warn_group_not_found(const struct attribute_group *grp,
> > + struct kobject *kobj)
> > +{
> > + umode_t mode = __first_visible(grp, kobj);
> > +
> > + if (mode & SYSFS_HAS_GROUP_VISIBLE) {
> > + /* may have never been created */
> > + pr_debug("sysfs group '%s' not found for kobject '%s'\n",
> > + grp->name, kobject_name(kobj));
> > + return;
>
> So if the group is visible somehow, but not found, then it's ok? But:
>
>
> > + }
> > +
> > + WARN(1, KERN_WARNING "sysfs group '%s' not found for kobject '%s'\n",
> > + grp->name, kobject_name(kobj));
>
> We crash the box if it was not visible and not found?

Yes, but only for preservation of legacy strictness. In other words,
without the new "has" flag this is as an unambiguous misuse of sysfs
APIs. With the "has" flag it is no long definitive that someone messed
up.

My preference is delete the WARN() and the "has" flag if you're open to
that.

> > +}
> > +
> > /**
> > * sysfs_remove_group: remove a group from a kobject
> > * @kobj: kobject to remove the group from
> > @@ -279,9 +327,7 @@ void sysfs_remove_group(struct kobject *kobj,
> > if (grp->name) {
> > kn = kernfs_find_and_get(parent, grp->name);
> > if (!kn) {
> > - WARN(!kn, KERN_WARNING
> > - "sysfs group '%s' not found for kobject '%s'\n",
> > - grp->name, kobject_name(kobj));
> > + warn_group_not_found(grp, kobj);
>
> We really should not WARN(), but I guess we don't ever get reports of
> this so it's ok.

It's one of those "should only fire on the kernel developer's system
during development" WARN()s, and per above if it's not adding value, it
is now adding complexity for this group visibility feature.

>
> > return;
> > }
> > } else {
> > diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
> > index b717a70219f6..4fb4f4da003a 100644
> > --- a/include/linux/sysfs.h
> > +++ b/include/linux/sysfs.h
> > @@ -62,21 +62,32 @@ do { \
> > * struct attribute_group - data structure used to declare an attribute group.
> > * @name: Optional: Attribute group name
> > * If specified, the attribute group will be created in
> > - * a new subdirectory with this name.
> > + * a new subdirectory with this name. Additionally when a
> > + * group is named, @is_visible and @is_bin_visible may
> > + * return SYSFS_HAS_GROUP_VISIBLE | SYSFS_GROUP_INVISIBLE
> > + * to control visibility of the directory itself. If
> > + * SYSFS_GROUP_INVISIBLE is ever to be returned,
> > + * SYSFS_HAS_GROUP_VISIBLE must always be included in the
> > + * return value from @is_visible and @is_bin_visible. See
> > + * the DEFINE_SYSFS_GROUP_VISIBLE() helper.
>
> Here it gets confusing for me. Why are you saying things like
> SYSFS_HAS_GROUP_VISIBLE and SYSFS_GROUP_INVISIBLE, when your example
> shows none of that at all? Shouldn't this all be internal-to-sysfs
> stuff? Why list it here?

True. I took my cue from the fact that SYSFS_PREALLOC is mentioned in
the documentation even though it is only ever used internally by the
attribute definition macros. I can trim to only the user documentation.

> > * @is_visible: Optional: Function to return permissions associated with an
> > - * attribute of the group. Will be called repeatedly for each
> > - * non-binary attribute in the group. Only read/write
> > - * permissions as well as SYSFS_PREALLOC are accepted. Must
> > - * return 0 if an attribute is not visible. The returned value
> > - * will replace static permissions defined in struct attribute.
> > + * attribute of the group. Will be called repeatedly for
> > + * each non-binary attribute in the group. Only read/write
> > + * permissions as well as SYSFS_PREALLOC (and the
> > + * visibility flags for named groups) are accepted. Must
> > + * return 0 (or just SYSFS_HAS_GROUP_VISIBLE) if an
> > + * attribute is not visible. The returned value will
> > + * replace static permissions defined in struct attribute.
> > * @is_bin_visible:
> > * Optional: Function to return permissions associated with a
> > * binary attribute of the group. Will be called repeatedly
> > * for each binary attribute in the group. Only read/write
> > - * permissions as well as SYSFS_PREALLOC are accepted. Must
> > - * return 0 if a binary attribute is not visible. The returned
> > - * value will replace static permissions defined in
> > - * struct bin_attribute.
> > + * permissions as well as SYSFS_PREALLOC (and the
> > + * visibility flags for named groups) are accepted. Must
> > + * return 0 (or just SYSFS_HAS_GROUP_VISIBLE) if a binary
> > + * attribute is not visible. The returned value will
> > + * replace static permissions defined in struct
> > + * bin_attribute.
> > * @attrs: Pointer to NULL terminated list of attributes.
> > * @bin_attrs: Pointer to NULL terminated list of binary attributes.
> > * Either attrs or bin_attrs or both must be provided.
> > @@ -91,13 +102,49 @@ struct attribute_group {
> > struct bin_attribute **bin_attrs;
> > };
> >
> > +#define SYSFS_PREALLOC 010000
> > +#define SYSFS_HAS_GROUP_VISIBLE 020000
>
> Nit, forgot a tab :(

Fixed.

> > +#define SYSFS_GROUP_INVISIBLE 040000
> > +#define SYSFS_GROUP_VISIBLE_MASK (SYSFS_HAS_GROUP_VISIBLE|SYSFS_GROUP_INVISIBLE)
>
> Ackward defines, "HAS_GROUP_VISABLE" vs. "GROUP_INVISIBLE"? Why not
> just "GROUP_VISIBLE" and "GROUP_INVISIBLE"?

Yeah, this "has" thing is only about preserving the WARN regime, the
other is reflecting the state.

> > +
> > +static inline umode_t sysfs_group_visible(umode_t mode)
> > +{
> > + return mode | SYSFS_HAS_GROUP_VISIBLE;
>
> So if mode is 0, then we return visible? is that really correct?

If the mode is zero we return, "oh by the way, this attribute group
potentially has variable visibility, so don't assume that failures to
find the directory already created at sysfs_update_group() time are
fatal"

Just explaining it that way convinces me it is time for those failure
cases to go.

> > +/*
> > + * The first call to is_visible() in the create / update path may
> > + * indicate visibility for the entire group
> > + */
> > +#define DEFINE_SYSFS_GROUP_VISIBLE(name) \
> > +static inline umode_t sysfs_group_visible_##name( \
> > + struct kobject *kobj, struct attribute *attr, int n) \
> > +{ \
> > + if (n == 0 && !name##_group_visible(kobj)) \
> > + return sysfs_group_visible(SYSFS_GROUP_INVISIBLE); \
>
> This reads really funny, we are passing in "invisible" to a "visible"
> function call :)
>
> Why pass anything in here? I really have a hard time parsing this,
> maybe because of the negative of the "*_group_visible()" call?
>
>
> > + return sysfs_group_visible(name##_attr_visible(kobj, attr, n)); \
>
> But you only call this on the first attribute, right? I kind of
> understand that, but documenting it a bit better here might help?
>
> Anyway, basic structure I like, changes for a driver to use this I love,
> but implementation confuses me, and if I have to maintain it for the
> next 20+ years, and can't understand it on day 1, I'm going to be in
> trouble soon, which makes me wary to take this as-is.

Here it is again without being beholden to keeping the old
WARN()/pr_warn() regime when the group directory is not found.

-- >8 --