Thread (16 messages) 16 messages, 7 authors, 2025-01-10

Re: [PATCH v2 0/3] sysfs: constify bin_attribute argument of sysfs_bin_attr_simple_read()

From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: 2025-01-09 07:57:27
Also in: bpf, linux-modules, lkml

On Wed, Jan 08, 2025 at 09:45:45AM -0800, Alexei Starovoitov wrote:
On Tue, Dec 31, 2024 at 2:30 AM Thomas Weißschuh [off-list ref] wrote:
quoted
On 2024-12-30 16:50:41-0800, Alexei Starovoitov wrote:
quoted
On Sat, Dec 28, 2024 at 12:43 AM Thomas Weißschuh [off-list ref] wrote:
quoted
Most users use this function through the BIN_ATTR_SIMPLE* macros,
they can handle the switch transparently.

This series is meant to be merged through the driver core tree.
hmm. why?
Patch 1 changes the signature of sysfs_bin_attr_simple_read().
Before patch 1 sysfs_bin_attr_simple_read() needs to be assigned to the
callback member .read, after patch 1 it's .read_new.
(Both callbacks work exactly the same, except for their signature,
.read_new is only a transition mechanism and will go away again)
quoted
I'd rather take patches 2 and 3 into bpf-next to avoid
potential conflicts.
Patch 1 looks orthogonal and independent.
If you pick up 2 and 3 through bpf-next you would need to adapt these
assignments. As soon as both patch 1 and the modified 2 and 3 hit
Linus' tree, the build would break due to mismatches function pointers.
(Casting function pointers to avoid the mismatch will blow up with KCFI)
I see. All these steps to constify is frankly a mess.
You're wasting cpu and memory for this read vs read_new
when const is not much more than syntactic sugar in C.
You should have done one tree wide patch without doing this _new() hack.

Anyway, rant over. Carry patches 2,3. Hopefully they won't conflict.
But I don't want to see any constification patches in bpf land
that come with such pointless runtime penalty.
The "pointless" penalty will go away once we convert all instances, and
really, it's just one pointer check, sysfs files should NOT be a hot
path for anything real, and one more pointer check should be cached and
not measurable compared to the real logic behind the binary data coming
from the hardware/kernel, right?

sysfs is NOT tuned for speed at all, so adding more checks like this
should be fine.

thanks,

greg k-h
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help