Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 08 12月, 2006 3 次提交
  3. 11 10月, 2006 1 次提交
  5. 01 10月, 2006 2 次提交
  7. 27 9月, 2006 3 次提交
  9. 28 8月, 2006 2 次提交
    • E
      [PATCH] ufs: truncate correction · ecdc6394
      由 Evgeniy Dushistov 提交于 
      1) When we allocated last fragment in ufs_truncate, we read page, check
   if block mapped to address, and if not trying to allocate it.  This is
   wrong behaviour, fragment may be NOT allocated, but mapped, this
   happened because of "block map" function not checked allocated fragment
   or not, it just take address of the first fragment in the block, add
   offset of fragment and return result, this is correct behaviour in
   almost all situation except call from ufs_truncate.

2) Almost all implementation of UFS, which I can investigate have such
   "defect": if you have full disk, and try truncate file, for example 3GB
   to 2MB, and have hole in this region, truncate return -ENOSPC.  I tried
   evade from this problem, but "block allocation" algorithm is tied to
   right value of i_lastfrag, and fix of this corner case may slow down of
   ordinaries scenarios, so this patch makes behavior of "truncate"
   operations similar to what other UFS implementations do.
Signed-off-by: NEvgeniy Dushistov <dushistov@mail.ru>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      ecdc6394
    • E
      [PATCH] ufs: write to hole in big file · c37336b0
      由 Evgeniy Dushistov 提交于 
      On UFS, this scenario:
	open(O_TRUNC)
	lseek(1024 * 1024 * 80)
	write("A")
	lseek(1024 * 2)
	write("A")

may cause access to invalid address.

This happened because of "goal" is calculated in wrong way in block
allocation path, as I see this problem exists also in 2.4.

We use construction like this i_data[lastfrag], i_data array of pointers to
direct blocks, indirect and so on, it has ceratain size ~20 elements, and
lastfrag may have value for example 40000.

Also this patch fixes related to handling such scenario issues, wrong
zeroing metadata, in case of block(not fragment) allocation, and wrong goal
calculation, when we allocate block
Signed-off-by: NEvgeniy Dushistov <dushistov@mail.ru>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c37336b0
  11. 06 8月, 2006 2 次提交
  13. 01 8月, 2006 1 次提交
  15. 04 7月, 2006 1 次提交
    • A
      [PATCH] lockdep: annotate the quota code · 5c81a419
      由 Arjan van de Ven 提交于 
      The quota code plays interesting games with the lock ordering; to quote Jan:

| i_mutex of inode containing quota file is acquired after all other
| quota locks. i_mutex of all other inodes is acquired before quota
| locks. Quota code makes sure (by resetting inode operations and
| setting special flag on inode) that noone tries to enter quota code
| while holding i_mutex on a quota file...

The good news is that all of this special case i_mutex grabbing happens in the
(per filesystem) low level quota write function.  For this special case we
need a new I_MUTEX_* nesting level, since this just entirely outside any of
the regular VFS locking rules for i_mutex.  I trust Jan on his blue eyes that
this is not ever going to deadlock; and based on that the patch below is what
it takes to inform lockdep of these very interesting new locking rules.

The new locking rule for the I_MUTEX_QUOTA nesting level is that this is the
deepest possible level of nesting for i_mutex, and that this only should be
used in quota write (and possibly read) function of filesystems.  This makes
the lock ordering of the I_MUTEX_* levels:

I_MUTEX_PARENT -> I_MUTEX_CHILD -> I_MUTEX_NORMAL -> I_MUTEX_QUOTA

Has no effect on non-lockdep kernels.
Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
Acked-by: NIngo Molnar <mingo@elte.hu>
Cc: Jan Kara <jack@ucw.cz>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5c81a419
  17. 02 7月, 2006 1 次提交
  19. 01 7月, 2006 1 次提交
  21. 30 6月, 2006 1 次提交
  23. 29 6月, 2006 1 次提交
  25. 28 6月, 2006 1 次提交
  27. 26 6月, 2006 19 次提交
  29. 23 6月, 2006 1 次提交