From: Oleg Nesterov <oleg@redhat.com>
To: Dylan Hatch <dylanbhatch@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/2] getrusage: use sig->stats_lock
Date: Wed, 24 Jan 2024 01:39:30 +0100 [thread overview]
Message-ID: <20240124003930.GA26412@redhat.com> (raw)
In-Reply-To: <CADBMgpxNUoaermXsEj0Hs0KT=Q0xRpz5y+Px=oAGDP2Efg8yyw@mail.gmail.com>
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.
prev parent reply other threads:[~2024-01-24 0:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-22 15:50 [PATCH v2 0/2] getrusage: use sig->stats_lock Oleg Nesterov
2024-01-22 15:50 ` [PATCH v2 1/2] getrusage: move thread_group_cputime_adjusted() outside of lock_task_sighand() Oleg Nesterov
2024-01-22 15:50 ` [PATCH v2 2/2] getrusage: use sig->stats_lock rather than lock_task_sighand() Oleg Nesterov
2024-01-22 23:57 ` Andrew Morton
2024-01-23 15:53 ` Oleg Nesterov
2024-01-23 23:45 ` [PATCH v2 0/2] getrusage: use sig->stats_lock Dylan Hatch
2024-01-24 0:39 ` Oleg Nesterov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240124003930.GA26412@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=dylanbhatch@google.com \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.