Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 16 Sep 2019 22:10:08 +0100
From:   Will Deacon <will@kernel.org>
To:     KeMeng Shi <shikemeng@huawei.com>
Cc:     akpm@linux-foundation.org, james.morris@microsoft.com,
        gregkh@linuxfoundation.org, mortonm@chromium.org,
        will.deacon@arm.com, kristina.martsenko@arm.com,
        yuehaibing@huawei.com, malat@debian.org, j.neuschaefer@gmx.net,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] connector: report comm change event when modifying
 /proc/pid/task/tid/comm
Message-ID: <20190916211008.ipqe3j7s22aannta@willie-the-truck>
References: <20190916141341.658-1-shikemeng@huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190916141341.658-1-shikemeng@huawei.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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 <shikemeng@huawei.com>
> ---
>  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