Skip to content
Snippets Groups Projects
  1. Jan 05, 2021
  2. Dec 17, 2020
    • Simon McVittie's avatar
      pressure-vessel: Let short-term subprocesses inherit non-CLOEXEC fds · 97b5a8f6
      Simon McVittie authored
      To work around older versions of GLib having a potential deadlock in
      their fd-closing code due to use of non-async-signal-safe functions
      in the forked child process, the Flatpak-derived code we're using here
      uses a simple, naive implementation of closing fds: it iterates through
      every possible fd, up to the rlimit.
      
      Unfortunately, Wine users sometimes set their fd rlimit very high
      (typically around a million), because the "esync" mechanism in Proton's
      Wine needs a lot of fds. The time taken by each individual syscall is
      not significant, but when we do a million of them, it adds up. This
      is arguably a misconfiguration - the recommendation is now to have a
      soft rlimit of 1024 and a hard rlimit of about a million, so that
      only processes that opt-in to dealing with a million fds have to be
      aware of them - but a significant number of misconfigured systems
      probably still exist.
      
      We don't actually *need* to close all the fds here: there's no security
      boundary, so giving the child access to unnecessary fds isn't a
      privilage gain; the parent process outlives the child, so leaking
      fds won't result in them never being closed; and in any case we're
      reasonably careful to set CLOEXEC on all our fds. So let's just not
      close them.
      
      In particular, this can save literally a million syscalls per helper
      subprocess invocation (it's not often I get to say that!), reducing
      pressure-vessel-wrap launch time by 90% on a system with the high fd
      limit (about 70 seconds down to 7). With the recommended soft limit of
      1024, the speedup is less dramatic, but it still takes off nearly 10%
      (about 6 down to 5.5).
      
      Resolves: https://github.com/ValveSoftware/steam-runtime/issues/323
      
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      97b5a8f6
  3. Dec 15, 2020
    • Ludovico de Nittis's avatar
      runtime: correctly handle ICD for different ABI even without subdirs · b099b960
      Ludovico de Nittis authored
      
      Previously we used the empty directory as an indicator that the capture
      of the library failed, but this worked only if we always started with an
      empty directory. And this is not the case when we are not using a
      subdir.
      
      For this reason, even if the capture of a library failed, we didn't set
      its "kinds" to "NONEXISTENT", and this could have leaded to errors like
      having duplicated Vulkan implicit layer JSON for the same name and
      different "library_path", one pointing to the correct ABI and the other
      to the wrong one.
      
      Fixes: #45
      
      Signed-off-by: default avatarLudovico de Nittis <ludovico.denittis@collabora.com>
      b099b960
  4. Dec 14, 2020
  5. Dec 11, 2020
  6. Dec 10, 2020
  7. Dec 09, 2020
    • Simon McVittie's avatar
      pressure-vessel: Make graphics drivers outside $HOME available, if used · 23834972
      Simon McVittie authored
      Since !173, we have been able to create symbolic links to graphics
      drivers anywhere on the filesystem, but that didn't mean the graphics
      driver would necessarily be usable, because the directory containing it
      would not necessarily be visible in the container. Add these directories
      to the list of directories to be "exported".
      
      Manual test (Debian on on Intel hardware, adjust as required for
      others):
      
      * Modify /usr/share/vulkan/icd.d/intel_icd.i686.json
        to use /opt/moved-from-usr/lib/i386-linux-gnu/libvulkan_intel.so
      * Move the real i386 libvulkan_intel.so to that location
      * ./run --verbose -- steam-runtime-system-info 2>&1 | tee container.log
      
      Resolves: #29
      Resolves: https://github.com/ValveSoftware/steam-runtime/issues/313
      
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      23834972
  8. Dec 08, 2020
  9. Dec 04, 2020
  10. Dec 03, 2020
Loading