Skip to content

L
linux
Switch branch/tag
  1. 24 Apr, 2016 2 commits
    • Jan Kara's avatar
      ext4: fix data exposure after a crash · 06bd3c36
      Jan Kara authored 
      Huang has reported that in his powerfail testing he is seeing stale
block contents in some of recently allocated blocks although he mounts
ext4 in data=ordered mode. After some investigation I have found out
that indeed when delayed allocation is used, we don't add inode to
transaction's list of inodes needing flushing before commit. Originally
we were doing that but commit f3b59291 removed the logic with a
flawed argument that it is not needed.

The problem is that although for delayed allocated blocks we write their
contents immediately after allocating them, there is no guarantee that
the IO scheduler or device doesn't reorder things and thus transaction
allocating blocks and attaching them to inode can reach stable storage
before actual block contents. Actually whenever we attach freshly
allocated blocks to inode using a written extent, we should add inode to
transaction's ordered inode list to make sure we properly wait for block
contents to be written before committing the transaction. So that is
what we do in this patch. This also handles other cases where stale data
exposure was possible - like filling hole via mmap in
data=ordered,nodelalloc mode.

The only exception to the above rule are extending direct IO writes where
blkdev_direct_IO() waits for IO to complete before increasing i_size and
thus stale data exposure is not possible. For now we don't complicate
the code with optimizing this special case since the overhead is pretty
low. In case this is observed to be a performance problem we can always
handle it using a special flag to ext4_map_blocks().

CC: stable@vger.kernel.org
Fixes: f3b59291Reported-by: default avatar"HUANG Weller (CM/ESW12-CN)" <Weller.Huang@cn.bosch.com>
Tested-by: default avatar"HUANG Weller (CM/ESW12-CN)" <Weller.Huang@cn.bosch.com>
Signed-off-by: default avatarJan Kara <jack@suse.cz>
Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      06bd3c36
    • Theodore Ts'o's avatar
      ext4: allow readdir()'s of large empty directories to be interrupted · 1f60fbe7
      Theodore Ts'o authored 
      If a directory has a large number of empty blocks, iterating over all
of them can take a long time, leading to scheduler warnings and users
getting irritated when they can't kill a process in the middle of one
of these long-running readdir operations.  Fix this by adding checks to
ext4_readdir() and ext4_htree_fill_tree().

This was reverted earlier due to a typo in the original commit where I
experimented with using signal_pending() instead of
fatal_signal_pending().  The test was in the wrong place if we were
going to return signal_pending() since we would end up returning
duplicant entries.  See 9f2394c9 for a more detailed explanation.

Added fix as suggested by Linus to check for signal_pending() in
in the filldir() functions.
Reported-by: default avatarBenjamin LaHaise <bcrl@kvack.org>
Google-Bug-Id: 27880676
Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      1f60fbe7
  3. 18 Apr, 2016 1 commit
  5. 17 Apr, 2016 5 commits
  7. 16 Apr, 2016 7 commits
  9. 15 Apr, 2016 17 commits
  11. 14 Apr, 2016 8 commits
    • Mike Snitzer's avatar
      dm cache metadata: fix READ_LOCK macros and cleanup WRITE_LOCK macros · 9567366f
      Mike Snitzer authored 
      The READ_LOCK macro was incorrectly returning -EINVAL if
dm_bm_is_read_only() was true -- it will always be true once the cache
metadata transitions to read-only by dm_cache_metadata_set_read_only().

Wrap READ_LOCK and WRITE_LOCK multi-statement macros in do {} while(0).
Also, all accesses of the 'cmd' argument passed to these related macros
are now encapsulated in parenthesis.

A follow-up patch can be developed to eliminate the use of macros in
favor of pure C code.  Avoiding that now given that this needs to apply
to stable@.
Reported-by: default avatarBen Hutchings <ben@decadent.org.uk>
Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
Fixes: d14fcf3d ("dm cache: make sure every metadata function checks fail_io")
Cc: stable@vger.kernel.org
      9567366f
    • Keith Busch's avatar
      NVMe: Always use MSI/MSI-x interrupts · a5229050
      Keith Busch authored 
      Multiple users have reported device initialization failure due the driver
not receiving legacy PCI interrupts. This is not unique to any particular
controller, but has been observed on multiple platforms.

There have been no issues reported or observed when with message signaled
interrupts, so this patch attempts to use MSI-x during initialization,
falling back to MSI. If that fails, legacy would become the default.

The setup_io_queues error handling had to change as a result: the admin
queue's msix_entry used to be initialized to the legacy IRQ. The case
where nr_io_queues is 0 would fail request_irq when setting up the admin
queue's interrupt since re-enabling MSI-x fails with 0 vectors, leaving
the admin queue's msix_entry invalid. Instead, return success immediately.
Reported-by: default avatarTim Muhlemmer <muhlemmer@gmail.com>
Reported-by: default avatarJon Derrick <jonathan.derrick@intel.com>
Signed-off-by: default avatarKeith Busch <keith.busch@intel.com>
Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      a5229050
    • Linus Torvalds's avatar
      /proc/iomem: only expose physical resource addresses to privileged users · 51d7b120
      Linus Torvalds authored 
      In commit c4004b02 ("x86: remove the kernel code/data/bss resources
from /proc/iomem") I was hoping to remove the phyiscal kernel address
data from /proc/iomem entirely, but that had to be reverted because some
system programs actually use it.

This limits all the detailed resource information to properly
credentialed users instead.
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      51d7b120
    • Linus Torvalds's avatar
      pci-sysfs: use proper file capability helper function · ab0fa82b
      Linus Torvalds authored 
      The PCI config access checked the file capabilities correctly, but used
the itnernal security capability check rather than the helper function
that is actually meant for that.

The security_capable() has unusual return values and is not meant to be
used elsewhere (the only other use is in the capability checking
functions that we actually intend people to use, and this odd PCI usage
really stood out when looking around the capability code.
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ab0fa82b
    • Linus Torvalds's avatar
      Make file credentials available to the seqfile interfaces · 34dbbcdb
      Linus Torvalds authored 
      A lot of seqfile users seem to be using things like %pK that uses the
credentials of the current process, but that is actually completely
wrong for filesystem interfaces.

The unix semantics for permission checking files is to check permissions
at _open_ time, not at read or write time, and that is not just a small
detail: passing off stdin/stdout/stderr to a suid application and making
the actual IO happen in privileged context is a classic exploit
technique.

So if we want to be able to look at permissions at read time, we need to
use the file open credentials, not the current ones.  Normal file
accesses can just use "f_cred" (or any of the helper functions that do
that, like file_ns_capable()), but the seqfile interfaces do not have
any such options.

It turns out that seq_file _does_ save away the user_ns information of
the file, though.  Since user_ns is just part of the full credential
information, replace that special case with saving off the cred pointer
instead, and suddenly seq_file has all the permission information it
needs.
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      34dbbcdb
    • Linus Torvalds's avatar
      Revert "x86: remove the kernel code/data/bss resources from /proc/iomem" · 4046d6e8
      Linus Torvalds authored 
      This reverts commit c4004b02.

Sadly, my hope that nobody would actually use the special kernel entries
in /proc/iomem were dashed by kexec.  Which reads /proc/iomem explicitly
to find the kernel base address.  Nasty.

Anyway, that means we can't do the sane and simple thing and just remove
the entries, and we'll instead have to mask them out based on permissions.
Reported-by: default avatarZhengyu Zhang <zhezhang@redhat.com>
Reported-by: default avatarDave Young <dyoung@redhat.com>
Reported-by: default avatarFreeman Zhang <freeman.zhang1992@gmail.com>
Reported-by: default avatarEmrah Demir <ed@abdsec.com>
Reported-by: default avatarBaoquan He <bhe@redhat.com>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4046d6e8
    • Helge Deller's avatar
      parisc: Fix ftrace function tracer · 366dd4ea
      Helge Deller authored 
      Fix the FTRACE function tracer for 32- and 64-bit kernel.
The former code was horribly broken.

Reimplement most coding in assembly and utilize optimizations, e.g. put
mcount() and ftrace_stub() into one L1 cacheline.
Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      366dd4ea
    • Toshi Kani's avatar
      pmem: fix BUG() error in pmem.h:48 on X86_32 · cba2e47a
      Toshi Kani authored 
      After 'commit fc0c2028 ("x86, pmem: use memcpy_mcsafe()
for memcpy_from_pmem()")', probing a PMEM device hits the BUG()
error below on X86_32 kernel.

 kernel BUG at include/linux/pmem.h:48!

memcpy_from_pmem() calls arch_memcpy_from_pmem(), which is
unimplemented since CONFIG_ARCH_HAS_PMEM_API is undefined on
X86_32.

Fix the BUG() error by adding default_memcpy_from_pmem().
Acked-by: default avatarDan Williams <dan.j.williams@intel.com>
Signed-off-by: default avatarToshi Kani <toshi.kani@hpe.com>
Signed-off-by: default avatarRoss Zwisler <ross.zwisler@linux.intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
      cba2e47a
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7