Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 02 5月, 2009 4 次提交
  3. 01 5月, 2009 9 次提交
  5. 30 4月, 2009 8 次提交
  7. 29 4月, 2009 1 次提交
  9. 28 4月, 2009 4 次提交
  11. 27 4月, 2009 8 次提交
  13. 25 4月, 2009 6 次提交
    • T
      ext4: Do not try to validate extents on special files · c4b5a614
      由 Theodore Ts'o 提交于 
      The EXTENTS_FL flag should never be set on special files, but if it
is, don't bother trying to validate that the extents tree is valid,
since only files, directories, and non-fast symlinks will ever have an
extent data structure.  We perhaps should flag the filesystem as being
corrupted if we see a special file (named pipes, device nodes, Unix
domain sockets, etc.) with the EXTENTS_FL flag, but e2fsck doesn't
currently check this case, so we'll just ignore this for now, since
it's harmless.

Without this fix, a special device with the extents flag is flagged as
an error by the kernel, so it is impossible to access or delete the
inode, but e2fsck doesn't see it as a problem, leading to
confused/frustrated users.
Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      c4b5a614
    • D
      ROMFS: Advance destination buffer pointer when reading from a blockdev · 4b2b0b97
      由 David Howells 提交于 
      RomFS should advance the destination buffer pointer when reading data from a
blockdev source (the data may be split over multiple blocks, each requiring its
own sb_read() call).  Without this, all the data is copied to the beginning of
the output buffer.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Tested-by: NMichal Simek <monstr@monstr.eu>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4b2b0b97
    • D
      ROMFS: romfs_lookup() shouldn't be doing a partial name comparison · 84baf74b
      由 David Howells 提交于 
      romfs_lookup() should be using a routine akin to strcmp() on the backing store,
rather than one akin to strncmp().  If it uses the latter, it's liable to match
/bin/shutdown when looking up /bin/sh.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Tested-by: NMichal Simek <monstr@monstr.eu>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      84baf74b
    • T
      ext4: Ignore i_file_acl_high unless EXT4_FEATURE_INCOMPAT_64BIT is present · a9e81742
      由 Theodore Ts'o 提交于 
      Don't try to look at i_file_acl_high unless the INCOMPAT_64BIT feature
bit is set.  The field is normally zero, but older versions of e2fsck
didn't automatically check to make sure of this, so in the spirit of
"be liberal in what you accept", don't look at i_file_acl_high unless
we are using a 64-bit filesystem.
Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      a9e81742
    • C
      Btrfs: fix deadlocks and stalls on dead root removal · 59bc5c75
      由 Chris Mason 提交于 
      After a transaction commit, the old root of the subvol btrees are sent through
snapshot removal.  This is what actually frees up any blocks replaced by
COW, and anything the old blocks pointed to.

Snapshot deletion will pause when a transaction commit has started, which
helps to avoid a huge amount of delayed reference count updates piling up
as the transaction is trying to close.

But, this pause happens after the snapshot deletion process has asked other
procs on the system to throttle back a bit so that it can make progress.

We don't want to throttle everyone while we're waiting for the transaction
commit, it leads to deadlocks in the user transaction ioctls used by Ceph
and makes things slower in general.

This patch changes things to avoid the throttling while we sleep.
Signed-off-by: NChris Mason <chris.mason@oracle.com>
      59bc5c75
    • C
      Btrfs: fix fallocate deadlock on inode extent lock · e980b50c
      由 Chris Mason 提交于 
      The btrfs fallocate call takes an extent lock on the entire range
being fallocated, and then runs through insert_reserved_extent on each
extent as they are allocated.

The problem with this is that btrfs_drop_extents may decide to try
and take the same extent lock fallocate was already holding.  The solution
used here is to push down knowledge of the range that is already locked
going into btrfs_drop_extents.

It turns out that at least one other caller had the same bug.
Signed-off-by: NChris Mason <chris.mason@oracle.com>
      e980b50c