1. 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
  2. 09 11月, 2013 2 次提交
  3. 25 10月, 2013 1 次提交
  4. 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
  5. 04 9月, 2013 1 次提交
  6. 31 8月, 2013 1 次提交
  7. 05 8月, 2013 1 次提交
  8. 20 7月, 2013 1 次提交
  9. 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
  10. 29 6月, 2013 2 次提交
  11. 04 3月, 2013 2 次提交
  12. 02 3月, 2013 1 次提交
  13. 26 2月, 2013 1 次提交
  14. 25 2月, 2013 1 次提交
  15. 23 2月, 2013 2 次提交
  16. 21 12月, 2012 7 次提交
  17. 19 11月, 2012 1 次提交
  18. 13 10月, 2012 2 次提交
    • J
      vfs: make path_openat take a struct filename pointer · 669abf4e
      Jeff Layton 提交于
      ...and fix up the callers. For do_file_open_root, just declare a
      struct filename on the stack and fill out the .name field. For
      do_filp_open, make it also take a struct filename pointer, and fix up its
      callers to call it appropriately.
      
      For filp_open, add a variant that takes a struct filename pointer and turn
      filp_open into a wrapper around it.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      669abf4e
    • J
      vfs: define struct filename and have getname() return it · 91a27b2a
      Jeff Layton 提交于
      getname() is intended to copy pathname strings from userspace into a
      kernel buffer. The result is just a string in kernel space. It would
      however be quite helpful to be able to attach some ancillary info to
      the string.
      
      For instance, we could attach some audit-related info to reduce the
      amount of audit-related processing needed. When auditing is enabled,
      we could also call getname() on the string more than once and not
      need to recopy it from userspace.
      
      This patchset converts the getname()/putname() interfaces to return
      a struct instead of a string. For now, the struct just tracks the
      string in kernel space and the original userland pointer for it.
      
      Later, we'll add other information to the struct as it becomes
      convenient.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      91a27b2a
  19. 12 10月, 2012 1 次提交
    • J
      audit: set the name_len in audit_inode for parent lookups · bfcec708
      Jeff Layton 提交于
      Currently, this gets set mostly by happenstance when we call into
      audit_inode_child. While that might be a little more efficient, it seems
      wrong. If the syscall ends up failing before audit_inode_child ever gets
      called, then you'll have an audit_names record that shows the full path
      but has the parent inode info attached.
      
      Fix this by passing in a parent flag when we call audit_inode that gets
      set to the value of LOOKUP_PARENT. We can then fix up the pathname for
      the audit entry correctly from the get-go.
      
      While we're at it, clean up the no-op macro for audit_inode in the
      !CONFIG_AUDITSYSCALL case.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      bfcec708
  20. 27 9月, 2012 7 次提交
  21. 21 9月, 2012 1 次提交
  22. 15 8月, 2012 1 次提交
  23. 04 8月, 2012 1 次提交