1. 16 Jun, 2023 2 commits
    • Kirill Smelkov's avatar
      fuse: Print debug flags in stable order · d5638ffd
      Kirill Smelkov authored
      This helps to compare fuse logs of e.g. different test runs. For example
      below are two INIT messages with the same flags, but formatted, before
      hereby patch, differently:
      
           rx 2: INIT n0 {7.37 Ra 131072 EXPORT_SUPPORT,SPLICE_READ,AUTO_INVAL_DATA,ASYNC_DIO,WRITEBACK_CACHE,BIG_WRITES,NO_OPEN_SUPPORT,PARALLEL_DIROPS,POSIX_ACL,EXPLICIT_INVAL_DATA,NO_OPENDIR_SUPPORT,ASYNC_READ,DONT_MASK,SPLICE_MOVE,IOCTL_DIR,READDIRPLUS,READDIRPLUS_AUTO,HANDLE_KILLPRIV,POSIX_LOCKS,ATOMIC_O_TRUNC,SPLICE_WRITE,FLOCK_LOCKS,ABORT_ERROR,MAX_PAGES,CACHE_SYMLINKS,0x70000000} "\x03\x00\x00\x00\x00\x00\x00\x00"... 48b
      
           rx 2: INIT n0 {7.37 Ra 131072 EXPORT_SUPPORT,SPLICE_READ,AUTO_INVAL_DATA,ASYNC_DIO,WRITEBACK_CACHE,BIG_WRITES,NO_OPEN_SUPPORT,PARALLEL_DIROPS,POSIX_ACL,EXPLICIT_INVAL_DATA,ASYNC_READ,DONT_MASK,SPLICE_MOVE,IOCTL_DIR,READDIRPLUS,READDIRPLUS_AUTO,HANDLE_KILLPRIV,NO_OPENDIR_SUPPORT,POSIX_LOCKS,ATOMIC_O_TRUNC,SPLICE_WRITE,FLOCK_LOCKS,ABORT_ERROR,MAX_PAGES,CACHE_SYMLINKS,0x70000000} "\x03\x00\x00\x00\x00\x00\x00\x00"... 48b
      
      which leads to corresponding lines to be present in the diff and
      requires human attention to verify that the messages are really the
      same.
      
      After this patch above INIT always formats as
      
           rx 2: INIT n0 {7.37 Ra 131072 ASYNC_READ,POSIX_LOCKS,ATOMIC_O_TRUNC,EXPORT_SUPPORT,BIG_WRITES,DONT_MASK,SPLICE_WRITE,SPLICE_MOVE,SPLICE_READ,FLOCK_LOCKS,IOCTL_DIR,AUTO_INVAL_DATA,READDIRPLUS,READDIRPLUS_AUTO,ASYNC_DIO,WRITEBACK_CACHE,NO_OPEN_SUPPORT,PARALLEL_DIROPS,HANDLE_KILLPRIV,POSIX_ACL,ABORT_ERROR,MAX_PAGES,CACHE_SYMLINKS,NO_OPENDIR_SUPPORT,EXPLICIT_INVAL_DATA,0x70000000} "\x03\x00\x00\x00\x00\x00\x00\x00"... 48b
      
      and the diff log does not unnecessarily distract attention to it.
      
      flagString is used for many messages, this fix should benefit all of
      them.
      
      Change-Id: Id4bdab9dd90552313ede41a3b9a6c337588e4b3e
      d5638ffd
    • Han-Wen Nienhuys's avatar
      fs: increase the limit for TestFileFdLeak · 9836d614
      Han-Wen Nienhuys authored
      The RELEASE opcode is asynchronous, so the next open() call may
      execute before the RELEASE for the preceding one has completed. In
      case of GOMAXPROCS=1, this happens often.
      
      Increase the limit to 15 to reduce the chance of this causing a test
      failure. The test runs 100 times, so this should still catch logic
      errors with deallocating file handles.
      
      Fixes #477.
      
      Change-Id: I12dbd96b2a6082e0f4a386d35983e6efcc596aef
      9836d614
  2. 14 Jun, 2023 1 commit
    • Kirill Smelkov's avatar
      fuse/test: Fix TestLargeDirRead · e5b78843
      Kirill Smelkov authored
      This test tries to create many files with random names and then asserts
      that readdir returns so many files that it created. But the test
      had a bug in that two random file names could be the same
      name but accounted twice. This leads to assertion in the end that the
      number of direntries read via readdir is not as expected.
      
      Here is how two random names could turn out to be the same:
      
      name 1: "file3" + "0" generated by randomLengthString
      name 2: "file30" + "" generated by randomLengthString
      
      -> Fix it by constructing random names guaranteed different.
      
      Fixes: https://github.com/hanwen/go-fuse/issues/472
      Change-Id: I776866bd728479da7324878d41dc71e504efd229
      e5b78843
  3. 12 Jun, 2023 2 commits
  4. 11 Jun, 2023 1 commit
    • Kirill Smelkov's avatar
      fuse/test: Fix TestFopenKeepCache, take 2 · d2138350
      Kirill Smelkov authored
      In 2019 TestOpenKeepCache was first disabled in ce2558b4 (fuse/test:
      disable TestFopenKeepCache) and then reenabled in 904ef0cc (fuse/test:
      Fix TestFopenKeepCache). The latter patch hoped to fix this test
      
          - by disabling CAP_AUTO_INVAL_DATA via ExplicitDataCacheControl. This
            should stop kernel from dropping data cache on mtime change;
          - by using the same size for before and after states. This avoid hitting
            cache being dropped when kernel sees file size being changed.
      
      In other words it took actions so that the data cache is not
      unexpectedly dropped by the kernel and the test does not fail with
      seeing different content after file reopen.
      
      However the test also wants to verify that updated data can be seen
      after cache invalidation and here it was not exactly correct: the test
      requested full control over the data cache via ExplicitDataCacheControl
      mount option, but was explicitly invalidating only file attributes
      via pathfs.EntryNotify _without_ invalidating the data cache.
      
      This way the test was actually working before Linux 5.2, because those
      older kernels never negotiate CAP_EXPLICIT_INVAL_DATA(*), but starting
      from Linux 5.2 CAP_EXPLICIT_INVAL_DATA started to be negotiated, and so
      the kernel was dropping only metadata without invalidating data cache on
      EntryNotify. This started to lead to the following test failures:
      
          --- FAIL: TestFopenKeepCache (0.13s)
              cache_test.go:153: ReadFile: got "before" after notify, want "afterX"
      
      @hanwen explains in https://github.com/hanwen/go-fuse/issues/473#issuecomment-1585617107
      
          It tries to invalidate the file content by issuing an ENTRY_NOTIFY. This
          leads to different mtime returned, but in the init phase, we don´t
          return AUTO_INVAL_DATA, because setupCacheTest explicitly disables it.
      
          === RUN   TestFopenKeepCache
          12:47:49.958227 callFusermount: executing ["/usr/bin/fusermount3" "/tmp/TestFopenKeepCache1094589261/001/mnt" "-o" "subtype=pathfs.pathInode,max_read=131072"]
          12:47:49.967664 rx 2: INIT n0 {7.38 Ra 131072 FLOCK_LOCKS,IOCTL_DIR,READDIRPLUS,READDIRPLUS_AUTO,PARALLEL_DIROPS,HANDLE_KILLPRIV,ASYNC_READ,BIG_WRITES,SPLICE_WRITE,SPLICE_MOVE,WRITEBACK_CACHE,NO_OPEN_SUPPORT,POSIX_ACL,POSIX_LOCKS,EXPORT_SUPPORT,AUTO_INVAL_DATA,ASYNC_DIO,MAX_PAGES,CACHE_SYMLINKS,NO_OPENDIR_SUPPORT,DONT_MASK,SPLICE_READ,ABORT_ERROR,EXPLICIT_INVAL_DATA,ATOMIC_O_TRUNC,0x70000000} "\a\x00\x00\x00\x00\x00\x00\x00"... 48b
          12:47:49.967708 tx 2:     OK, {7.28 Ra 131072 BIG_WRITES,NO_OPEN_SUPPORT,MAX_PAGES,EXPLICIT_INVAL_DATA,ASYNC_READ,READDIRPLUS,PARALLEL_DIROPS 0/0 Wr 131072 Tg 0 MaxPages 32}
      
      -> Let's fix this.
      
      As explained in 904ef0cc we do not want to reenable AUTO_INVAL_DATA
      because then the kernel will start dropping data cache on mtime change
      and the test will start to fail in its first part - where we want to
      assert that the data stays the same until data cache is invalidated.
      
      So let's change EntryNotify to FileNotify to explicitly invalidate data
      cache when we want the file to read with new data.
      
      Hopefully fixes: https://github.com/hanwen/go-fuse/issues/473
      
      (*) see git.kernel.org/linus/ad2ba64dd489 and github.com/hanwen/go-fuse/pull/273
      
      Change-Id: I4ff0f2bef61f0217601eee6d272f7e5563b272d2
      d2138350
  5. 09 Jun, 2023 2 commits
  6. 08 Jun, 2023 2 commits
  7. 07 Jun, 2023 1 commit
  8. 25 May, 2023 1 commit
  9. 18 May, 2023 2 commits
  10. 26 Apr, 2023 1 commit
  11. 23 Apr, 2023 2 commits
  12. 21 Apr, 2023 2 commits
    • Jakob Unterwurzacher's avatar
      .github: set user_allow_other in /etc/fuse.conf · 652da3f9
      Jakob Unterwurzacher authored
      Fixes this test failure:
      
      2023/04/13 20:25:20 callFusermount: executing ["/usr/bin/fusermount3" "/tmp/TestDirectMount4166040800" "-o" "allow_other,subtype=/tmp/go-build1065896,max_read=131072"]
      /usr/bin/fusermount3: option allow_other only allowed if 'user_allow_other' is set in /etc/fuse.conf
      
      \--- FAIL: TestDirectMount (0.01s)
          mount_linux_test.go:117: fusermount exited with code 256
      
      Change-Id: I4a2a2983dd422de9360b17068ac0d8a3947d453d
      652da3f9
    • Han-Wen Nienhuys's avatar
      .github: drop Go 1.13 / 1.15, add Go 1.18/1.19 · 1e62711b
      Han-Wen Nienhuys authored
      Change-Id: Ifb84efcb76615cc492c867afb9e1840a6977d402
      1e62711b
  13. 12 Apr, 2023 2 commits
  14. 10 Apr, 2023 5 commits
  15. 09 Apr, 2023 1 commit
    • Han-Wen Nienhuys's avatar
      fs: buffer error in directory reads · 17756c7c
      Han-Wen Nienhuys authored
      Previously, if a DirStream.Next() call would return error, we would
      return the buffered data as well as the errno code in the same
      request.
      
      This would confuse the kernel, who interprets this as an invalid
      response, returning syscall.EIO to the caller.
      
      To fix this, also buffer the errno as overflow entry in the fileEntry
      struct. When we encounter an error, return thus far read entries with
      success. The following read contains just the error.
      
      For testing this properly, loopbackDirStream (which reads directory
      contents) must also buffer error returns.
      
      Change-Id: Ideb8ea6f540de9189a0f366efca0db2205e5dec3
      17756c7c
  16. 07 Apr, 2023 7 commits
  17. 05 Apr, 2023 1 commit
  18. 29 Mar, 2023 1 commit
  19. 23 Mar, 2023 1 commit
  20. 19 Mar, 2023 2 commits
  21. 21 Feb, 2023 1 commit