1. 01 Oct, 2013 1 commit
    • Miklos Szeredi's avatar
      fuse: readdirplus: fix RCU walk · 6314efee
      Miklos Szeredi authored
      
      
      Doing dput(parent) is not valid in RCU walk mode.  In RCU mode it would
      probably be okay to update the parent flags, but it's actually not
      necessary most of the time...
      
      So only set the FUSE_I_ADVISE_RDPLUS flag on the parent when the entry was
      recently initialized by READDIRPLUS.
      
      This is achieved by setting FUSE_I_INIT_RDPLUS on entries added by
      READDIRPLUS and only dropping out of RCU mode if this flag is set.
      FUSE_I_INIT_RDPLUS is cleared once the FUSE_I_ADVISE_RDPLUS flag is set in
      the parent.
      Reported-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      Cc: stable@vger.kernel.org
      6314efee
  2. 03 Sep, 2013 1 commit
    • 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
  3. 01 May, 2013 1 commit
  4. 18 Apr, 2013 1 commit
  5. 17 Apr, 2013 4 commits
    • Maxim Patlasov's avatar
      fuse: make fuse_direct_io() aware about AIO · 36cf66ed
      Maxim Patlasov authored
      
      
      The patch implements passing "struct fuse_io_priv *io" down the stack up to
      fuse_send_read/write where it is used to submit request asynchronously.
      io->async==0 designates synchronous processing.
      
      Non-trivial part of the patch is changes in fuse_direct_io(): resources
      like fuse requests and user pages cannot be released immediately in async
      case.
      Signed-off-by: default avatarMaxim Patlasov <mpatlasov@parallels.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      36cf66ed
    • Maxim Patlasov's avatar
      fuse: add support of async IO · 01e9d11a
      Maxim Patlasov authored
      
      
      The patch implements a framework to process an IO request asynchronously. The
      idea is to associate several fuse requests with a single kiocb by means of
      fuse_io_priv structure. The structure plays the same role for FUSE as 'struct
      dio' for direct-io.c.
      
      The framework is supposed to be used like this:
       - someone (who wants to process an IO asynchronously) allocates fuse_io_priv
         and initializes it setting 'async' field to non-zero value.
       - as soon as fuse request is filled, it can be submitted (in non-blocking way)
         by fuse_async_req_send()
       - when all submitted requests are ACKed by userspace, io->reqs drops to zero
         triggering aio_complete()
      
      In case of IO initiated by libaio, aio_complete() will finish processing the
      same way as in case of dio_complete() calling aio_complete(). But the
      framework may be also used for internal FUSE use when initial IO request
      was synchronous (from user perspective), but it's beneficial to process it
      asynchronously. Then the caller should wait on kiocb explicitly and
      aio_complete() will wake the caller up.
      Signed-off-by: default avatarMaxim Patlasov <mpatlasov@parallels.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      01e9d11a
    • Maxim Patlasov's avatar
      fuse: add flag fc->initialized · 796523fb
      Maxim Patlasov authored
      
      
      Existing flag fc->blocked is used to suspend request allocation both in case
      of many background request submitted and period of time before init_reply
      arrives from userspace. Next patch will skip blocking allocations of
      synchronous request (disregarding fc->blocked). This is mostly OK, but
      we still need to suspend allocations if init_reply is not arrived yet. The
      patch introduces flag fc->initialized which will serve this purpose.
      Signed-off-by: default avatarMaxim Patlasov <mpatlasov@parallels.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      796523fb
    • Maxim Patlasov's avatar
      fuse: make request allocations for background processing explicit · 8b41e671
      Maxim Patlasov authored
      
      
      There are two types of processing requests in FUSE: synchronous (via
      fuse_request_send()) and asynchronous (via adding to fc->bg_queue).
      
      Fortunately, the type of processing is always known in advance, at the time
      of request allocation. This preparatory patch utilizes this fact making
      fuse_get_req() aware about the type. Next patches will use it.
      Signed-off-by: default avatarMaxim Patlasov <mpatlasov@parallels.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      8b41e671
  6. 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
  7. 31 Jan, 2013 2 commits
  8. 24 Jan, 2013 5 commits
    • Miklos Szeredi's avatar
      fuse: cleanup fuse_direct_io() · fb05f41f
      Miklos Szeredi authored
      
      
      Fix the following sparse warnings:
      
      fs/fuse/file.c:1216:43: warning: cast removes address space of expression
      fs/fuse/file.c:1216:43: warning: incorrect type in initializer (different address spaces)
      fs/fuse/file.c:1216:43:    expected void [noderef] <asn:1>*iov_base
      fs/fuse/file.c:1216:43:    got void *<noident>
      fs/fuse/file.c:1241:43: warning: cast removes address space of expression
      fs/fuse/file.c:1241:43: warning: incorrect type in initializer (different address spaces)
      fs/fuse/file.c:1241:43:    expected void [noderef] <asn:1>*iov_base
      fs/fuse/file.c:1241:43:    got void *<noident>
      fs/fuse/file.c:1267:43: warning: cast removes address space of expression
      fs/fuse/file.c:1267:43: warning: incorrect type in initializer (different address spaces)
      fs/fuse/file.c:1267:43:    expected void [noderef] <asn:1>*iov_base
      fs/fuse/file.c:1267:43:    got void *<noident>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      fb05f41f
    • Maxim Patlasov's avatar
      fuse: add per-page descriptor <offset, length> to fuse_req · b2430d75
      Maxim Patlasov authored
      
      
      The ability to save page pointers along with lengths and offsets in fuse_req
      will be useful to cover several iovec-s with a single fuse_req.
      
      Per-request page_offset is removed because anybody who need it can use
      req->page_descs[0].offset instead.
      Signed-off-by: default avatarMaxim Patlasov <mpatlasov@parallels.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      b2430d75
    • 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
    • Maxim Patlasov's avatar
      fuse: general infrastructure for pages[] of variable size · 4250c066
      Maxim Patlasov authored
      
      
      The patch removes inline array of FUSE_MAX_PAGES_PER_REQ page pointers from
      fuse_req. Instead of that, req->pages may now point either to small inline
      array or to an array allocated dynamically.
      
      This essentially means that all callers of fuse_request_alloc[_nofs] should
      pass the number of pages needed explicitly.
      
      The patch doesn't make any logic changes.
      Signed-off-by: default avatarMaxim Patlasov <mpatlasov@parallels.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      4250c066
    • Anand V. Avati's avatar
      fuse: implement NFS-like readdirplus support · 0b05b183
      Anand V. Avati authored
      
      
      This patch implements readdirplus support in FUSE, similar to NFS.
      The payload returned in the readdirplus call contains
      'fuse_entry_out' structure thereby providing all the necessary inputs
      for 'faking' a lookup() operation on the spot.
      
      If the dentry and inode already existed (for e.g. in a re-run of ls -l)
      then just the inode attributes timeout and dentry timeout are refreshed.
      
      With a simple client->network->server implementation of a FUSE based
      filesystem, the following performance observations were made:
      
      Test: Performing a filesystem crawl over 20,000 files with
      
      sh# time ls -lR /mnt
      
      Without readdirplus:
      Run 1: 18.1s
      Run 2: 16.0s
      Run 3: 16.2s
      
      With readdirplus:
      Run 1: 4.1s
      Run 2: 3.8s
      Run 3: 3.8s
      
      The performance improvement is significant as it avoided 20,000 upcalls
      calls (lookup). Cache consistency is no worse than what already is.
      Signed-off-by: default avatarAnand V. Avati <avati@redhat.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      0b05b183
  9. 15 Nov, 2012 1 commit
    • Eric W. Biederman's avatar
      userns: Support fuse interacting with multiple user namespaces · 499dcf20
      Eric W. Biederman authored
      
      
      Use kuid_t and kgid_t in struct fuse_conn and struct fuse_mount_data.
      
      The connection between between a fuse filesystem and a fuse daemon is
      established when a fuse filesystem is mounted and provided with a file
      descriptor the fuse daemon created by opening /dev/fuse.
      
      For now restrict the communication of uids and gids between the fuse
      filesystem and the fuse daemon to the initial user namespace.  Enforce
      this by verifying the file descriptor passed to the mount of fuse was
      opened in the initial user namespace.  Ensuring the mount happens in
      the initial user namespace is not necessary as mounts from non-initial
      user namespaces are not yet allowed.
      
      In fuse_req_init_context convert the currrent fsuid and fsgid into the
      initial user namespace for the request that will be sent to the fuse
      daemon.
      
      In fuse_fill_attr convert the uid and gid passed from the fuse daemon
      from the initial user namespace into kuids and kgids.
      
      In iattr_to_fattr called from fuse_setattr convert kuids and kgids
      into the uids and gids in the initial user namespace before passing
      them to the fuse filesystem.
      
      In fuse_change_attributes_common called from fuse_dentry_revalidate,
      fuse_permission, fuse_geattr, and fuse_setattr, and fuse_iget convert
      the uid and gid from the fuse daemon into a kuid and a kgid to store
      on the fuse inode.
      
      By default fuse mounts are restricted to task whose uid, suid, and
      euid matches the fuse user_id and whose gid, sgid, and egid matches
      the fuse group id.  Convert the user_id and group_id mount options
      into kuids and kgids at mount time, and use uid_eq and gid_eq to
      compare the in fuse_allow_task.
      
      Cc: Miklos Szeredi <miklos@szeredi.hu>
      Acked-by: default avatarSerge Hallyn <serge.hallyn@canonical.com>
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      499dcf20
  10. 18 Jul, 2012 1 commit
  11. 14 May, 2012 1 commit
    • Pavel Shilovsky's avatar
      fuse: fix stat call on 32 bit platforms · 45c72cd7
      Pavel Shilovsky authored
      
      
      Now we store attr->ino at inode->i_ino, return attr->ino at the
      first time and then return inode->i_ino if the attribute timeout
      isn't expired. That's wrong on 32 bit platforms because attr->ino
      is 64 bit and inode->i_ino is 32 bit in this case.
      
      Fix this by saving 64 bit ino in fuse_inode structure and returning
      it every time we call getattr. Also squash attr->ino into inode->i_ino
      explicitly.
      Signed-off-by: default avatarPavel Shilovsky <piastry@etersoft.ru>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      45c72cd7
  12. 26 Apr, 2012 1 commit
  13. 04 Jan, 2012 1 commit
  14. 13 Dec, 2011 2 commits
    • John Muir's avatar
      FUSE: Notifying the kernel of deletion. · 451d0f59
      John Muir authored
      
      
      Allows a FUSE file-system to tell the kernel when a file or directory is
      deleted. If the specified dentry has the specified inode number, the kernel will
      unhash it.
      
      The current 'fuse_notify_inval_entry' does not cause the kernel to clean up
      directories that are in use properly, and as a result the users of those
      directories see incorrect semantics from the file-system. The error condition
      seen when 'fuse_notify_inval_entry' is used to notify of a deleted directory is
      avoided when 'fuse_notify_delete' is used instead.
      
      The following scenario demonstrates the difference:
      1. User A chdirs into 'testdir' and starts reading 'testfile'.
      2. User B rm -rf 'testdir'.
      3. User B creates 'testdir'.
      4. User C chdirs into 'testdir'.
      
      If you run the above within the same machine on any file-system (including fuse
      file-systems), there is no problem: user C is able to chdir into the new
      testdir. The old testdir is removed from the dentry tree, but still open by user
      A.
      
      If operations 2 and 3 are performed via the network such that the fuse
      file-system uses one of the notify functions to tell the kernel that the nodes
      are gone, then the following error occurs for user C while user A holds the
      original directory open:
      
      muirj@empacher:~> ls /test/testdir
      ls: cannot access /test/testdir: No such file or directory
      
      The issue here is that the kernel still has a dentry for testdir, and so it is
      requesting the attributes for the old directory, while the file-system is
      responding that the directory no longer exists.
      
      If on the other hand, if the file-system can notify the kernel that the
      directory is deleted using the new 'fuse_notify_delete' function, then the above
      ls will find the new directory as expected.
      Signed-off-by: default avatarJohn Muir <john@jmuir.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      451d0f59
    • Miklos Szeredi's avatar
      fuse: support ioctl on directories · b18da0c5
      Miklos Szeredi authored
      
      
      Multiplexing filesystems may want to support ioctls on the underlying
      files and directores (e.g. FS_IOC_{GET,SET}FLAGS).
      
      Ioctl support on directories was missing so add it now.
      Reported-by: default avatarAntonio SJ Musumeci <bile@landofbile.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      b18da0c5
  15. 08 Aug, 2011 1 commit
    • Miklos Szeredi's avatar
      fuse: fix flock · 37fb3a30
      Miklos Szeredi authored
      Commit a9ff4f87
      
       "fuse: support BSD locking semantics" overlooked a
      number of issues with supporing flock locks over existing POSIX
      locking infrastructure:
      
        - it's not backward compatible, passing flock(2) calls to userspace
          unconditionally (if userspace sets FUSE_POSIX_LOCKS)
      
        - it doesn't cater for the fact that flock locks are automatically
          unlocked on file release
      
        - it doesn't take into account the fact that flock exclusive locks
          (write locks) don't need an fd opened for write.
      
      The last one invalidates the original premise of the patch that flock
      locks can be emulated with POSIX locks.
      
      This patch fixes the first two issues.  The last one needs to be fixed
      in userspace if the filesystem assumed that a write lock will happen
      only on a file operned for write (as in the case of the current fuse
      library).
      Reported-by: default avatarSebastian Pipping <webmaster@hartwork.org>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      37fb3a30
  16. 21 Jul, 2011 1 commit
    • Josef Bacik's avatar
      fs: push i_mutex and filemap_write_and_wait down into ->fsync() handlers · 02c24a82
      Josef Bacik authored
      
      
      Btrfs needs to be able to control how filemap_write_and_wait_range() is called
      in fsync to make it less of a painful operation, so push down taking i_mutex and
      the calling of filemap_write_and_wait() down into the ->fsync() handlers.  Some
      file systems can drop taking the i_mutex altogether it seems, like ext3 and
      ocfs2.  For correctness sake I just pushed everything down in all cases to make
      sure that we keep the current behavior the same for everybody, and then each
      individual fs maintainer can make up their mind about what to do from there.
      Thanks,
      Acked-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      02c24a82
  17. 21 Mar, 2011 1 commit
  18. 25 Feb, 2011 1 commit
  19. 07 Dec, 2010 2 commits
    • Miklos Szeredi's avatar
      fuse: allow batching of FORGET requests · 02c048b9
      Miklos Szeredi authored
      
      
      Terje Malmedal reports that a fuse filesystem with 32 million inodes
      on a machine with lots of memory can take up to 30 minutes to process
      FORGET requests when all those inodes are evicted from the icache.
      
      To solve this, create a BATCH_FORGET request that allows up to about
      8000 FORGET requests to be sent in a single message.
      
      This request is only sent if userspace supports interface version 7.16
      or later, otherwise fall back to sending individual FORGET messages.
      Reported-by: default avatarTerje Malmedal <terje.malmedal@usit.uio.no>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      02c048b9
    • Miklos Szeredi's avatar
      fuse: separate queue for FORGET requests · 07e77dca
      Miklos Szeredi authored
      
      
      Terje Malmedal reports that a fuse filesystem with 32 million inodes
      on a machine with lots of memory can go unresponsive for up to 30
      minutes when all those inodes are evicted from the icache.
      
      The reason is that FORGET messages, sent when the inode is evicted,
      are queued up together with regular filesystem requests, and while the
      huge queue of FORGET messages are processed no other filesystem
      operation can proceed.
      
      Since a full fuse request structure is allocated for each inode, these
      take up quite a bit of memory as well.
      
      To solve these issues, create a slim 'fuse_forget_link' structure
      containing just the minimum of information required to send the FORGET
      request and chain these on a separate queue.
      
      When userspace is asking for a request make sure that FORGET and
      non-FORGET requests are selected fairly: for each 8 non-FORGET allow
      16 FORGET requests.  This will make sure FORGETs do not pile up, yet
      other requests are also allowed to proceed while the queued FORGETs
      are processed.
      Reported-by: default avatarTerje Malmedal <terje.malmedal@usit.uio.no>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      07e77dca
  20. 12 Jul, 2010 2 commits
    • Miklos Szeredi's avatar
      fuse: add retrieve request · 2d45ba38
      Miklos Szeredi authored
      
      
      Userspace filesystem can request data to be retrieved from the inode's
      mapping.  This request is synchronous and the retrieved data is queued
      as a new request.  If the write to the fuse device returns an error
      then the retrieve request was not completed and a reply will not be
      sent.
      
      Only present pages are returned in the retrieve reply.  Retrieving
      stops when it finds a non-present page and only data prior to that is
      returned.
      
      This request doesn't change the dirty state of pages.
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      2d45ba38
    • Miklos Szeredi's avatar
      fuse: add store request · a1d75f25
      Miklos Szeredi authored
      
      
      Userspace filesystem can request data to be stored in the inode's
      mapping.  This request is synchronous and has no reply.  If the write
      to the fuse device returns an error then the store request was not
      fully completed (but may have updated some pages).
      
      If the stored data overflows the current file size, then the size is
      extended, similarly to a write(2) on the filesystem.
      
      Pages which have been completely stored are marked uptodate.
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      a1d75f25
  21. 28 May, 2010 1 commit
  22. 25 May, 2010 1 commit
    • Miklos Szeredi's avatar
      fuse: allow splice to move pages · ce534fb0
      Miklos Szeredi authored
      
      
      When splicing buffers to the fuse device with SPLICE_F_MOVE, try to
      move pages from the pipe buffer into the page cache.  This allows
      populating the fuse filesystem's cache without ever touching the page
      contents, i.e. zero copy read capability.
      
      The following steps are performed when trying to move a page into the
      page cache:
      
       - buf->ops->confirm() to make sure the new page is uptodate
       - buf->ops->steal() to try to remove the new page from it's previous place
       - remove_from_page_cache() on the old page
       - add_to_page_cache_locked() on the new page
      
      If any of the above steps fail (non fatally) then the code falls back
      to copying the page.  In particular ->steal() will fail if there are
      external references (other than the page cache and the pipe buffer) to
      the page.
      
      Also since the remove_from_page_cache() + add_to_page_cache_locked()
      are non-atomic it is possible that the page cache is repopulated in
      between the two and add_to_page_cache_locked() will fail.  This could
      be fixed by creating a new atomic replace_page_cache_page() function.
      
      fuse_readpages_end() needed to be reworked so it works even if
      page->mapping is NULL for some or all pages which can happen if the
      add_to_page_cache_locked() failed.
      
      A number of sanity checks were added to make sure the stolen pages
      don't have weird flags set, etc...  These could be moved into generic
      splice/steal code.
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      ce534fb0
  23. 24 Sep, 2009 1 commit
  24. 16 Sep, 2009 1 commit
  25. 07 Jul, 2009 1 commit
  26. 30 Jun, 2009 2 commits
    • John Muir's avatar
      fuse: invalidation reverse calls · 3b463ae0
      John Muir authored
      
      
      Add notification messages that allow the filesystem to invalidate VFS
      caches.
      
      Two notifications are added:
      
       1) inode invalidation
      
         - invalidate cached attributes
         - invalidate a range of pages in the page cache (this is optional)
      
       2) dentry invalidation
      
         - try to invalidate a subtree in the dentry cache
      
      Care must be taken while accessing the 'struct super_block' for the
      mount, as it can go away while an invalidation is in progress.  To
      prevent this, introduce a rw-semaphore, that is taken for read during
      the invalidation and taken for write in the ->kill_sb callback.
      
      Cc: Csaba Henk <csaba@gluster.com>
      Cc: Anand Avati <avati@zresearch.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      3b463ae0
    • Miklos Szeredi's avatar
      fuse: allow umask processing in userspace · e0a43ddc
      Miklos Szeredi authored
      
      
      This patch lets filesystems handle masking the file mode on creation.
      This is needed if filesystem is using ACLs.
      
       - The CREATE, MKDIR and MKNOD requests are extended with a "umask"
         parameter.
      
       - A new FUSE_DONT_MASK flag is added to the INIT request/reply.  With
         this the filesystem may request that the create mode is not masked.
      
      CC: Jean-Pierre André <jean-pierre.andre@wanadoo.fr>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      e0a43ddc
  27. 28 Apr, 2009 2 commits