1. 14 Jul, 2012 12 commits
  2. 08 Jul, 2012 1 commit
  3. 01 Jun, 2012 4 commits
  4. 03 May, 2012 2 commits
  5. 09 Apr, 2012 1 commit
  6. 19 Feb, 2012 1 commit
    • David Howells's avatar
      Wrap accesses to the fd_sets in struct fdtable · 1dce27c5
      David Howells authored
      Wrap accesses to the fd_sets in struct fdtable (for recording open files and
      close-on-exec flags) so that we can move away from using fd_sets since we
      abuse the fd_set structs by not allocating the full-sized structure under
      normal circumstances and by non-core code looking at the internals of the
      The first abuse means that use of FD_ZERO() on these fd_sets is not permitted,
      since that cannot be told about their abnormal lengths.
      This introduces six wrapper functions for setting, clearing and testing
      close-on-exec flags and fd-is-open flags:
      	void __set_close_on_exec(int fd, struct fdtable *fdt);
      	void __clear_close_on_exec(int fd, struct fdtable *fdt);
      	bool close_on_exec(int fd, const struct fdtable *fdt);
      	void __set_open_fd(int fd, struct fdtable *fdt);
      	void __clear_open_fd(int fd, struct fdtable *fdt);
      	bool fd_is_open(int fd, const struct fdtable *fdt);
      Note that I've prepended '__' to the names of the set/clear functions because
      they require the caller to hold a lock to use them.
      Note also that I haven't added wrappers for looking behind the scenes at the
      the array.  Possibly that should exist too.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Link: http://lkml.kernel.org/r/20120216174942.23314.1364.stgit@warthog.procyon.org.ukSigned-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
  7. 07 Jan, 2012 1 commit
  8. 04 Jan, 2012 3 commits
  9. 28 Oct, 2011 1 commit
  10. 26 Jul, 2011 1 commit
    • Al Viro's avatar
      merge fchmod() and fchmodat() guts, kill ancient broken kludge · e57712eb
      Al Viro authored
      The kludge in question is undocumented and doesn't work for 32bit
      binaries on amd64, sparc64 and s390.  Passing (mode_t)-1 as
      mode had (since 0.99.14v and contrary to behaviour of any
      other Unix, prescriptions of POSIX, SuS and our own manpages)
      was kinda-sorta no-op.  Note that any software relying on
      that (and looking for examples shows none) would be visibly
      broken on sparc64, where practically all userland is built
      32bit.  No such complaints noticed...
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
  11. 22 Jul, 2011 1 commit
  12. 21 Mar, 2011 1 commit
  13. 15 Mar, 2011 2 commits
    • Al Viro's avatar
      readlinkat(), fchownat() and fstatat() with empty relative pathnames · 65cfc672
      Al Viro authored
      For readlinkat() we simply allow empty pathname; it will fail unless
      we have dfd equal to O_PATH-opened symlink, so we are outside of
      POSIX scope here.  For fchownat() and fstatat() we allow AT_EMPTY_PATH;
      let the caller explicitly ask for such behaviour.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
    • Al Viro's avatar
      New kind of open files - "location only". · 1abf0c71
      Al Viro authored
      New flag for open(2) - O_PATH.  Semantics:
      	* pathname is resolved, but the file itself is _NOT_ opened
      as far as filesystem is concerned.
      	* almost all operations on the resulting descriptors shall
      fail with -EBADF.  Exceptions are:
      	1) operations on descriptors themselves (i.e.
      		close(), dup(), dup2(), dup3(), fcntl(fd, F_DUPFD),
      		fcntl(fd, F_DUPFD_CLOEXEC, ...), fcntl(fd, F_GETFD),
      		fcntl(fd, F_SETFD, ...))
      	2) fcntl(fd, F_GETFL), for a common non-destructive way to
      		check if descriptor is open
      	3) "dfd" arguments of ...at(2) syscalls, i.e. the starting
      		points of pathname resolution
      	* closing such descriptor does *NOT* affect dnotify or
      posix locks.
      	* permissions are checked as usual along the way to file;
      no permission checks are applied to the file itself.  Of course,
      giving such thing to syscall will result in permission checks (at
      the moment it means checking that starting point of ....at() is
      a directory and caller has exec permissions on it).
      fget() and fget_light() return NULL on such descriptors; use of
      fget_raw() and fget_raw_light() is needed to get them.  That protects
      existing code from dealing with those things.
      There are two things still missing (they come in the next commits):
      one is handling of symlinks (right now we refuse to open them that
      way; see the next commit for semantics related to those) and another
      is descriptor passing via SCM_RIGHTS datagrams.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
  14. 14 Mar, 2011 2 commits
    • Al Viro's avatar
      open-style analog of vfs_path_lookup() · 73d049a4
      Al Viro authored
      new function: file_open_root(dentry, mnt, name, flags) opens the file
      vfs_path_lookup would arrive to.
      Note that name can be empty; in that case the usual requirement that
      dentry should be a directory is lifted.
      open-coded equivalents switched to it, may_open() got down exactly
      one caller and became static.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
    • Al Viro's avatar
      switch do_filp_open() to struct open_flags · 47c805dc
      Al Viro authored
      take calculation of open_flags by open(2) arguments into new helper
      in fs/open.c, move filp_open() over there, have it and do_sys_open()
      use that helper, switch exec.c callers of do_filp_open() to explicit
      (and constant) struct open_flags.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
  15. 10 Mar, 2011 1 commit
  16. 11 Feb, 2011 1 commit
    • Linus Torvalds's avatar
      Fix possible filp_cachep memory corruption · 2dab5974
      Linus Torvalds authored
      In commit 31e6b01f ("fs: rcu-walk for path lookup") we started doing
      path lookup using RCU, which then falls back to a careful non-RCU lookup
      in case of problems (LOOKUP_REVAL).  So do_filp_open() has this "re-do
      the lookup carefully" looping case.
      However, that means that we must not release the open-intent file data
      if we are going to loop around and use it once more!
      Fix this by moving the release of the open-intent data to the function
      that allocates it (do_filp_open() itself) rather than the helper
      functions that can get called multiple times (finish_open() and
      do_last()).  This makes the logic for the lifetime of that field much
      more obvious, and avoids the possible double free.
      Reported-by: default avatarJ. R. Okajima <hooanon05@yahoo.co.jp>
      Acked-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Cc: Nick Piggin <npiggin@kernel.dk>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  17. 10 Feb, 2011 1 commit
  18. 17 Jan, 2011 1 commit
    • Christoph Hellwig's avatar
      fallocate should be a file operation · 2fe17c10
      Christoph Hellwig authored
      Currently all filesystems except XFS implement fallocate asynchronously,
      while XFS forced a commit.  Both of these are suboptimal - in case of O_SYNC
      I/O we really want our allocation on disk, especially for the !KEEP_SIZE
      case where we actually grow the file with user-visible zeroes.  On the
      other hand always commiting the transaction is a bad idea for fast-path
      uses of fallocate like for example in recent Samba versions.   Given
      that block allocation is a data plane operation anyway change it from
      an inode operation to a file operation so that we have the file structure
      available that lets us check for O_SYNC.
      This also includes moving the code around for a few of the filesystems,
      and remove the already unnedded S_ISDIR checks given that we only wire
      up fallocate for regular files.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
  19. 13 Jan, 2011 1 commit
    • Josef Bacik's avatar
      fs: add hole punching to fallocate · 79124f18
      Josef Bacik authored
      Hole punching has already been implemented by XFS and OCFS2, and has the
      potential to be implemented on both BTRFS and EXT4 so we need a generic way to
      get to this feature.  The simplest way in my mind is to add FALLOC_FL_PUNCH_HOLE
      to fallocate() since it already looks like the normal fallocate() operation.
      I've tested this patch with XFS and BTRFS to make sure XFS did what it's
      supposed to do and that BTRFS failed like it was supposed to.  Thank you,
      Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
  20. 29 Oct, 2010 1 commit
    • Al Viro's avatar
      fix open/umount race · d893f1bc
      Al Viro authored
      nameidata_to_filp() drops nd->path or transfers it to opened
      file.  In the former case it's a Bad Idea(tm) to do mnt_drop_write()
      on nd->path.mnt, since we might race with umount and vfsmount in
      question might be gone already.
      Fix: don't drop it, then...  IOW, have nameidata_to_filp() grab nd->path
      in case it transfers it to file and do path_drop() in callers.  After
      they are through with accessing nd->path...
      Reported-by: default avatarMiklos Szeredi <miklos@szeredi.hu>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
  21. 18 Aug, 2010 1 commit