Created attachment 1842895 [details] kernel log Created attachment 1842895 [details] kernel log Created attachment 1842895 [details] kernel log 1. Please describe the problem: Kernel 5.14.20 breaks xdg-document-portal (choosing a file) in a flatpak, causing flatpak apps to freeze upon picking a file. I use Fedora 35 KDE with wayland. When booted into kernel 5.14.20-300.fc35.x86_64, and choosing a file to open in a flatpak app, the flatpak app freezes up. This does not happen in kernel 5.14.18. /var/log/messages has kernel errors about fuse when this happens. 2. What is the Version-Release number of the kernel: 5.14.20-300.fc35.x86_64 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : 5.14.20-300.fc35.x86_64 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: Enable flathub repo flatpak install com.belmoussaoui.Obfuscate flatpak run com.belmoussaoui.Obfuscate choose a file app freezes up notice something like this in /var/log/messages Nov 21 07:29:29 fedora-t580 kernel: aops:fuse_file_aops [fuse] ino:5e3ad53fdf779e10 dentry name:"blah.png" Nov 21 07:29:29 fedora-t580 kernel: flags: 0x17ffffc0000017(locked|referenced|uptodate|lru|node=0|zone=2|lastcpupid=0x1fffff) Nov 21 07:29:29 fedora-t580 kernel: raw: 0017ffffc0000017 ffffe34ac8288748 ffffe34ac8225c48 ffff97416b6ac4b8 Nov 21 07:29:29 fedora-t580 kernel: raw: 0000000000000000 0000000000000000 00000002ffffffff ffff9741a41bd000 Nov 21 07:29:29 fedora-t580 kernel: page dumped because: VM_BUG_ON_PAGE(PageLRU(page)) Nov 21 07:29:29 fedora-t580 kernel: ------------[ cut here ]------------ Nov 21 07:29:29 fedora-t580 kernel: kernel BUG at mm/swap.c:469! Nov 21 07:29:29 fedora-t580 kernel: invalid opcode: 0000 [#1] SMP PTI Nov 21 07:29:29 fedora-t580 kernel: CPU: 2 PID: 4934 Comm: fuse mainloop Tainted: G OE 5.14.20-300.fc35.x86_64 #1 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by ``sudo dnf update --enablerepo=rawhide kernel``: Yes. Tried latest rawhide kernel, same issue. Last good kernel that doesn't have this bug is 5.14.18 6. Are you running any modules that not shipped with directly Fedora's kernel?: v4l2loopback_dc (droidcam) virtualbox from rpmfusion 7. Please attach the kernel logs. You can get the complete kernel log for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the issue occurred on a previous boot, use the journalctl ``-b`` flag. attached as dmesg.txt Edit: If the flatpak you test has a filesystem permission it most likely isn't affected by this bug! I'm talking about flatpaks that use portals to access files. Any file that is in a whitelisted filesystem defined in the flatpak would open just fine.
Edit: Tried kernel 5.15.3, same issue. Tried latest rawhide kernel, same issue. Last good kernel that doesn't have this bug is 5.14.18
I can confirm that com.belmoussaoui.Obfuscate also crashes on my system with kernel 5.15.3, but it is working fine with 5.15.2 I tried with some other flatpaks, namely im.riot.Riot, im.fluffychat.Fluffychat, org.mozilla.firefox, org.mozilla.Thunderbird and org.chromium.Chromium and they all work just fine when opening files, regardless of the kernel version. So this could be a specific issuo of com.belmoussaoui.Obfuscate with certain kernel versions.
It happens with any flatpak that doesn't have permission for "home" or "host", meaning, uses portals to access files. It happens with org.duckstation.DuckStation, and org.desmume.DeSmuME, to name some more. So it must be a kernel bug.
It should be worth noting that every time the bug occurs, I notice the same lines in dmesg like the ones I posted in the bug report: Nov 21 07:29:29 fedora-t580 kernel: aops:fuse_file_aops [fuse] ino:5e3ad53fdf779e10 dentry name:"insert_file_here.file" Nov 21 07:29:29 fedora-t580 kernel: flags: 0x17ffffc0000017(locked|referenced|uptodate|lru|node=0|zone=2|lastcpupid=0x1fffff) Nov 21 07:29:29 fedora-t580 kernel: raw: 0017ffffc0000017 ffffe34ac8288748 ffffe34ac8225c48 ffff97416b6ac4b8 Nov 21 07:29:29 fedora-t580 kernel: raw: 0000000000000000 0000000000000000 00000002ffffffff ffff9741a41bd000 Nov 21 07:29:29 fedora-t580 kernel: page dumped because: VM_BUG_ON_PAGE(PageLRU(page)) Nov 21 07:29:29 fedora-t580 kernel: ------------[ cut here ]------------ Nov 21 07:29:29 fedora-t580 kernel: kernel BUG at mm/swap.c:469! Nov 21 07:29:29 fedora-t580 kernel: invalid opcode: 0000 [#1] SMP PTI Nov 21 07:29:29 fedora-t580 kernel: CPU: 2 PID: 4934 Comm: fuse mainloop Tainted: G OE 5.14.20-300.fc35.x86_64 #1 I also tested 5.15.2, and I can confirm it does not have this issue. But 5.15.3 has the issue.
Running 5.14.20-300.fc35.x86_64 here, and using the Signal flatpak: $ flatpak info -M org.signal.Signal [Context] shared=network;ipc; sockets=x11;pulseaudio; devices=all; filesystems=xdg-documents;xdg-desktop;xdg-music;xdg-download;xdg-pictures;xdg-videos;xdg-public-share; [Session Bus Policy] org.kde.StatusNotifierWatcher=talk org.freedesktop.Notifications=talk org.freedesktop.portal.Background=talk org.kde.*=own Doesn't seem to have any problems picking files from the specified directories, and doesn't have `home` or `host` access.
@Dimitris The Signal flatpak doesn't use portals to select files, and it already has "raw" access to those directories, so it wouldn't be affected by this bug.
Flatpaks that use portals typically show the whole filesystem in the file chooser without having permission for it. Meaning, you give them access to specific files when you select them. There would be no "filesystems=" line in permissions for the flatpak.
I can reproduce. I tested com.github.johnfactotum.Foliate from Flathub, which uses Portals to open files. Can't open a book on Kernel 5.14.20. Rebooting into Kernel 5.14.18 solves the problem.
Please notify about this also in Bodhi to prevent this kernel pushing in Stable repos https://bodhi.fedoraproject.org/updates/FEDORA-2021-f2409188d2#comment-2291183
Can you please try both this scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=79202491 And the rawhide 5.16-rc2 kernel: https://koji.fedoraproject.org/koji/buildinfo?buildID=1858573 I expect the scratch build will fix the issue, but I need to know if the patch that was backported for stable is missing another patch that it depends on, or if it was just a bad patch, that's why I need both tested.
I've tested in f35 with this [1] and seems like fixed issue for me. [1]: https://koji.fedoraproject.org/koji/taskinfo?taskID=79202491
Please also test with the rawhide kernel linked, it is important in making sure that we get a proper fix upstream, and that this doesn't revert in 5.16 if I just keep that patch reverted for 5.15 kernels
(In reply to Justin M. Forbes from comment #12) Afraid to test pre-released kernels on bare metal, but OK: so the problem is still persist in kernel-5.16.0-0.rc2.18.fc36. Tested on the same machine and Fedora 35. My test case is 'flatpak-builder' and problem is definitely here in this kernel.
I appreciate it. I am currently building a proper 5.15.4-201/101 that have the patch reverted, and have linked this to upstream.
So, upstream asked that we try a patch, so can people experiencing this issue try this scratch build and report back? https://koji.fedoraproject.org/koji/taskinfo?taskID=79208076 Backing out the patch is not the optimal solution, as the patch does fix a real issue, so hopefully this is something that works for everyone.
I will test and report back as soon as it finishes downloading, it is taking a long time.
Hi, unfortunately that scratch build does not fix the issue. Same bug occurs.
Thank you for the report. I have forwarded the results upstream.
FEDORA-2021-c09b851eb0 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-c09b851eb0
FEDORA-2021-eab8c5a263 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-eab8c5a263
One more test kernel with a new patch from upstream if someone can please test and see if it fixes the issue: https://koji.fedoraproject.org/koji/taskinfo?taskID=79226775
@
(In reply to Justin M. Forbes from comment #23) No issue. 👍️
(In reply to Justin M. Forbes from comment #23) > One more test kernel with a new patch from upstream if someone can please > test and see if it fixes the issue: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=79226775 Hi, writing from this Kernel on bare-metal, it does solve the issue for me.
The latest scratch build fixes it for me also. Thanks. :)
Thank you for the feedback, I will ship 5.15.4-201 to stable with the original patch reverted, and should have both patches back in for 5.15.5
FEDORA-2021-c09b851eb0 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-c09b851eb0` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-c09b851eb0 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
So, 5.15.5 in F35 has the existing revert and not the new upstream patch, correct?
FEDORA-2021-c09b851eb0 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-eab8c5a263 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.