| Message ID | 80bec689c8ce0d46ef64f0dbbee349b54dd4038c.1545261970.git.mirq-linux@rere.qmqm.pl (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | procfs: /proc/PID/comm fixes | expand |
On Thu, 20 Dec 2018 00:28:04 +0100 Michał Mirosław <mirq-linux@rere.qmqm.pl> 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. Thanks.
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@rere.qmqm.pl> 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.
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@rere.qmqm.pl> 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
diff --git a/fs/proc/base.c b/fs/proc/base.c index ce3465479447..3a3b566443e5 100644 --- a/fs/proc/base.c +++ b/fs/proc/base.c @@ -1526,8 +1526,14 @@ static ssize_t comm_write(struct file *file, const char __user *buf, char buffer[TASK_COMM_LEN]; const size_t maxlen = sizeof(buffer) - 1; + if (*offset) + return -ENOSPC; + + if (count > maxlen) + count = maxlen; + memset(buffer, 0, sizeof(buffer)); - if (copy_from_user(buffer, buf, count > maxlen ? maxlen : count)) + if (copy_from_user(buffer, buf, count)) return -EFAULT; p = get_proc_task(inode); @@ -1541,6 +1547,9 @@ static ssize_t comm_write(struct file *file, const char __user *buf, put_task_struct(p); + if (count > 0) + *offset = count; + return count; }
Keeps truncation working, but also signals to writing process when that happens. Fixes: 830e0fc967a7 ("fs, proc: truncate /proc/pid/comm writes to first TASK_COMM_LEN bytes") Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> --- fs/proc/base.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)