Re: [PATCH v2] posix-cpu-timers: Dequeue per-thread timers before exchange_tids()

[Oleg Nesterov <oleg@redhat.com>]

OMG, my head spins ;) I'll try to read your explanation tomorrow.
Right now I am all confused.

But let me ask some stupid questions right now, please help me to
understand the problem.

On 08/26, Hyunwoo Kim wrote:
>
> begin_new_exec() calls posix_cpu_timers_exit(me) right after
> exec_task_namespaces() and that removes the leftover node, so the state
> normally stays invisible. But bprm->point_of_no_return is set before
> de_thread(), so if unshare_files(), set_mm_exe_file(), exec_mmap() or
> exec_task_namespaces() fails, the task dies before it gets there.

Do I understand this correctly? If begin_new_exec() does call
posix_cpu_timers_exit(me), then everything is fine.

Yes? If yes

> --- a/fs/exec.c
> +++ b/fs/exec.c
> @@ -1003,6 +1003,18 @@ static int de_thread(struct task_struct *tsk)
>  		 * the former thread group leader:
>  		 */
>
> +#ifdef CONFIG_POSIX_TIMERS
> +		/*
> +		 * exchange_tids() hands this thread's PID to the old leader,
> +		 * which is reaped right after. The PID lookup in
> +		 * timer_lock_sighand() then fails while the per thread CPU
> +		 * timers are still queued here, so dequeue them first.
> +		 */
> +		spin_lock(lock);
> +		posix_cpu_timers_exit(tsk);
> +		spin_unlock(lock);
> +#endif

... then why do we need to call posix_cpu_timers_exit(current) before
exchange_tids() ?

And what if another process attaches another cpu timer to the execing
thread right after the code above?

Can we move posix_cpu_timers_exit() or the whole CONFIG_POSIX_TIMERS
sequence in begin_new_exec() up, right after de_thread() before the
"if (retval)" check?

Thank you,

Oleg.