Skip to content
Snippets Groups Projects
  1. 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
  2. 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
  3. Oct 06, 2020
  4. Sep 28, 2020
  5. Sep 25, 2020
  6. Sep 09, 2020
  7. Sep 08, 2020
  8. Sep 07, 2020
    • Simon McVittie's avatar
      wrap, adverb: Move "wrap with xterm" code into the adverb · 5dd3b8aa
      Simon McVittie authored
      
      Looking at environment variables is still part of pv-wrap, but the
      command-line part now happens in pv-adverb. This means the launching
      scripts for the "session" mode, which use pv-launch to run the main
      game command in a previously-set-up pv-launcher environment, can
      direct pv-adverb to run an interactive shell instead of or in addition
      to the actual game.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      5dd3b8aa
  9. Sep 04, 2020
  10. Aug 18, 2020
  11. Aug 05, 2020
  12. Aug 04, 2020
  13. Jul 29, 2020
  14. Jul 21, 2020
  15. Jun 12, 2020
  16. Jan 23, 2020
  17. Jan 06, 2020
    • Simon McVittie's avatar
      bwrap-lock: Add support for OFD locks · 4ad7b057
      Simon McVittie authored
      
      These more modern locks, introduced in Linux 3.15 and not yet included
      in POSIX, propagate across fork(), dup(), fd-passing etc. the way you'd
      expect: as long as at least one copy of the inherited or fd-passed file
      descriptor remains open, the lock remains held. This allows us to
      pass a lock fd to a child process across bwrap's fork-and-exec the way
      we were already trying to, and have it actually work.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      4ad7b057
  18. Nov 14, 2019
Loading