linux-rt-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Xi Ruoyao <xry111@xry111.site>
To: Christian Brauner <brauner@kernel.org>, Nam Cao <namcao@linutronix.de>
Cc: Frederic Weisbecker <frederic@kernel.org>,
	Valentin Schneider	 <vschneid@redhat.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Jan Kara	 <jack@suse.cz>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	John Ogness	 <john.ogness@linutronix.de>,
	Clark Williams <clrkwllms@kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
		linux-rt-devel@lists.linux.dev, linux-rt-users@vger.kernel.org,
	Joe Damato	 <jdamato@fastly.com>,
	Martin Karsten <mkarsten@uwaterloo.ca>,
	Jens Axboe	 <axboe@kernel.dk>
Subject: Re: [PATCH v3] eventpoll: Fix priority inversion problem
Date: Thu, 10 Jul 2025 11:08:18 +0800	[thread overview]
Message-ID: <cda3b07998b39b7d46f10394c232b01a778d07a9.camel@xry111.site> (raw)
In-Reply-To: <20250701-wochen-bespannt-33e745d23ff6@brauner>

On Tue, 2025-07-01 at 14:03 +0200, Christian Brauner wrote:
> On Tue, 27 May 2025 11:08:36 +0200, Nam Cao wrote:
> > The ready event list of an epoll object is protected by read-write
> > semaphore:
> > 
> >   - The consumer (waiter) acquires the write lock and takes items.
> >   - the producer (waker) takes the read lock and adds items.
> > 
> > The point of this design is enabling epoll to scale well with large number
> > of producers, as multiple producers can hold the read lock at the same
> > time.
> > 
> > [...]
> 
> Applied to the vfs.fixes branch of the vfs/vfs.git tree.
> Patches in the vfs.fixes branch should appear in linux-next soon.

> Please report any outstanding bugs that were missed during review in a
> new review to the original patch series allowing us to drop it.

Hi,

After upgrading my kernel to the recent mainline I've encountered some
stability issue, like:

- When GDM started gnome-shell, the screen often froze and the only
thing I could do was to switch into a VT and reboot.
- Sometimes gnome-shell started "fine" but then starting an application
(like gnome-console) needed to wait for about a minute.
- Sometimes the system shutdown process hangs waiting for a service to
stop.
- Rarely the system boot process hangs for no obvious reason.

Most strangely in all the cases there are nothing alarming in dmesg or
system journal.

I'm unsure if this is the culprit but I'm almost sure it's the trigger.
Maybe there's some race condition in my userspace that the priority
inversion had happened to hide...  but anyway reverting this patch
seemed to "fix" the issue.

Any thoughts or pointers to diagnose further?

-- 
Xi Ruoyao <xry111@xry111.site>

  reply	other threads:[~2025-07-10  3:08 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-27  9:08 [PATCH v3] eventpoll: Fix priority inversion problem Nam Cao
2025-05-30  5:08 ` Christian Brauner
2025-06-25 15:35   ` Sebastian Andrzej Siewior
2025-06-26 13:35     ` Frederic Weisbecker
2025-06-26 13:51       ` Sebastian Andrzej Siewior
2025-06-25 14:50 ` Sebastian Andrzej Siewior
2025-06-25 15:27   ` Nam Cao
2025-06-25 15:33     ` Sebastian Andrzej Siewior
2025-06-25 15:57       ` Nam Cao
2025-06-25 16:02         ` Nam Cao
2025-06-26 15:23 ` John Ogness
2025-06-26 15:49   ` Sebastian Andrzej Siewior
2025-06-26 15:56     ` Nam Cao
2025-06-30 15:08 ` K Prateek Nayak
2025-07-01 20:33   ` Florian Bezdeka
2025-07-01 12:03 ` Christian Brauner
2025-07-10  3:08   ` Xi Ruoyao [this message]
2025-07-10  3:48     ` Nam Cao
2025-07-10  4:06       ` Nam Cao
2025-07-10  4:10         ` Xi Ruoyao
2025-07-10  6:21           ` Nam Cao
2025-07-10  6:54             ` Xi Ruoyao
2025-07-10  8:32               ` Nam Cao
2025-07-10  9:47                 ` Xi Ruoyao
2025-07-11  5:02                   ` Nam Cao
2025-07-11  9:44                     ` Christian Brauner
2025-07-11  9:48                       ` Xi Ruoyao
2025-07-11  9:58                         ` Nam Cao
2025-07-11 12:09                           ` Xi Ruoyao
2025-07-11 12:21                             ` Nam Cao
2025-07-12  0:09                               ` Nam Cao
2025-07-12  8:54                                 ` Xi Ruoyao
2025-07-11  9:50                       ` Nam Cao
2025-07-14  8:59                         ` Christian Brauner
2025-07-14 10:14                           ` Nam Cao
2025-07-15  9:37                             ` Yann Ylavic
2025-07-15 10:08                               ` Nam Cao
2025-07-14 16:16                           ` Linus Torvalds

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=cda3b07998b39b7d46f10394c232b01a778d07a9.camel@xry111.site \
    --to=xry111@xry111.site \
    --cc=axboe@kernel.dk \
    --cc=bigeasy@linutronix.de \
    --cc=brauner@kernel.org \
    --cc=clrkwllms@kernel.org \
    --cc=frederic@kernel.org \
    --cc=jack@suse.cz \
    --cc=jdamato@fastly.com \
    --cc=john.ogness@linutronix.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-devel@lists.linux.dev \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=mkarsten@uwaterloo.ca \
    --cc=namcao@linutronix.de \
    --cc=rostedt@goodmis.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=vschneid@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).