fcntl(F_ADD_SEALS): Device or resource busy

[aanno]

Linux distribution and version

$ lsb_release -a
LSB Version: :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch
Distributor ID: Fedora
Description: Fedora release 31 (Thirty One)
Release: 31
Codename: ThirtyOne

Flatpak version

$ rpm -qa flatpak
flatpak-1.4.3-3.fc31.x86_64

Description of the problem

Can't start/run/use any app installed with flatpak. E.g. org.signal.Signal:

$ flatpak  -v  run org.signal.Signal
F: No installations directory in /etc/flatpak/installations.d. Skipping
F: Opening system flatpak installation at path /var/lib/flatpak
F: Opening user flatpak installation at path /mnt/home/tpasch/.local/share/flatpak
F: Opening user flatpak installation at path /mnt/home/tpasch/.local/share/flatpak
F: Opening system flatpak installation at path /var/lib/flatpak
F: Opening user flatpak installation at path /mnt/home/tpasch/.local/share/flatpak
F: Opening system flatpak installation at path /var/lib/flatpak
Fehler: fcntl(F_ADD_SEALS): Device or resource busy

Steps to reproduce

Should be a problem on all fedora systems. Maybe the culprit is the nvidia driver (which I have to use).

$ rpm -qa nvidia-driver
nvidia-driver-440.59-1.fc31.x86_64

$ flatpak list
Name                                   Application ID                    Version   Zweig  Ursprung      Installation
Freedesktop.org Application Platform … org.freedesktop.Platform          1.6       1.6    flathub       system
Freedesktop Platform                   org.freedesktop.Platform          18.08.39  18.08  flathub       system
Freedesktop Platform                   org.freedesktop.Platform          19.08.7   19.08  flathub       system
default                                ….freedesktop.Platform.GL.default           19.08  flathub       system
Intel VAAPI Driver                     …freedesktop.Platform.VAAPI.Intel           1.6    flathub       system
Intel                                  …freedesktop.Platform.VAAPI.Intel           18.08  flathub       system
Intel                                  …freedesktop.Platform.VAAPI.Intel           19.08  flathub       system
FFmpeg extension                       org.freedesktop.Platform.ffmpeg             1.6    flathub       system
ffmpeg-full                            …freedesktop.Platform.ffmpeg-full           19.08  flathub       system
html5-codecs                           …reedesktop.Platform.html5-codecs           18.08  flathub       system
Freedesktop SDK                        org.freedesktop.Sdk               18.08.39  18.08  flathub       system
Adwaita theme                          org.kde.KStyle.Adwaita                      5.12   flathub       system
Adwaita theme                          org.kde.KStyle.Adwaita                      5.13   flathub       system
KDE Application Platform               org.kde.Platform                            5.12   flathub       system
KDE Application Platform               org.kde.Platform                            5.13   flathub       system
digiKam                                org.kde.digikam                             master kdeapps       system
Signal                                 org.signal.Signal                 1.30.1    stable signal-origin system
Telegram Desktop                       org.telegram.desktop              1.9.9     stable flathub       system
Kodi                                   tv.kodi.Kodi                      18.5-Leia stable kodi-origin   system

[aanno]

Also see my fedora issue at https://bugzilla.redhat.com/show_bug.cgi?id=1747363

[alexlarsson]

This is really weird. I've never seen it (and i'm on f31 with nvidia drivers).
Can you run something like strace -o signal.log -f -y flatpak -v run org.signal.Signal and attach the signal.log file here?

[aanno]

Certainly.
signal.log.gz

[alexlarsson]

This is the failing part:

20325 memfd_create("ld-so-conf", MFD_CLOEXEC|MFD_ALLOW_SEALING) = 17</memfd:ld-so-conf (deleted)>
20325 ftruncate(17</memfd:ld-so-conf (deleted)>, 41) = 0
20325 write(17</memfd:ld-so-conf (deleted)>, "/usr/lib/x86_64-linux-gnu/GL/def"..., 41) = 41
20325 lseek(17</memfd:ld-so-conf (deleted)>, 0, SEEK_SET) = 0
20325 fcntl(17</memfd:ld-so-conf (deleted)>, F_ADD_SEALS, F_SEAL_SEAL|F_SEAL_SHRINK|F_SEAL_GROW|F_SEAL_WRITE) = -1 EBUSY (Device or resource busy)

I have no idea why this would ever fail. It is purely an in-memory operation, no "device" or "resources" are involved.

[alexlarsson]

Oh:

       EBUSY  cmd is F_ADD_SEALS, arg includes F_SEAL_WRITE, and there
              exists a writable, shared mapping on the file referred to by
              fd.

[alexlarsson]

But how could there be a mapping? We just created it and we didn't map it!

[alexlarsson]

Just to isolate this, any chance you could boot into text-mode without the nvidia driver and see if this is reproducible?

[aanno]

Well, as far as I can tell it's the same without nvidia stuff (text mode, no Xorg/sddm):

signal-no-nvidia.log.gz

The only other 'special' thing about the system is that I'm using stratisd on LUKS for /home (and stratisd is used for SSD caching a HDD).

[aanno]

The problem is still there on fedora 32.

[candide-guevara]

I noticed you get this problem if you have transparent huge pages always enabled for shmem.
What is the output of cat /sys/kernel/mm/transparent_hugepage/shmem_enabled ?
If set to always, the following will always fail with EBUSY

void
buffer_to_sealed_memfd_or_tmpfile2 (const char  *name,
                                   const char  *content,
                                   size_t       len)
{
  int memfd = memfd_create (name, MFD_CLOEXEC | MFD_ALLOW_SEALING);
  ftruncate (memfd, len);
  write (memfd, content, len);
  lseek (memfd, 0, SEEK_SET);
  errno = 0;
  fcntl (memfd, F_ADD_SEALS, F_SEAL_SHRINK | F_SEAL_GROW | F_SEAL_WRITE | F_SEAL_SEAL);
  perror("fcntl result: ");
}

[aanno]

The problem is still there on fedora 33.

$ cat /sys/kernel/mm/transparent_hugepage/shmem_enabled
[always] within_size advise never deny force

So, candide-guevara is right: on my machine it is set to always.

[aanno]

If I set the parameter to within_size, I can run Signal without problem!

$ cat /sys/kernel/mm/transparent_hugepage/shmem_enabled
always [within_size] advise never deny force
$ flatpak  -v  run org.signal.Signal
# Working now...

[0n-s]

Is this problem still reproducible? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f2b277c4d1c63a85127e8aa2588e9cc3bd21cb99 should have fixed it (it did for me).