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 10, 2020
  4. 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
  5. Dec 08, 2020
  6. Dec 03, 2020
  7. Nov 30, 2020
  8. Nov 24, 2020
  9. Nov 17, 2020
    • Simon McVittie's avatar
      bwrap: Don't bind-mount files into /etc as part of binding /usr · 23035e38
      Simon McVittie authored
      
      If we want to deal with strange operating systems that use a non-standard
      filename for ld.so.cache, we'll have to special-case it. There's
      little extra cost to doing this because we already need to understand
      how ld.so.cache works, to be able to generate our own with different
      search paths.
      
      In situations where we just want a quick container to be able to inspect
      the runtime, we can deal with this by mounting all of /etc read-only.
      
      For the final container, we already iterate over all the files in the
      runtime's /etc, which will "naturally" include ld.so.cache and
      alternatives.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      23035e38
  10. Oct 26, 2020
  11. Oct 22, 2020
    • Simon McVittie's avatar
      pressure-vessel: Disable GIO modules differently · 92b1c2b6
      Simon McVittie authored
      
      Now that GIO_MODULE_DIR has been backported into scout's GLib, we can
      disable GIO modules completely, instead of loading them but then not
      using them. This avoids some misleading warnings (#32).
      
      This will not be completely effective on non-Debian systems until we
      also patch scout's GLib to make GIO_MODULE_DIR take precedence over
      the hard-coded legacy search path /usr/lib/gio/modules.
      
      The unit test for this is still in tests/pressure-vessel/utils.c
      for now.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      92b1c2b6
  12. Oct 19, 2020
  13. Oct 06, 2020
  14. Oct 01, 2020
  15. Sep 30, 2020
  16. Sep 28, 2020
  17. Sep 25, 2020
  18. Sep 09, 2020
  19. Sep 08, 2020
  20. Sep 07, 2020
  21. Sep 04, 2020
Loading