On Fri, Apr 18, 2025 at 10:15:01AM +0800, Xilin Wu wrote:
On 2025/4/7 17:54:15, Christian Brauner wrote:
This allows the VFS to not trip over anonymous inodes and we can add asserts based on the mode into the vfs. When we report it to userspace we can simply hide the mode to avoid regressions. I've audited all direct callers of alloc_anon_inode() and only secretmen overrides i_mode and i_op inode operations but it already uses a regular file.
Fixes: af153bb63a336 ("vfs: catch invalid modes in may_open()") Cc: stable@vger.kernel.org # all LTS kernels Reported-by: syzbot+5d8e79d323a13aa0b248@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/67ed3fb3.050a0220.14623d.0009.GAE@google.com Signed-off-by: Christian Brauner brauner@kernel.org
Hi Christian and FSdevel list,
I'm reporting a regression introduced in the linux-next tree, which I've tracked down using `git bisect` to this commit.
Starting with `linux-next` tag `next-20250408` (up to the latest `next-20250417` I tested), attempting to start an SDDM Wayland session (using KDE Plasma's KWin) results in a black screen. The `kwin_wayland` and `sddm-helper-start-wayland` processes both enter a state consuming 100% CPU on a single core indefinitely, preventing the login screen from appearing. The last known good kernel is `next-20250407`.
Using `strace` on the `kwin_wayland` process revealed it's stuck in a tight loop involving `ppoll` and `ioctl`:
ioctl(29, FIONREAD, [0]) = 0 ppoll([{fd=10, events=POLLIN}, {fd=37, events=POLLIN}, {fd=9, events=POLLIN}, {fd=5, events=POLLIN}, {fd=29, events=POLLIN}, {fd=17, events=POLLIN}, {fd=3, events=POLLIN}], 7, NULL, NULL, 8) = 1 ([{fd=29, revents=POLLIN}]) ioctl(29, FIONREAD, [0]) = 0 ppoll([{fd=10, events=POLLIN}, {fd=37, events=POLLIN}, {fd=9, events=POLLIN}, {fd=5, events=POLLIN}, {fd=29, events=POLLIN}, {fd=17, events=POLLIN}, {fd=3, events=POLLIN}], 7, NULL, NULL, 8) = 1 ([{fd=29, revents=POLLIN}]) # ... this repeats indefinitely at high frequencyInitially, I suspected a DRM issue, but checking the file descriptor confirmed it's an `inotify` instance:
$ sudo ls -l /proc/<kwin_pid>/fd/29 lr-x------ 1 sddm sddm 64 Apr 17 14:03 /proc/<kwin_pid>/fd/29 -> anon_inode:inotifyReverting this commit resolves the issue, allowing SDDM and KWin Wayland to start normally.
Could you please take a look at this? Let me know if you need any further information or testing from my side.
I'll take a look latest Tuesday.