Skip to content
Snippets Groups Projects
  1. Aug 07, 2024
  2. Aug 02, 2024
  3. Apr 25, 2024
  4. Apr 19, 2024
  5. Mar 19, 2024
    • Simon McVittie's avatar
      pv-wrap: Try harder to get the initial LD_LIBRARY_PATH into pv-adverb · 13946a0c
      Simon McVittie authored
      
      If bwrap is setuid root, we were previously pushing LD_LIBRARY_PATH
      into it via bwrap --setenv, but it turns out that doesn't actually work:
      the fact that bwrap is setuid means that the environment variable won't
      stick. The result is that pv-adverb doesn't have the host system's glibc
      in its library search path and can't start.
      
      We can avoid this problem by using ld.so(8) to invoke pv-adverb with a
      specified search path, and then telling pv-adverb to finish setting up
      the environment before it runs ldconfig(8) to regenerate the ld.so.cache.
      
      Instead of second-guessing which environment variables glibc is going
      to filter out in setuid executables, we just serialize all of them -
      with `--env-fd` there's no longer any real reason not to.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      13946a0c
  6. Mar 13, 2024
  7. Feb 19, 2024
  8. Nov 02, 2023
  9. Oct 30, 2023
  10. Aug 30, 2023
  11. Feb 06, 2023
    • Ludovico de Nittis's avatar
      pressure-vessel: Reuse the drivers basename · c2fd0c62
      Ludovico de Nittis authored
      
      When creating the JSON manifests, we were simply naming them
      sequentially, as an easy way to avoid conflicts.
      
      However, since Vulkan Loader 1.3.234, it is possible to select which
      driver to use by listing their names in the environment variable
      `VK_LOADER_DRIVERS_SELECT`. This functionality would not work in
      pressure-vessel, unless we keep the original JSON manifest name.
      
      With this commit now we always reuse the JSON manifest basename.
      In the rare events where this could cause a conflict, we create
      unique sub directories to avoid issues.
      
      Signed-off-by: default avatarLudovico de Nittis <ludovico.denittis@collabora.com>
      c2fd0c62
  12. Oct 28, 2022
  13. Jun 21, 2022
  14. Apr 07, 2022
  15. Mar 31, 2022
  16. Jan 27, 2022
  17. Sep 20, 2021
    • Simon McVittie's avatar
      Avoid misleadingly-named g_spawn_check_exit_status() if possible · c507a0a2
      Simon McVittie authored
      
      g_spawn_check_exit_status() was renamed to g_spawn_check_wait_status()
      in GLib 2.70 because its name was misleading: the first argument was
      always a wait-status (the output of wait(), waitpid() or waitid(),
      encoding either an exit status or a terminating signal) rather than an
      exit status.
      
      Use the modern name in our code. When building for scout or
      continue to provide our own implementation; when building for anything
      else older than GLib 2.70, provide a macro to wrap the old, misleading
      name.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      c507a0a2
  18. Aug 06, 2021
  19. Aug 03, 2021
  20. Jul 20, 2021
    • Ludovico de Nittis's avatar
      Adjust LD_PRELOAD and LD_AUDIT to prevent ELF warnings · e7a5f274
      Ludovico de Nittis authored and Simon McVittie's avatar Simon McVittie committed
      
      When a game is launched with the Steam Overlay feature enabled (it's on
      by default), we end up with an LD_PRELOAD that contains
      `gameoverlayrenderer.so` two times, one for 32-bit and the other for
      64-bit processes.
      
      However this leads to a warning that is harmless but scary for users and
      developers unaware of that:
      `ERROR: ld.so: object
      '/home/me/.local/share/steam/ubuntu12_64/gameoverlayrenderer.so' from
      LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.`
      
      And every 64-bit process prints something similar about the ELFCLASS32.
      
      By creating a temporary directory and using the dynamic linker token
      expansion `$PLATFORM` we can let a process preload only the
      `gameoverlayrenderer.so` for the right ABI.
      
      Signed-off-by: default avatarLudovico de Nittis <ludovico.denittis@collabora.com>
      e7a5f274
  21. May 20, 2021
  22. May 12, 2021
  23. Apr 22, 2021
  24. Feb 26, 2021
    • Simon McVittie's avatar
      pressure-vessel: Put apt-style severity prefixes on messages · dbf21961
      Simon McVittie authored
      
      These indicate which lines are harmless and which lines are really bad,
      without taking up too much space.
      
      The mapping from GLib log level to message is not 100% obvious, because
      G_LOG_LEVEL_ERROR is "worse than" an error. We diagnose "can't happen"
      situations (assertion failures, etc.) as "Internal error". Ideally,
      users should never see these: they indicate a bug.
      
      For situations that will cause pressure-vessel to exit with an error,
      introduce a new log level flag PV_LOG_LEVEL_FAILURE and map it to the
      apt-style "E:" prefix. pv_log_failure() is a convenience macro to log
      at level PV_LOG_LEVEL_FAILURE. Conceptually this is a fatal error, but
      it's a fatal error prompted by something external to pressure-vessel,
      for which we want pressure-vessel to clean up "nicely" and exit
      gracefully, even though it's going to fail - so we can't use g_error()
      for this.
      
      In the parts of main() that involve parsing command-line arguments,
      add usage_error() as syntactic sugar for pv_log_failure(). I might
      eventually turn these into G_OPTION_ERROR_FAILED as we factor out
      more of main() into helper functions, but for now they're handled
      separately.
      
      For less-severe log levels, use single-letter prefixes similar to apt's.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      dbf21961
  25. Feb 25, 2021
  26. Feb 23, 2021
  27. Jan 13, 2021
  28. Jan 05, 2021
  29. 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
  30. Dec 10, 2020
  31. Dec 03, 2020
Loading