On Mon, Sep 13, 2021 at 08:27:50AM +0200, Greg Kroah-Hartman wrote: > Anyway, I like the idea, but as you can see here, it could lead to even > more abuse of sysfs files. We are just now getting people to use > sysfs_emit() and that is showing us where people have been abusing the > api in bad ways. To be honest I've always seen sysfs_emit as at best a horrible band aid to enforce the PAGE_SIZE bounds checking. Better than nothing, but not a solution at all, as you can't force anyone to actually use it. > Is there any way that sysfs can keep the existing show functionality and > just do the seq_printf() for the buffer returned by the attribute file > inside of the sysfs core? Well, you'd need one page allocated in the seq_file code, and one in the sysfs code. At which point we might as well drop using seq_file at all. But in general seq_file seems like a very nice helper for over flow free printing into a buffer. If sysfs files actually were all limited to a single print we wouldn't really need it, and could just have something like sysfs_emit just with the buffer hidden inside a structure that is opaqueue to the caller. But looking at various attributes that is not exactly the case. While the majority certainly uses a single value and a single print statement there is plenty where this is not the case. Either because they use multiple values, or often also because they dynamically append to the string to print things like comma-separated flags.
