On (08/14/18 16:45), Andrew Morton wrote: > > > > > > - strlcpy(file_name, buf, len); > > > > This is quite interesting. The reason it worked before was the fact that > > strlcpy() copies 'len - 1' bytes, which is strlen(buf) - 1 in our case, > > so it accidentally didn't copy the trailing new line symbol. Which also > > means that "echo -n /dev/sdX" most likely was broken. > > > > I can't find the original email on lkml for some reason, but I > recreated the patch.
Neither can I. > The changelog doesn't describe the end-user impact of the bug, which is > very desirable when tagging a patch for -stable backporting. Can we > have that paragraph please? The problem is that strlcpy() copies as many bytes as the source string has, not as many bytes as destination string can fit. IOW: char dst[100]; char src[1000]; ... strlcpy(dst, src, strlen(src)); where it should do strlcpy(dst, src, strlen(dst)); > The implementation might be able to use strim() somehow. strim() trims white-spaces. What we have here is a trailing new line symbol, which echo appends to the string it writes to the kernel [echo -n switch disables it]. So we receive a "/dev/name\n" device name from sysfs, which we unsuccessfully try to open(). To make it all work we need to remove that trailing new line. A side note, There is sysfs_strcmp(), which takes care of that "user space may append a new line to the string" case, I wonder if we should finally have sysfs_strcpy(), which would not copy the trailing new line. I think this "if string[sz - 1] == '\n' then string[sz - 1] == 0x00" is quite common. -ss