Re: [patch 7/8] posix-cpu-timers: Prevent enqueueing when PF_EXITING is set

[Thomas Gleixner <tglx@kernel.org>]

On Fri, Sep 04 2026 at 10:47, Eric W. Biederman wrote:
> "Eric W. Biederman" <ebiederm@xmission.com> writes:
>> Thomas Gleixner <tglx@kernel.org> writes:
>>
>>>  
>>> +static inline bool task_can_enqueue(struct k_itimer *timer, struct task_struct *p)
>>> +{
>>> +	if (likely(!(p->flags & PF_EXITING)))
>>> +		return true;
>>> +
>>> +	/* Allow TGID type unless the last thread is on the way out. */
>>> +	return clock_pid_type(timer->it_clock) == PIDTYPE_TGID && atomic_read(&p->signal->live);
>>
>> Couldn't this be?
>>
>> 	/* Allow TGID type unless the group is on the way out. */
>> 	return (clock_pid_type(timer->it_clock) == PIDTYPE_TGID) &&
>>         	!(p->signal->flags & SIGNAL_GROUP_EXIT);
>>> +}
>>
>> I don't understand why we would want to re-arm a timer after it has
>> been decided the group is dying.
>>
>> Plush I really don't like the idea of p->signal->live spreading to more
>> places.  In the future that has the potential to complicate any changes
>> to the group_dead calculation.
>
> Hmm.
>
> Now that I think about it this could be:
>
> static inline bool task_can_enqueue(struct k_itimer *timer, struct task_struct *p)
> {
> 	/* Is the process exiting? */
> 	if (signal->flags & SIGNAL_GROUP_EXIT)
>         	return false;
>
> 	/* Is the thread exiting? */
> 	if ((clock_pid_type(timer->it_clock) == PIDTYPE_PID) &&
> 	    (p->flags & PF_EXITING))
> 		return false;
>
> 	return true;
> }
>
> Unless I am missing something subtle with the parts of shutdown.  As
> there is a difference between starting the shutdown, and having reached
> do_exit.
>
> But unless there is some subtle reason to start a timer after some
> thread has called exit() or after a fatal signal has been received
> I suspect stopping as soon as SIGNAL_GROUP_EXIT is set is a good idea.

I don't see a reason why that would be a problem. It puts the cutoff a
little bit earlier, but who cares. The task/process is going to exit no
matter what.

So the "observable" difference would be that a POSIX CPU timer which is
attached to the process by a different entity will stop firing a little
bit earlier. The resulting "fallout" is a purely academic problem IMO.

Thanks,

        tglx