1. 24 6月, 2015 1 次提交
  2. 19 6月, 2015 1 次提交
    • D
      overlayfs: Make f_path always point to the overlay and f_inode to the underlay · 4bacc9c9
      David Howells 提交于
      Make file->f_path always point to the overlay dentry so that the path in
      /proc/pid/fd is correct and to ensure that label-based LSMs have access to the
      overlay as well as the underlay (path-based LSMs probably don't need it).
      
      Using my union testsuite to set things up, before the patch I see:
      
      	[root@andromeda union-testsuite]# bash 5</mnt/a/foo107
      	[root@andromeda union-testsuite]# ls -l /proc/$$/fd/
      	...
      	lr-x------. 1 root root 64 Jun  5 14:38 5 -> /a/foo107
      	[root@andromeda union-testsuite]# stat /mnt/a/foo107
      	...
      	Device: 23h/35d Inode: 13381       Links: 1
      	...
      	[root@andromeda union-testsuite]# stat -L /proc/$$/fd/5
      	...
      	Device: 23h/35d Inode: 13381       Links: 1
      	...
      
      After the patch:
      
      	[root@andromeda union-testsuite]# bash 5</mnt/a/foo107
      	[root@andromeda union-testsuite]# ls -l /proc/$$/fd/
      	...
      	lr-x------. 1 root root 64 Jun  5 14:22 5 -> /mnt/a/foo107
      	[root@andromeda union-testsuite]# stat /mnt/a/foo107
      	...
      	Device: 23h/35d Inode: 40346       Links: 1
      	...
      	[root@andromeda union-testsuite]# stat -L /proc/$$/fd/5
      	...
      	Device: 23h/35d Inode: 40346       Links: 1
      	...
      
      Note the change in where /proc/$$/fd/5 points to in the ls command.  It was
      pointing to /a/foo107 (which doesn't exist) and now points to /mnt/a/foo107
      (which is correct).
      
      The inode accessed, however, is the lower layer.  The union layer is on device
      25h/37d and the upper layer on 24h/36d.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      4bacc9c9
  3. 11 5月, 2015 1 次提交
  4. 12 4月, 2015 3 次提交
    • A
      ->aio_read and ->aio_write removed · 84363182
      Al Viro 提交于
      no remaining users
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      84363182
    • A
      NFS: fix BUG() crash in notify_change() with patch to chown_common() · c1b8940b
      Andrew Elble 提交于
      We have observed a BUG() crash in fs/attr.c:notify_change(). The crash
      occurs during an rsync into a filesystem that is exported via NFS.
      
      1.) fs/attr.c:notify_change() modifies the caller's version of attr.
      2.) 6de0ec00 ("VFS: make notify_change pass ATTR_KILL_S*ID to
          setattr operations") introduced a BUG() restriction such that "no
          function will ever call notify_change() with both ATTR_MODE and
          ATTR_KILL_S*ID set". Under some circumstances though, it will have
          assisted in setting the caller's version of attr to this very
          combination.
      3.) 27ac0ffe ("locks: break delegations on any attribute
          modification") introduced code to handle breaking
          delegations. This can result in notify_change() being re-called. attr
          _must_ be explicitly reset to avoid triggering the BUG() established
          in #2.
      4.) The path that that triggers this is via fs/open.c:chmod_common().
          The combination of attr flags set here and in the first call to
          notify_change() along with a later failed break_deleg_wait()
          results in notify_change() being called again via retry_deleg
          without resetting attr.
      
      Solution is to move retry_deleg in chmod_common() a bit further up to
      ensure attr is completely reset.
      
      There are other places where this seemingly could occur, such as
      fs/utimes.c:utimes_common(), but the attr flags are not initially
      set in such a way to trigger this.
      
      Fixes: 27ac0ffe ("locks: break delegations on any attribute modification")
      Reported-by: NEric Meddaugh <etmsys@rit.edu>
      Tested-by: NEric Meddaugh <etmsys@rit.edu>
      Signed-off-by: NAndrew Elble <aweits@rit.edu>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      c1b8940b
    • A
      drop bogus check in file_open_root() · e5b811e3
      Al Viro 提交于
      For one thing, LOOKUP_DIRECTORY will be dealt with in do_last().
      For another, name can be an empty string, but not NULL - no callers
      pass that and it would oops immediately if they would.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      e5b811e3
  5. 25 3月, 2015 1 次提交
  6. 17 2月, 2015 1 次提交
    • M
      vfs: remove get_xip_mem · e748dcd0
      Matthew Wilcox 提交于
      All callers of get_xip_mem() are now gone.  Remove checks for it,
      initialisers of it, documentation of it and the only implementation of it.
       Also remove mm/filemap_xip.c as it is now empty.  Also remove
      documentation of the long-gone get_xip_page().
      Signed-off-by: NMatthew Wilcox <matthew.r.wilcox@intel.com>
      Cc: Andreas Dilger <andreas.dilger@intel.com>
      Cc: Boaz Harrosh <boaz@plexistor.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Dave Chinner <david@fromorbit.com>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
      Cc: Theodore Ts'o <tytso@mit.edu>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e748dcd0
  7. 23 1月, 2015 1 次提交
    • P
      fs: create proper filename objects using getname_kernel() · 51689104
      Paul Moore 提交于
      There are several areas in the kernel that create temporary filename
      objects using the following pattern:
      
      	int func(const char *name)
      	{
      		struct filename *file = { .name = name };
      		...
      		return 0;
      	}
      
      ... which for the most part works okay, but it causes havoc within the
      audit subsystem as the filename object does not persist beyond the
      lifetime of the function.  This patch converts all of these temporary
      filename objects into proper filename objects using getname_kernel()
      and putname() which ensure that the filename object persists until the
      audit subsystem is finished with it.
      
      Also, a special thanks to Al Viro, Guenter Roeck, and Sabrina Dubroca
      for helping resolve a difficult kernel panic on boot related to a
      use-after-free problem in kern_path_create(); the thread can be seen
      at the link below:
      
       * https://lkml.org/lkml/2015/1/20/710
      
      This patch includes code that was either based on, or directly written
      by Al in the above thread.
      
      CC: viro@zeniv.linux.org.uk
      CC: linux@roeck-us.net
      CC: sd@queasysnail.net
      CC: linux-fsdevel@vger.kernel.org
      Signed-off-by: NPaul Moore <pmoore@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      51689104
  8. 14 12月, 2014 1 次提交
    • H
      fallocate: create FAN_MODIFY and IN_MODIFY events · 820c12d5
      Heinrich Schuchardt 提交于
      The fanotify and the inotify API can be used to monitor changes of the
      file system.  System call fallocate() modifies files.  Hence it should
      trigger the corresponding fanotify (FAN_MODIFY) and inotify (IN_MODIFY)
      events.  The most interesting case is FALLOC_FL_COLLAPSE_RANGE because
      this value allows to create arbitrary file content from random data.
      
      This patch adds the missing call to fsnotify_modify().
      
      The FAN_MODIFY and IN_MODIFY event will be created when fallocate()
      succeeds.  It will even be created if the file length remains unchanged,
      e.g.  when calling fanotify with flag FALLOC_FL_KEEP_SIZE.
      
      This logic was primarily chosen to keep the coding simple.
      
      It resembles the logic of the write() system call.
      
      When we call write() we always create a FAN_MODIFY event, even in the case
      of overwriting with identical data.
      
      Events FAN_MODIFY and IN_MODIFY do not provide any guarantee that data was
      actually changed.
      
      Furthermore even if if the filesize remains unchanged, fallocate() may
      influence whether a subsequent write() will succeed and hence the
      fallocate() call may be considered a modification.
      
      The fallocate(2) man page teaches: After a successful call, subsequent
      writes into the range specified by offset and len are guaranteed not to
      fail because of lack of disk space.
      
      So calling fallocate(fd, FALLOC_FL_KEEP_SIZE, offset, len) may result in
      different outcomes of a subsequent write depending on the values of offset
      and len.
      Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
      Reviewed-by: NJan Kara <jack@suse.cz>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Eric Paris <eparis@parisplace.org>
      Cc: John McCutchan <john@johnmccutchan.com>
      Cc: Robert Love <rlove@rlove.org>
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Cc: Theodore Ts'o <tytso@mit.edu>
      Cc: Dave Chinner <david@fromorbit.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      820c12d5
  9. 20 11月, 2014 1 次提交
    • A
      new helper: audit_file() · 9f45f5bf
      Al Viro 提交于
      ... for situations when we don't have any candidate in pathnames - basically,
      in descriptor-based syscalls.
      
      [Folded the build fix for !CONFIG_AUDITSYSCALL configs from Chen Gang]
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      9f45f5bf
  10. 08 11月, 2014 1 次提交
  11. 24 10月, 2014 1 次提交
  12. 01 8月, 2014 1 次提交
  13. 07 5月, 2014 2 次提交
    • A
      new methods: ->read_iter() and ->write_iter() · 293bc982
      Al Viro 提交于
      Beginning to introduce those.  Just the callers for now, and it's
      clumsier than it'll eventually become; once we finish converting
      aio_read and aio_write instances, the things will get nicer.
      
      For now, these guys are in parallel to ->aio_read() and ->aio_write();
      they take iocb and iov_iter, with everything in iov_iter already
      validated.  File offset is passed in iocb->ki_pos, iov/nr_segs -
      in iov_iter.
      
      Main concerns in that series are stack footprint and ability to
      split the damn thing cleanly.
      
      [fix from Peter Ujfalusi <peter.ujfalusi@ti.com> folded]
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      293bc982
    • A
      replace checking for ->read/->aio_read presence with check in ->f_mode · 7f7f25e8
      Al Viro 提交于
      Since we are about to introduce new methods (read_iter/write_iter), the
      tests in a bunch of places would have to grow inconveniently.  Check
      once (at open() time) and store results in ->f_mode as FMODE_CAN_READ
      and FMODE_CAN_WRITE resp.  It might end up being a temporary measure -
      once everything switches from ->aio_{read,write} to ->{read,write}_iter
      it might make sense to return to open-coded checks.  We'll see...
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      7f7f25e8
  14. 12 4月, 2014 3 次提交
  15. 02 4月, 2014 5 次提交
  16. 13 3月, 2014 1 次提交
    • L
      fs: Introduce FALLOC_FL_ZERO_RANGE flag for fallocate · 409332b6
      Lukas Czerner 提交于
      Introduce new FALLOC_FL_ZERO_RANGE flag for fallocate. This has the same
      functionality as xfs ioctl XFS_IOC_ZERO_RANGE.
      
      It can be used to convert a range of file to zeros preferably without
      issuing data IO. Blocks should be preallocated for the regions that span
      holes in the file, and the entire range is preferable converted to
      unwritten extents - even though file system may choose to zero out the
      extent or do whatever which will result in reading zeros from the range
      while the range remains allocated for the file.
      
      This can be also used to preallocate blocks past EOF in the same way as
      with fallocate. Flag FALLOC_FL_KEEP_SIZE which should cause the inode
      size to remain the same.
      Signed-off-by: NLukas Czerner <lczerner@redhat.com>
      Reviewed-by: NDave Chinner <dchinner@redhat.com>
      Signed-off-by: NDave Chinner <david@fromorbit.com>
      409332b6
  17. 10 3月, 2014 1 次提交
    • L
      vfs: atomic f_pos accesses as per POSIX · 9c225f26
      Linus Torvalds 提交于
      Our write() system call has always been atomic in the sense that you get
      the expected thread-safe contiguous write, but we haven't actually
      guaranteed that concurrent writes are serialized wrt f_pos accesses, so
      threads (or processes) that share a file descriptor and use "write()"
      concurrently would quite likely overwrite each others data.
      
      This violates POSIX.1-2008/SUSv4 Section XSI 2.9.7 that says:
      
       "2.9.7 Thread Interactions with Regular File Operations
      
        All of the following functions shall be atomic with respect to each
        other in the effects specified in POSIX.1-2008 when they operate on
        regular files or symbolic links: [...]"
      
      and one of the effects is the file position update.
      
      This unprotected file position behavior is not new behavior, and nobody
      has ever cared.  Until now.  Yongzhi Pan reported unexpected behavior to
      Michael Kerrisk that was due to this.
      
      This resolves the issue with a f_pos-specific lock that is taken by
      read/write/lseek on file descriptors that may be shared across threads
      or processes.
      Reported-by: NYongzhi Pan <panyongzhi@gmail.com>
      Reported-by: NMichael Kerrisk <mtk.manpages@gmail.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      9c225f26
  18. 24 2月, 2014 1 次提交
  19. 09 11月, 2013 2 次提交
  20. 25 10月, 2013 1 次提交
  21. 17 9月, 2013 1 次提交
    • M
      vfs: improve i_op->atomic_open() documentation · 0854d450
      Miklos Szeredi 提交于
      Fix documentation of ->atomic_open() and related functions: finish_open()
      and finish_no_open().  Also add details that seem to be unclear and a
      source of bugs (some of which are fixed in the following series).
      
      Cc-ing maintainers of all filesystems implementing ->atomic_open().
      Signed-off-by: NMiklos Szeredi <mszeredi@suse.cz>
      Cc: Eric Van Hensbergen <ericvh@gmail.com>
      Cc: Sage Weil <sage@inktank.com>
      Cc: Steve French <sfrench@samba.org>
      Cc: Steven Whitehouse <swhiteho@redhat.com>
      Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      0854d450
  22. 04 9月, 2013 1 次提交
  23. 31 8月, 2013 1 次提交
  24. 05 8月, 2013 1 次提交
  25. 20 7月, 2013 1 次提交
  26. 13 7月, 2013 1 次提交
    • A
      Safer ABI for O_TMPFILE · bb458c64
      Al Viro 提交于
      [suggested by Rasmus Villemoes] make O_DIRECTORY | O_RDWR part of O_TMPFILE;
      that will fail on old kernels in a lot more cases than what I came up with.
      And make sure O_CREAT doesn't get there...
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      bb458c64
  27. 29 6月, 2013 2 次提交
  28. 04 3月, 2013 2 次提交