Skip to content

K
Kernel

openeuler / Kernel
大约 1 年 前同步成功

通知 5
Star 0
Fork 0
K
Kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 06 1月, 2009 9 次提交
    • C
      add a vfs_fsync helper · 4c728ef5
      由 Christoph Hellwig 提交于 
      Fsync currently has a fdatawrite/fdatawait pair around the method call,
and a mutex_lock/unlock of the inode mutex.  All callers of fsync have
to duplicate this, but we have a few and most of them don't quite get
it right.  This patch adds a new vfs_fsync that takes care of this.
It's a little more complicated as usual as ->fsync might get a NULL file
pointer and just a dentry from nfsd, but otherwise gets afile and we
want to take the mapping and file operations from it when it is there.

Notes on the fsync callers:

 - ecryptfs wasn't calling filemap_fdatawrite / filemap_fdatawait on the
   	lower file
 - coda wasn't calling filemap_fdatawrite / filemap_fdatawait on the host
	file, and returning 0 when ->fsync was missing
 - shm wasn't calling either filemap_fdatawrite / filemap_fdatawait nor
   taking i_mutex.  Now given that shared memory doesn't have disk
   backing not doing anything in fsync seems fine and I left it out of
   the vfs_fsync conversion for now, but in that case we might just
   not pass it through to the lower file at all but just call the no-op
   simple_sync_file directly.

[and now actually export vfs_fsync]
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      4c728ef5
    • E
      sys_execve and sys_uselib do not call into fsnotify · 6110e3ab
      由 Eric Paris 提交于 
      sys_execve and sys_uselib do not call into fsnotify so inotify does not get
open events for these types of syscalls.  This patch simply makes the
requisite fsnotify calls.
Signed-off-by: NEric Paris <eparis@redhat.com>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      6110e3ab
    • A
      zero i_uid/i_gid on inode allocation · 56ff5efa
      由 Al Viro 提交于 
      ... and don't bother in callers.  Don't bother with zeroing i_blocks,
while we are at it - it's already been zeroed.

i_mode is not worth the effort; it has no common default value.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      56ff5efa
    • A
      inode->i_op is never NULL · acfa4380
      由 Al Viro 提交于 
      We used to have rather schizophrenic set of checks for NULL ->i_op even
though it had been eliminated years ago.  You'd need to go out of your
way to set it to NULL explicitly _and_ a bunch of code would die on
such inodes anyway.  After killing two remaining places that still
did that bogosity, all that crap can go away.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      acfa4380
    • A
      ntfs: don't NULL i_op · 9742df33
      由 Al Viro 提交于 
      it's already set to empty table (and no, ntfs doesn't have any explicit
checks for NULL ->i_op or NULL ->i_fop)
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      9742df33
    • A
      isofs check for NULL ->i_op in root directory is dead code · 261964c6
      由 Al Viro 提交于 
      for one thing it never happens, for another we check that inode
is a directory right after that place anyway (and we'd already
checked that reading it from disk has not failed).
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      261964c6
    • A
      affs: do not zero ->i_op · c765d479
      由 Al Viro 提交于 
      it is already set to empty table and should never be NULL
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      c765d479
    • D
      kill suid bit only for regular files · 7f5ff766
      由 Dmitri Monakhov 提交于 
      We don't have to do it because it is useless for non regular files.
In fact block device may trigger this path without dentry->d_inode->i_mutex.

(akpm: concerns were expressed (by me) about S_ISDIR inodes)
Signed-off-by: NDmitri Monakhov <dmonakhov@openvz.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      7f5ff766
    • A
      vfs: lseek(fd, 0, SEEK_CUR) race condition · 5b6f1eb9
      由 Alain Knaff 提交于 
      This patch fixes a race condition in lseek. While it is expected that
unpredictable behaviour may result while repositioning the offset of a
file descriptor concurrently with reading/writing to the same file
descriptor, this should not happen when merely *reading* the file
descriptor's offset.

Unfortunately, the only portable way in Unix to read a file
descriptor's offset is lseek(fd, 0, SEEK_CUR); however executing this
concurrently with read/write may mess up the position.

[with fixes from akpm]
Signed-off-by: NAlain Knaff <alain@knaff.lu>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      5b6f1eb9
  3. 04 1月, 2009 24 次提交
  5. 03 1月, 2009 7 次提交