Received-SPF: pass (google.com: domain of linux-kernel+bounces-45675-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Feedback-ID: i21f147d5:Fastmail
Date: Tue, 30 Jan 2024 19:27:50 -0700
From: Tycho Andersen <tycho@tycho.pizza>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Christian Brauner <brauner@kernel.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] pidfd: implement PIDFD_THREAD flag for pidfd_open()
Message-ID: <ZbmwJiIS4ei64u6R@tycho.pizza>
References: <20240130112638.GA29773@redhat.com>
 <20240130113409.GA29849@redhat.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240130113409.GA29849@redhat.com>

On Tue, Jan 30, 2024 at 12:34:09PM +0100, Oleg Nesterov wrote:
> Damn. Self-NACK.
> 
> I forgot (we all ;) about mt-exec, and there are 2 problems.
> 
> 1. The "if (!thread_group_leader(tsk))" block in de_thread() needs
>    do_notify_pidfd() too, the execing non-leader thread looses its
>    old pid, pidfd_poll(PIDFD_THREAD, pid-of-execing-sub-thread)
>    should succeed. Must be fixed, I think.

I think the `test_non_tgl_exec` from my tests exercises the scenario
you're describing, and it works.

> 2. pidfd_poll(PIDFD_THREAD, pid-of-group-leader) should not succeed
>    when its sub-thread execs, the execing thread inherits the leader's
>    pid. Perhaps pidfd_task_exited() can check sig->group_exec_task,

I didn't have an explicit test for this, but I hacked one up, and
pidfd_poll(PIDFD_THREAD, pid-of-group-leader) doesn't return after
exec.

I think it's ok? But I must be missing something.

Tycho