1. 23 Aug, 2024 3 commits
  2. 16 Aug, 2024 1 commit
  3. 15 Aug, 2024 3 commits
  4. 28 May, 2024 2 commits
  5. 18 May, 2024 2 commits
  6. 15 May, 2024 4 commits
  7. 12 May, 2024 1 commit
  8. 01 May, 2024 2 commits
  9. 30 Apr, 2024 1 commit
  10. 21 Apr, 2024 1 commit
    • lch's avatar
      posixtest: fix building of tests · 8d89f3cd
      lch authored
      Prefer x/sys/unix over syscall package, which supports FreeBSD.
      
      Change-Id: Ifd3a0fd6d2b90369a6e1e74d92606a655815a6a4
      8d89f3cd
  11. 20 Apr, 2024 2 commits
  12. 14 Apr, 2024 2 commits
  13. 12 Apr, 2024 5 commits
  14. 08 Apr, 2024 3 commits
  15. 25 Mar, 2024 2 commits
  16. 24 Mar, 2024 1 commit
    • Han-Wen Nienhuys's avatar
      fuse: fix deadlock with parallel mounts · 36b35911
      Han-Wen Nienhuys authored
      Commit 1aa7b7b2 ("fs: document known deadlocks") describes a deadlock
      scenario where inheriting file descriptors triggers a spurious close
      during subprocess setup, leading to deadlock.
      
      This exact scenario actually happens when setting up the FUSE mount
      using fusermount: the fusermount process inherits one half of a socket
      pair, which is used to pass back the opened /dev/fuse file.  After the
      mount is successful, we open a file in the FUSE mount for the poll
      hack. This means that in parallel scenarios, we may use fd 3 as the
      poll hack, while also calling fusermount with inherited file
      descriptors.
      
      Solve this by grabbing fd 3 during initialization.
      
      This is not completely foolproof, as FD 0, 1 and 2 could be closed
      (and then reused) after initialization finished, but this should be
      uncommon as 0, 1 and 2 are standard input/output/error.
      
      Doing it during the init phase means that we prevent deadlock for all
      users that inherit single file descriptors.
      
      Change-Id: If5ac7c941f0ee2e13ca657c31d056a676eed3fde
      36b35911
  17. 09 Feb, 2024 1 commit
    • Han-Wen Nienhuys's avatar
      fuse: don't set flagname keyed by syscall.O_LARGEFILE · e9e7c22a
      Han-Wen Nienhuys authored
      On amd64, syscall.O_LARGEFILE is 0x0, making it be ignored as a
      key. However, the kernel always passes 0x8000 to the FUSE server for
      the OPEN call.
      
      The previous behavior causes crashes on 386, because the flagname is
      added twice.
      
      Change-Id: Ibabcdfef4d90e4fa4d02963d45a4d4cf2cba1ea2
      e9e7c22a
  18. 20 Nov, 2023 1 commit
  19. 13 Nov, 2023 2 commits
  20. 10 Nov, 2023 1 commit