[Bug 2154194] Re: [Jammy] Priority inversion problem in epoll for rt kernel

** Tags added: kernel-daily-bug -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2154194 Title: [Jammy] Priority inversion problem in epoll for rt kernel Status in linux package in Ubuntu: New Status in linux source package in Jammy: New Bug description: [SRU Justification] [Impact] The current epoll implementation in the 5.15 kernel utilizes a read-write semaphore (rwlock_t) to protect the ready event list. While this allows multiple producers to concurrently add items, it introduces a scheduling priority inversion vulnerability. If a high-priority consumer (such as a real-time thread calling epoll_wait) is blocked waiting for the exclusive write lock, it can be indefinitely stalled by a low-priority producer holding the read lock. This results in un-deterministic system stalls and latency spikes. The fix involves replacing rwlock_t with a standard spinlock_t one-to-one, and removing the now-redundant lockless helper functions (list_add_tail_lockless and chain_epi_lockless). This ensures that under real-time configurations, priority inheritance works correctly across the epoll subsystem, eliminating priority inversion. [Fix] Backport upstream commit: 0c43094f8cc9 ("eventpoll: Replace rwlock with spinlock") [Test Plan] Due to the nature of scheduling priority inversion, reproducing this bug reliably on demand is highly impractical. Because this race condition relies on erratic, non-deterministic scheduling micro-windows, a standard deterministic reproduction script cannot be provided. Therefore, validation relies on verifying that the replacement locking mechanism functions correctly, introduces no regressions, and scales safely under synthetic load. There is a test kernel available in the following ppa: https://launchpad.net/~munirsid/+archive/ubuntu/lp2154194 [Where Problems Could Occur] There is a trade-off in raw throughput for highly specific, synthetic workloads. As seen in the upstream commit description [0], in artificial benchmarks where hundreds of threads continuously spam epoll events, throughput can drop by ~38% due to serialization around the new spinlock. However, testing with realistic workloads (via perf bench epoll wait) actually demonstrates a performance improvement on x86 architectures. The regression potential for real-world production environments is considered low, as typical workloads do not exhibit continuous, uninterrupted event-spamming behavior. Moreover, the fix is strictly isolated to fs/eventpoll.c and alters no external kernel APIs. [Other Info] This bug was addressed upstream and has already been integrated into Noble and subsequent releases. [0] - https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0c43094f8cc9d3d99d835c0ac9c4fe1ccc62babd To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2154194/+subscriptions