1. 07 Aug, 2014 1 commit
  2. 10 Jul, 2014 1 commit
  3. 07 Jul, 2014 2 commits
    • Anand Avati's avatar
      fuse: ignore entry-timeout on LOOKUP_REVAL · 154210cc
      Anand Avati authored
      
      
      The following test case demonstrates the bug:
      
        sh# mount -t glusterfs localhost:meta-test /mnt/one
      
        sh# mount -t glusterfs localhost:meta-test /mnt/two
      
        sh# echo stuff > /mnt/one/file; rm -f /mnt/two/file; echo stuff > /mnt/one/file
        bash: /mnt/one/file: Stale file handle
      
        sh# echo stuff > /mnt/one/file; rm -f /mnt/two/file; sleep 1; echo stuff > /mnt/one/file
      
      On the second open() on /mnt/one, FUSE would have used the old
      nodeid (file handle) trying to re-open it. Gluster is returning
      -ESTALE. The ESTALE propagates back to namei.c:filename_lookup()
      where lookup is re-attempted with LOOKUP_REVAL. The right
      behavior now, would be for FUSE to ignore the entry-timeout and
      and do the up-call revalidation. Instead FUSE is ignoring
      LOOKUP_REVAL, succeeding the revalidation (because entry-timeout
      has not passed), and open() is again retried on the old file
      handle and finally the ESTALE is going back to the application.
      
      Fix: if revalidation is happening with LOOKUP_REVAL, then ignore
      entry-timeout and always do the up-call.
      Signed-off-by: default avatarAnand Avati <avati@redhat.com>
      Reviewed-by: default avatarNiels de Vos <ndevos@redhat.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      Cc: stable@vger.kernel.org
      154210cc
    • Miklos Szeredi's avatar
      fuse: timeout comparison fix · 126b9d43
      Miklos Szeredi authored
      
      
      As suggested by checkpatch.pl, use time_before64() instead of direct
      comparison of jiffies64 values.
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      Cc: <stable@vger.kernel.org>
      126b9d43
  4. 28 Apr, 2014 7 commits
  5. 02 Apr, 2014 2 commits
    • Maxim Patlasov's avatar
      fuse: Trust kernel i_mtime only · b0aa7606
      Maxim Patlasov authored
      
      
      Let the kernel maintain i_mtime locally:
       - clear S_NOCMTIME
       - implement i_op->update_time()
       - flush mtime on fsync and last close
       - update i_mtime explicitly on truncate and fallocate
      
      Fuse inode flag FUSE_I_MTIME_DIRTY serves as indication that local i_mtime
      should be flushed to the server eventually.
      Signed-off-by: default avatarMaxim Patlasov <MPatlasov@parallels.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      b0aa7606
    • Pavel Emelyanov's avatar
      fuse: Trust kernel i_size only · 8373200b
      Pavel Emelyanov authored
      
      
      Make fuse think that when writeback is on the inode's i_size is always
      up-to-date and not update it with the value received from the userspace.
      This is done because the page cache code may update i_size without letting
      the FS know.
      
      This assumption implies fixing the previously introduced short-read helper --
      when a short read occurs the 'hole' is filled with zeroes.
      
      fuse_file_fallocate() is also fixed because now we should keep i_size up to
      date, so it must be updated if FUSE_FALLOCATE request succeeded.
      Signed-off-by: default avatarMaxim V. Patlasov <MPatlasov@parallels.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      8373200b
  6. 22 Jan, 2014 1 commit
  7. 25 Oct, 2013 1 commit
  8. 01 Oct, 2013 3 commits
  9. 12 Sep, 2013 1 commit
  10. 05 Sep, 2013 3 commits
  11. 03 Sep, 2013 3 commits
    • Miklos Szeredi's avatar
      fuse: readdir: check for slash in names · efeb9e60
      Miklos Szeredi authored
      
      
      Userspace can add names containing a slash character to the directory
      listing.  Don't allow this as it could cause all sorts of trouble.
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      Cc: stable@vger.kernel.org
      efeb9e60
    • Maxim Patlasov's avatar
      fuse: hotfix truncate_pagecache() issue · 06a7c3c2
      Maxim Patlasov authored
      
      
      The way how fuse calls truncate_pagecache() from fuse_change_attributes()
      is completely wrong. Because, w/o i_mutex held, we never sure whether
      'oldsize' and 'attr->size' are valid by the time of execution of
      truncate_pagecache(inode, oldsize, attr->size). In fact, as soon as we
      released fc->lock in the middle of fuse_change_attributes(), we completely
      loose control of actions which may happen with given inode until we reach
      truncate_pagecache. The list of potentially dangerous actions includes
      mmap-ed reads and writes, ftruncate(2) and write(2) extending file size.
      
      The typical outcome of doing truncate_pagecache() with outdated arguments
      is data corruption from user point of view. This is (in some sense)
      acceptable in cases when the issue is triggered by a change of the file on
      the server (i.e. externally wrt fuse operation), but it is absolutely
      intolerable in scenarios when a single fuse client modifies a file without
      any external intervention. A real life case I discovered by fsx-linux
      looked like this:
      
      1. Shrinking ftruncate(2) comes to fuse_do_setattr(). The latter sends
      FUSE_SETATTR to the server synchronously, but before getting fc->lock ...
      2. fuse_dentry_revalidate() is asynchronously called. It sends FUSE_LOOKUP
      to the server synchronously, then calls fuse_change_attributes(). The
      latter updates i_size, releases fc->lock, but before comparing oldsize vs
      attr->size..
      3. fuse_do_setattr() from the first step proceeds by acquiring fc->lock and
      updating attributes and i_size, but now oldsize is equal to
      outarg.attr.size because i_size has just been updated (step 2). Hence,
      fuse_do_setattr() returns w/o calling truncate_pagecache().
      4. As soon as ftruncate(2) completes, the user extends file size by
      write(2) making a hole in the middle of file, then reads data from the hole
      either by read(2) or mmap-ed read. The user expects to get zero data from
      the hole, but gets stale data because truncate_pagecache() is not executed
      yet.
      
      The scenario above illustrates one side of the problem: not truncating the
      page cache even though we should. Another side corresponds to truncating
      page cache too late, when the state of inode changed significantly.
      Theoretically, the following is possible:
      
      1. As in the previous scenario fuse_dentry_revalidate() discovered that
      i_size changed (due to our own fuse_do_setattr()) and is going to call
      truncate_pagecache() for some 'new_size' it believes valid right now. But
      by the time that particular truncate_pagecache() is called ...
      2. fuse_do_setattr() returns (either having called truncate_pagecache() or
      not -- it doesn't matter).
      3. The file is extended either by write(2) or ftruncate(2) or fallocate(2).
      4. mmap-ed write makes a page in the extended region dirty.
      
      The result will be the lost of data user wrote on the fourth step.
      
      The patch is a hotfix resolving the issue in a simplistic way: let's skip
      dangerous i_size update and truncate_pagecache if an operation changing
      file size is in progress. This simplistic approach looks correct for the
      cases w/o external changes. And to handle them properly, more sophisticated
      and intrusive techniques (e.g. NFS-like one) would be required. I'd like to
      postpone it until the issue is well discussed on the mailing list(s).
      
      Changed in v2:
       - improved patch description to cover both sides of the issue.
      Signed-off-by: default avatarMaxim Patlasov <mpatlasov@parallels.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      Cc: stable@vger.kernel.org
      06a7c3c2
    • Anand Avati's avatar
      fuse: invalidate inode attributes on xattr modification · d331a415
      Anand Avati authored
      
      
      Calls like setxattr and removexattr result in updation of ctime.
      Therefore invalidate inode attributes to force a refresh.
      Signed-off-by: default avatarAnand Avati <avati@redhat.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      Cc: stable@vger.kernel.org
      d331a415
  12. 17 Jul, 2013 5 commits
  13. 29 Jun, 2013 1 commit
  14. 03 Jun, 2013 1 commit
    • Miklos Szeredi's avatar
      fuse: fix readdirplus Oops in fuse_dentry_revalidate · 28420dad
      Miklos Szeredi authored
      Fix bug introduced by commit 4582a4ab
      
       "FUSE: Adapt readdirplus to application
      usage patterns".
      
      We need to check for a positive dentry; negative dentries are not added by
      readdirplus.  Secondly we need to advise the use of readdirplus on the *parent*,
      otherwise the whole thing is useless.  Thirdly all this is only relevant if
      "readdirplus_auto" mode is selected by the filesystem.
      
      We advise the use of readdirplus only if the dentry was still valid.  If we had
      to redo the lookup then there was no use in doing the -plus version.
      Reported-by: default avatarBernd Schubert <bernd.schubert@itwm.fraunhofer.de>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      CC: Feng Shuo <steve.shuo.feng@gmail.com>
      CC: stable@vger.kernel.org
      28420dad
  15. 18 Apr, 2013 1 commit
  16. 23 Feb, 2013 1 commit
  17. 07 Feb, 2013 1 commit
    • Eric Wong's avatar
      fuse: allow control of adaptive readdirplus use · 634734b6
      Eric Wong authored
      
      
      For some filesystems (e.g. GlusterFS), the cost of performing a
      normal readdir and readdirplus are identical.  Since adaptively
      using readdirplus has no benefit for those systems, give
      users/filesystems the option to control adaptive readdirplus use.
      
      v2 of this patch incorporates Miklos's suggestion to simplify the code,
      as well as improving consistency of macro names and documentation.
      Signed-off-by: default avatarEric Wong <normalperson@yhbt.net>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      634734b6
  18. 04 Feb, 2013 1 commit
  19. 31 Jan, 2013 2 commits
  20. 24 Jan, 2013 2 commits
    • Maxim Patlasov's avatar
      fuse: use req->page_descs[] for argpages cases · 85f40aec
      Maxim Patlasov authored
      
      
      Previously, anyone who set flag 'argpages' only filled req->pages[] and set
      per-request page_offset. This patch re-works all cases where argpages=1 to
      fill req->page_descs[] properly.
      
      Having req->page_descs[] filled properly allows to re-work fuse_copy_pages()
      to copy page fragments described by req->page_descs[]. This will be useful
      for next patches optimizing direct_IO.
      Signed-off-by: default avatarMaxim Patlasov <mpatlasov@parallels.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      85f40aec
    • Maxim Patlasov's avatar
      fuse: categorize fuse_get_req() · b111c8c0
      Maxim Patlasov authored
      
      
      The patch categorizes all fuse_get_req() invocations into two categories:
       - fuse_get_req_nopages(fc) - when caller doesn't care about req->pages
       - fuse_get_req(fc, n) - when caller need n page pointers (n > 0)
      
      Adding fuse_get_req_nopages() helps to avoid numerous fuse_get_req(fc, 0)
      scattered over code. Now it's clear from the first glance when a caller need
      fuse_req with page pointers.
      
      The patch doesn't make any logic changes. In multi-page case, it silly
      allocates array of FUSE_MAX_PAGES_PER_REQ page pointers. This will be amended
      by future patches.
      Signed-off-by: default avatarMaxim Patlasov <mpatlasov@parallels.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      b111c8c0