On Wed, Jul 10, 2024 at 01:53:22PM +0200, Greg Kroah-Hartman wrote: > On Mon, Jul 08, 2024 at 03:25:53PM +0100, John Keeping wrote: > > Most writes to configfs handle an optional newline, but do not require > > it. By using the number of bytes written as the limit for scnprintf() > > it is guaranteed that the final character in the buffer will be > > overwritten. > > > > This is expected if it is a newline but is undesirable when a string is > > written "as-is" (as libusbgx does, for example). > > So we are changing kernel functionality because a userspace program does > not work? Why not fix the userspace program? This file behaves differently from every other sysfs/debugfs/configfs file AFAICT. In most places the behaviour of the following two commands is equivalent: $ echo foo >file $ printf foo >file But for this function_name the result is that the final character is dropped unconditionally, so the name reported in the USB descriptors will be "fo" in the second case. > > Update the store function to strip an optional newline, matching the > > behaviour of usb_string_copy(). > > This changes the behaviour of a lot of configfs files right? What will > break if this happens? No, this is just one file in f_uac2. I can't see any scenario where a newline in a USB string descriptor makes sense so it's unlikely to break any existing use cases. This brings the audio function name more in line with other string descriptors for the device manufacturer/product or configuration name which use usb_string_copy() and strip a trailing newline if it's present. Regards, John
