To be able to constify instances of struct attribute it has to be
possible to add them to struct attribute_group.
The current type of the attrs member however is not compatible with that.
Introduce a union that allows registration of both const and non-const
attributes to enable a piecewise transition.
As both union member types are compatible no logic needs to be adapted.
Technically it is now possible register a const struct
attribute and receive it as mutable pointer in the callbacks.
This is a soundness issue.
But this same soundness issue already exists today in
sysfs_create_file().
Also the struct definition and callback implementation are always
closely linked and are meant to be moved to const in lockstep.
Similar to commit 906c508afdca ("sysfs: attribute_group: allow registration of const bin_attribute")
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
include/linux/sysfs.h | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index f418aae4f1134f8126783d9e8eb575ba4278e927..a47092e837d9eb014894d1f7e49f0fd0f9a2e350 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -105,7 +105,10 @@ struct attribute_group {
size_t (*bin_size)(struct kobject *,
const struct bin_attribute *,
int);
- struct attribute **attrs;
+ union {
+ struct attribute **attrs;
+ const struct attribute *const *attrs_new;
+ };
union {
const struct bin_attribute *const *bin_attrs;
const struct bin_attribute *const *bin_attrs_new;
--
2.50.1
On Mon, Aug 11, 2025 at 11:14:27AM +0200, Thomas Weißschuh wrote: > To be able to constify instances of struct attribute it has to be > possible to add them to struct attribute_group. > The current type of the attrs member however is not compatible with that. > Introduce a union that allows registration of both const and non-const > attributes to enable a piecewise transition. > As both union member types are compatible no logic needs to be adapted. > > Technically it is now possible register a const struct > attribute and receive it as mutable pointer in the callbacks. > This is a soundness issue. > But this same soundness issue already exists today in > sysfs_create_file(). > Also the struct definition and callback implementation are always > closely linked and are meant to be moved to const in lockstep. > > Similar to commit 906c508afdca ("sysfs: attribute_group: allow registration of const bin_attribute") > > Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> > --- > include/linux/sysfs.h | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h > index f418aae4f1134f8126783d9e8eb575ba4278e927..a47092e837d9eb014894d1f7e49f0fd0f9a2e350 100644 > --- a/include/linux/sysfs.h > +++ b/include/linux/sysfs.h > @@ -105,7 +105,10 @@ struct attribute_group { > size_t (*bin_size)(struct kobject *, > const struct bin_attribute *, > int); > - struct attribute **attrs; > + union { > + struct attribute **attrs; > + const struct attribute *const *attrs_new; I know you will drop the "_new" prefix after a while, but "new" is relative, and not very descriptive. How about "_const"? > + }; > union { > const struct bin_attribute *const *bin_attrs; > const struct bin_attribute *const *bin_attrs_new; There is no bin_attrs_new anymore. Finally. sorry about that... greg k-h
On 2025-08-19 13:22:55+0200, Greg Kroah-Hartman wrote: > On Mon, Aug 11, 2025 at 11:14:27AM +0200, Thomas Weißschuh wrote: > > To be able to constify instances of struct attribute it has to be > > possible to add them to struct attribute_group. > > The current type of the attrs member however is not compatible with that. > > Introduce a union that allows registration of both const and non-const > > attributes to enable a piecewise transition. > > As both union member types are compatible no logic needs to be adapted. > > > > Technically it is now possible register a const struct > > attribute and receive it as mutable pointer in the callbacks. > > This is a soundness issue. > > But this same soundness issue already exists today in > > sysfs_create_file(). > > Also the struct definition and callback implementation are always > > closely linked and are meant to be moved to const in lockstep. > > > > Similar to commit 906c508afdca ("sysfs: attribute_group: allow registration of const bin_attribute") > > > > Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> > > --- > > include/linux/sysfs.h | 5 ++++- > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h > > index f418aae4f1134f8126783d9e8eb575ba4278e927..a47092e837d9eb014894d1f7e49f0fd0f9a2e350 100644 > > --- a/include/linux/sysfs.h > > +++ b/include/linux/sysfs.h > > @@ -105,7 +105,10 @@ struct attribute_group { > > size_t (*bin_size)(struct kobject *, > > const struct bin_attribute *, > > int); > > - struct attribute **attrs; > > + union { > > + struct attribute **attrs; > > + const struct attribute *const *attrs_new; > > I know you will drop the "_new" prefix after a while, but "new" is > relative, and not very descriptive. That is somewhat intentional to express that it is a transitional thing. > How about "_const"? At some point the regular variant will be const too, so "_const" would be a bit weird. > > + }; > > union { > > const struct bin_attribute *const *bin_attrs; > > const struct bin_attribute *const *bin_attrs_new; > > There is no bin_attrs_new anymore. Finally. sorry about that... Thanks! No worries. Thomas
On Tue, Aug 19, 2025 at 03:59:04PM +0200, Thomas Weißschuh wrote: > On 2025-08-19 13:22:55+0200, Greg Kroah-Hartman wrote: > > On Mon, Aug 11, 2025 at 11:14:27AM +0200, Thomas Weißschuh wrote: > > > To be able to constify instances of struct attribute it has to be > > > possible to add them to struct attribute_group. > > > The current type of the attrs member however is not compatible with that. > > > Introduce a union that allows registration of both const and non-const > > > attributes to enable a piecewise transition. > > > As both union member types are compatible no logic needs to be adapted. > > > > > > Technically it is now possible register a const struct > > > attribute and receive it as mutable pointer in the callbacks. > > > This is a soundness issue. > > > But this same soundness issue already exists today in > > > sysfs_create_file(). > > > Also the struct definition and callback implementation are always > > > closely linked and are meant to be moved to const in lockstep. > > > > > > Similar to commit 906c508afdca ("sysfs: attribute_group: allow registration of const bin_attribute") > > > > > > Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> > > > --- > > > include/linux/sysfs.h | 5 ++++- > > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > > > diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h > > > index f418aae4f1134f8126783d9e8eb575ba4278e927..a47092e837d9eb014894d1f7e49f0fd0f9a2e350 100644 > > > --- a/include/linux/sysfs.h > > > +++ b/include/linux/sysfs.h > > > @@ -105,7 +105,10 @@ struct attribute_group { > > > size_t (*bin_size)(struct kobject *, > > > const struct bin_attribute *, > > > int); > > > - struct attribute **attrs; > > > + union { > > > + struct attribute **attrs; > > > + const struct attribute *const *attrs_new; > > > > I know you will drop the "_new" prefix after a while, but "new" is > > relative, and not very descriptive. > > That is somewhat intentional to express that it is a transitional thing. Fair, but given the huge quantity here, it's going to take a long time, so "new" is going to be rough to push through for 6+ months. > > How about "_const"? > > At some point the regular variant will be const too, so "_const" would > be a bit weird. Yes, that's when you "switch it back", right? You would have to do that for _new as well. thanks, greg k-h
On 2025-08-19 16:10:42+0200, Greg Kroah-Hartman wrote: > On Tue, Aug 19, 2025 at 03:59:04PM +0200, Thomas Weißschuh wrote: > > On 2025-08-19 13:22:55+0200, Greg Kroah-Hartman wrote: > > > On Mon, Aug 11, 2025 at 11:14:27AM +0200, Thomas Weißschuh wrote: > > > > To be able to constify instances of struct attribute it has to be > > > > possible to add them to struct attribute_group. > > > > The current type of the attrs member however is not compatible with that. > > > > Introduce a union that allows registration of both const and non-const > > > > attributes to enable a piecewise transition. > > > > As both union member types are compatible no logic needs to be adapted. > > > > > > > > Technically it is now possible register a const struct > > > > attribute and receive it as mutable pointer in the callbacks. > > > > This is a soundness issue. > > > > But this same soundness issue already exists today in > > > > sysfs_create_file(). > > > > Also the struct definition and callback implementation are always > > > > closely linked and are meant to be moved to const in lockstep. > > > > > > > > Similar to commit 906c508afdca ("sysfs: attribute_group: allow registration of const bin_attribute") > > > > > > > > Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> > > > > --- > > > > include/linux/sysfs.h | 5 ++++- > > > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h > > > > index f418aae4f1134f8126783d9e8eb575ba4278e927..a47092e837d9eb014894d1f7e49f0fd0f9a2e350 100644 > > > > --- a/include/linux/sysfs.h > > > > +++ b/include/linux/sysfs.h > > > > @@ -105,7 +105,10 @@ struct attribute_group { > > > > size_t (*bin_size)(struct kobject *, > > > > const struct bin_attribute *, > > > > int); > > > > - struct attribute **attrs; > > > > + union { > > > > + struct attribute **attrs; > > > > + const struct attribute *const *attrs_new; > > > > > > I know you will drop the "_new" prefix after a while, but "new" is > > > relative, and not very descriptive. > > > > That is somewhat intentional to express that it is a transitional thing. > > Fair, but given the huge quantity here, it's going to take a long time, > so "new" is going to be rough to push through for 6+ months. Looking at how 'struct bin_attribute' went probably quite a bit longer. > > > How about "_const"? > > > > At some point the regular variant will be const too, so "_const" would > > be a bit weird. > > Yes, that's when you "switch it back", right? You would have to do that > for _new as well. There will probably be some overlap. But in the end it probably doesn't matter. Let's go with "_const". Thomas
© 2016 - 2025 Red Hat, Inc.