On Fri, Dec 21, 2018 at 01:07:12PM +0300, Alexey Dobriyan wrote: > On Thu, Dec 20, 2018 at 12:38:33PM -0800, Andrew Morton wrote: > > On Thu, 20 Dec 2018 00:28:04 +0100 Michał Mirosław <mirq-linux@xxxxxxxxxxxx> wrote: > > > > > Keeps truncation working, but also signals to writing process > > > when that happens. > > Please fully describe what is presently wrong with truncation. ie: > > describe the end-user-visible effects of a bug when fixing it. > Well, patch returns number of bytes actually copied instead of what > write(2) is given if truncation occurs. > > But TASK_COMM_LEN was fixed since forever, none of this is needed. > > Same for the second patch, lseek(SEEK_END) is unnecessary is > the size of the file is fixed. What I want to do later is to make TASK_COMM_LEN bigger in a backward-compatible way. And userspace has to know somehow the length after it gets extended. Glibc now limits the length before write(), so this really affects only shell users. pthread_get/set_name_np() has an interface that can use an extended length - it's description limits the length to 16 bytes for Linux, but other OSes have different lengths, and so application authors have to take this into account for multiplatform compatibility. I think silent truncation is rather user-unfriendly. prctl() equivalent does it that way, though. An relic of the ancient past, I would say. Best Regards, Michał Mirosław
