Re: [PATCH RFC v3 2/4] exec: introduce struct task_exec_state

[Oleg Nesterov <oleg@redhat.com>]

On 05/26, Christian Brauner wrote:
>
> On Fri, May 22, 2026 at 05:00:10PM +0200, Oleg Nesterov wrote:
> >
> > Can't we (later) move exec_state into signal_struct?
> >
> > AFAICS, the only complication is that task_still_dumpable/etc can't use
> > tsk->signal->exec_state if tsk was alredy reaped (another thread can do
> > exec_mmap() after that). But perhaps we can rely on pid_alive() check
> > and return an error if the task has already passed __unhash_process() ?
>
> So Jann pointed out a problem with this in
> https://lore.kernel.org/CAG48ez0Gz_GghVeVzaixAQRNYBdWHYEj3K6FXBSzc+8WNsFxtA@mail.gmail.com

Aha, thanks. This is basically what I have said above.

> I quote:
>
>     I think signal_struct is not unshared on exec; so in this sequence of events:
>
>      - task T1 is a non-dumpable task
>      - task T1 creates another thread T2
>      - T2 exits
>      - T1 goes through execve and becomes dumpable

Note that T1 can call exec_mmap/etc only after T2 is already reaped, that
is why I said we need to use something like pid_alive() check.

OK, lets forget it for now, this needs some changes in release_task() path,
perhaps makes no sense.

FWIW, your series + additional fixlets you sent in reply to 0/4 look good to me,
I see nothing wrong.

Oleg.