[PATCH 0/2] procfs: /proc/PID/comm fixes

[PATCH 0/2] procfs: /proc/PID/comm fixes

[Michał Mirosław]

Two extensions to /proc/PID/comm implementation to ease extending
TASK_COMM length: first is a fix for silent truncation when changing
thread name, second allows atomic query of kernel's TASK_COMM size.

Michał Mirosław (2):
  procfs: signal /proc/PID/comm write truncation
  procfs: lseek(/proc/PID/comm, 0, SEEK_END)

 fs/proc/base.c | 22 ++++++++++++++++++++--
 1 file changed, 20 insertions(+), 2 deletions(-)

-- 
2.19.2

[PATCH 2/2] procfs: lseek(/proc/PID/comm, 0, SEEK_END)

[Michał Mirosław]

Implement lseek(fd, 0, SEEK_END) for /proc/PID/comm to return max
task name length.

This will allow eg. pthread_getname_np() to be able to return ERANGE
without modifying thread's name.

Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
 fs/proc/base.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/fs/proc/base.c b/fs/proc/base.c
index 3a3b566443e5..80f5911f2ea9 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -1575,11 +1575,20 @@ static int comm_open(struct inode *inode, struct file *filp)
 	return single_open(filp, comm_show, inode);
 }
 
+static loff_t comm_lseek(struct file *file, loff_t offset, int whence)
+{
+	/* SEEK_END for seq_files normally gets -EINVAL */
+	if (whence == SEEK_END && offset == 0)
+		return TASK_COMM_LEN - 1;
+
+	return seq_lseek(file, offset, whence);
+}
+
 static const struct file_operations proc_pid_set_comm_operations = {
 	.open		= comm_open,
 	.read		= seq_read,
 	.write		= comm_write,
-	.llseek		= seq_lseek,
+	.llseek		= comm_lseek,
 	.release	= single_release,
 };
 
-- 
2.19.2

[PATCH 1/2] procfs: signal /proc/PID/comm write truncation

[Michał Mirosław]

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(-)

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;
 }
 
-- 
2.19.2

Re: [PATCH 1/2] procfs: signal /proc/PID/comm write truncation

[Andrew Morton]

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.

Re: [PATCH 1/2] procfs: signal /proc/PID/comm write truncation

[Alexey Dobriyan]

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.

Re: [PATCH 1/2] procfs: signal /proc/PID/comm write truncation

[Michał Mirosław]

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