On Mon, Sep 16, 2019 at 10:13:41AM -0400, KeMeng Shi wrote:
> Commit f786ecba41588 ("connector: add comm change event report to proc
> connector") added proc_comm_connector to report comm change event, and
> prctl will report comm change event when dealing with PR_SET_NAME case.
>
> prctl can only set the name of the calling thread. In order to set the name
> of other threads in a process, modifying /proc/self/task/tid/comm is a
> general way.It's exactly how pthread_setname_np do to set name of a thread.
>
> It's unable to get comm change event of thread if the name of thread is set
> by other thread via pthread_setname_np. This update provides a chance for
> application to monitor and control threads whose name is set by other
> threads.
>
> Signed-off-by: KeMeng Shi <[email protected]>
> ---
> fs/proc/base.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index ebea9501afb8..34ffe572ac69 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -94,6 +94,7 @@
> #include <linux/sched/debug.h>
> #include <linux/sched/stat.h>
> #include <linux/posix-timers.h>
> +#include <linux/cn_proc.h>
> #include <trace/events/oom.h>
> #include "internal.h"
> #include "fd.h"
> @@ -1549,10 +1550,12 @@ static ssize_t comm_write(struct file *file, const
> char __user *buf,
> if (!p)
> return -ESRCH;
>
> - if (same_thread_group(current, p))
> + if (same_thread_group(current, p)) {
> set_task_comm(p, buffer);
> - else
> + proc_comm_connector(p);
> + } else {
> count = -EINVAL;
> + }
>
> put_task_struct(p);
The rough idea looks ok to me but I have two concerns:
(1) This looks like it will be visible to userspace, and this changes
the behaviour after ~8 years of not reporting this event.
(2) What prevents proc_comm_connector(p) running concurrently with itself
via the prctl()? The locking seems to be confined to set_task_comm().
Will
