Andrew,

this series replaces

	getrusage-move-thread_group_cputime_adjusted-outside-of-lock_task_sighand.patch
	getrusage-use-sig-stats_lock.patch

in mm-nonmm-unstable.

The patches are same, I only tried to improve the changelogs as we discussed.

Dylan, do you have something to add?

Oleg.

On Mon, Jan 22, 2024 at 7:51 AM Oleg Nesterov <oleg@redhat.com> wrote:
>
> Dylan, do you have something to add?
>
> Oleg.
>

I have one last question -- is there possibly an edge case in which
the hard lockup
can still happen? How likely is it for many writers to force enough
readers to do a
retry on the seqlock, disabling irq and causing the lockup? Is this
not a concern
because there aren't many writers?

Thanks,
Dylan

On 01/23, Dylan Hatch wrote:
>
> I have one last question -- is there possibly an edge case in which
> the hard lockup
> can still happen? How likely is it for many writers to force enough
> readers to do a
> retry on the seqlock, disabling irq and causing the lockup?

I don't know how likely is it, and I guess the repro should be more creative ;)

But yes. Please see the TODO: section in the changelog,

	- Turn sig->stats_lock into seqcount_rwlock_t, this way the
	  readers in the slow mode won't exclude each other.

and more importantly,

	- stats_lock has to disable irqs because ->siglock can be taken
	  in irq context, it would be very nice to change __exit_signal()
	  to avoid the siglock->stats_lock dependency.

There are other users which take stats_lock under siglock (and the
"fs/proc: do_task_stat" series changes 2 of them to not do this), but
__exit_signal() is most problematic.

If we remove this dependency, we can turn read_seqbegin_or_lock_irqsave()
into read_seqbegin_or_lock() which doesn't disable irqs.

Oleg.