Skip to content

K
Kernel

openeuler / Kernel
12 个月 前同步成功

通知 5
Star 0
Fork 0
K
Kernel

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

切换分支/标签
  1. 18 8月, 2010 1 次提交
  3. 13 8月, 2010 1 次提交
  5. 11 8月, 2010 1 次提交
  7. 28 7月, 2010 1 次提交
    • E
      vfs/fsnotify: fsnotify_close can delay the final work in fput · c1e5c954
      由 Eric Paris 提交于 
      fanotify almost works like so:

user context calls fsnotify_* function with a struct file.
   fsnotify takes a reference on the struct path
user context goes about it's buissiness

at some later point in time the fsnotify listener gets the struct path
   fanotify listener calls dentry_open() to create a file which userspace can deal with
      listener drops the reference on the struct path
at some later point the listener calls close() on it's new file

With the switch from struct path to struct file this presents a problem for
fput() and fsnotify_close().  fsnotify_close() is called when the filp has
already reached 0 and __fput() wants to do it's cleanup.

The solution presented here is a bit odd.  If an event is created from a
struct file we take a reference on the file.  We check however if the f_count
was already 0 and if so we take an EXTRA reference EVEN THOUGH IT WAS ZERO.
In __fput() (where we know the f_count hit 0 once) we check if the f_count is
non-zero and if so we drop that 'extra' ref and return without destroying the
file.
Signed-off-by: NEric Paris <eparis@redhat.com>
      c1e5c954
  9. 28 5月, 2010 1 次提交
    • A
      get rid of the magic around f_count in aio · d7065da0
      由 Al Viro 提交于 
      __aio_put_req() plays sick games with file refcount.  What
it wants is fput() from atomic context; it's almost always
done with f_count > 1, so they only have to deal with delayed
work in rare cases when their reference happens to be the
last one.  Current code decrements f_count and if it hasn't
hit 0, everything is fine.  Otherwise it keeps a pointer
to struct file (with zero f_count!) around and has delayed
work do __fput() on it.

Better way to do it: use atomic_long_add_unless( , -1, 1)
instead of !atomic_long_dec_and_test().  IOW, decrement it
only if it's not the last reference, leave refcount alone
if it was.  And use normal fput() in delayed work.

I've made that atomic_long_add_unless call a new helper -
fput_atomic().  Drops a reference to file if it's safe to
do in atomic (i.e. if that's not the last one), tells if
it had been able to do that.  aio.c converted to it, __fput()
use is gone.  req->ki_file *always* contributes to refcount
now.  And __fput() became static.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      d7065da0
  11. 07 3月, 2010 1 次提交
  13. 07 2月, 2010 1 次提交
  15. 23 12月, 2009 1 次提交
  17. 17 12月, 2009 6 次提交
  19. 25 10月, 2009 1 次提交
  21. 24 9月, 2009 1 次提交
  23. 12 6月, 2009 2 次提交
    • N
      fs: move mark_files_ro into file_table.c · 864d7c4c
      由 npiggin@suse.de 提交于 
      This function walks the s_files lock, and operates primarily on the
files in a superblock, so it better belongs here (eg. see also
fs_may_remount_ro).

[AV: ... and it shouldn't be static after that move]
Signed-off-by: NNick Piggin <npiggin@suse.de>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      864d7c4c
    • N
      fs: introduce mnt_clone_write · 96029c4e
      由 npiggin@suse.de 提交于 
      This patch speeds up lmbench lat_mmap test by about another 2% after the
first patch.

Before:
 avg = 462.286
 std = 5.46106

After:
 avg = 453.12
 std = 9.58257

(50 runs of each, stddev gives a reasonable confidence)

It does this by introducing mnt_clone_write, which avoids some heavyweight
operations of mnt_want_write if called on a vfsmount which we know already
has a write count; and mnt_want_write_file, which can call mnt_clone_write
if the file is open for write.

After these two patches, mnt_want_write and mnt_drop_write go from 7% on
the profile down to 1.3% (including mnt_clone_write).

[AV: mnt_want_write_file() should take file alone and derive mnt from it;
not only all callers have that form, but that's the only mnt about which
we know that it's already held for write if file is opened for write]

Cc: Dave Hansen <haveblue@us.ibm.com>
Signed-off-by: NNick Piggin <npiggin@suse.de>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      96029c4e
  25. 30 3月, 2009 1 次提交
  27. 16 3月, 2009 1 次提交
  29. 06 2月, 2009 1 次提交
  31. 01 1月, 2009 1 次提交
  33. 14 11月, 2008 3 次提交
  35. 02 11月, 2008 1 次提交
    • A
      saner FASYNC handling on file close · 233e70f4
      由 Al Viro 提交于 
      As it is, all instances of ->release() for files that have ->fasync()
need to remember to evict file from fasync lists; forgetting that
creates a hole and we actually have a bunch that *does* forget.

So let's keep our lives simple - let __fput() check FASYNC in
file->f_flags and call ->fasync() there if it's been set.  And lose that
crap in ->release() instances - leaving it there is still valid, but we
don't have to bother anymore.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      233e70f4
  37. 21 10月, 2008 1 次提交
  39. 27 7月, 2008 1 次提交
  41. 02 5月, 2008 1 次提交
  43. 19 4月, 2008 3 次提交
  45. 19 3月, 2008 1 次提交
  47. 09 2月, 2008 1 次提交
  49. 20 10月, 2007 1 次提交
  51. 17 10月, 2007 3 次提交
  53. 09 5月, 2007 1 次提交
  55. 09 12月, 2006 1 次提交