1. 26 7月, 2014 1 次提交
  2. 25 7月, 2014 3 次提交
  3. 24 7月, 2014 14 次提交
  4. 22 7月, 2014 3 次提交
  5. 21 7月, 2014 12 次提交
  6. 20 7月, 2014 7 次提交
    • R
      um: segv: Save regs only in case of a kernel mode fault · bb6a1b2e
      Richard Weinberger 提交于
      ...otherwise me lose user mode regs and the resulting
      stack trace is useless.
      Signed-off-by: NRichard Weinberger <richard@nod.at>
      bb6a1b2e
    • R
      um: Fix hung task in fix_range_common() · 468f6597
      Richard Weinberger 提交于
      If do_ops() fails we have to release current->mm->mmap_sem
      otherwise the failing task will never terminate.
      Reported-by: NToralf Förster <toralf.foerster@gmx.de>
      Signed-off-by: NRichard Weinberger <richard@nod.at>
      468f6597
    • R
      um: Ensure that a stub page cannot get unmapped · 284e6d39
      Richard Weinberger 提交于
      Trinity discovered an execution path such that a task
      can unmap his stub page.
      Reported-by: NToralf Förster <toralf.foerster@gmx.de>
      Signed-off-by: NRichard Weinberger <richard@nod.at>
      284e6d39
    • R
      Revert "um: Fix wait_stub_done() error handling" · ae5db6d1
      Richard Weinberger 提交于
      This reverts commit 0974a9ca.
      The real for for that issue is to release current->mm->mmap_sem in
      fix_range_common().
      Signed-off-by: NRichard Weinberger <richard@nod.at>
      ae5db6d1
    • E
      btrfs: test for valid bdev before kobj removal in btrfs_rm_device · 0bfaa9c5
      Eric Sandeen 提交于
      commit 99994cde btrfs: dev delete should remove sysfs entry
      added a btrfs_kobj_rm_device, which dereferences device->bdev...
      right after we check whether device->bdev might be NULL.
      
      I don't honestly know if it's possible to have a NULL device->bdev
      here, but assuming that it is (given the test), we need to move
      the kobject removal to be under that test.
      
      (Coverity spotted this)
      Signed-off-by: NEric Sandeen <sandeen@redhat.com>
      Signed-off-by: NChris Mason <clm@fb.com>
      0bfaa9c5
    • L
      Btrfs: fix abnormal long waiting in fsync · 98ce2ded
      Liu Bo 提交于
      xfstests generic/127 detected this problem.
      
      With commit 7fc34a62, now fsync will only flush
      data within the passed range.  This is the cause of the above problem,
      -- btrfs's fsync has a stage called 'sync log' which will wait for all the
      ordered extents it've recorded to finish.
      
      In xfstests/generic/127, with mixed operations such as truncate, fallocate,
      punch hole, and mapwrite, we get some pre-allocated extents, and mapwrite will
      mmap, and then msync.  And I find that msync will wait for quite a long time
      (about 20s in my case), thanks to ftrace, it turns out that the previous
      fallocate calls 'btrfs_wait_ordered_range()' to flush dirty pages, but as the
      range of dirty pages may be larger than 'btrfs_wait_ordered_range()' wants,
      there can be some ordered extents created but not getting corresponding pages
      flushed, then they're left in memory until we fsync which runs into the
      stage 'sync log', and fsync will just wait for the system writeback thread
      to flush those pages and get ordered extents finished, so the latency is
      inevitable.
      
      This adds a flush similar to btrfs_start_ordered_extent() in
      btrfs_wait_logged_extents() to fix that.
      Reviewed-by: NMiao Xie <miaox@cn.fujitsu.com>
      Signed-off-by: NLiu Bo <bo.li.liu@oracle.com>
      Signed-off-by: NChris Mason <clm@fb.com>
      98ce2ded
    • L
      Merge branch 'locking-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · d0571909
      Linus Torvalds 提交于
      Pull locking fixes from Thomas Gleixner:
       "The locking department delivers:
      
         - A rather large and intrusive bundle of fixes to address serious
           performance regressions introduced by the new rwsem / mcs
           technology.  Simpler solutions have been discussed, but they would
           have been ugly bandaids with more risk than doing the right thing.
      
         - Make the rwsem spin on owner technology opt-in for architectures
           and enable it only on the known to work ones.
      
         - A few fixes to the lockdep userspace library"
      
      * 'locking-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        locking/rwsem: Add CONFIG_RWSEM_SPIN_ON_OWNER
        locking/mutex: Disable optimistic spinning on some architectures
        locking/rwsem: Reduce the size of struct rw_semaphore
        locking/rwsem: Rename 'activity' to 'count'
        locking/spinlocks/mcs: Micro-optimize osq_unlock()
        locking/spinlocks/mcs: Introduce and use init macro and function for osq locks
        locking/spinlocks/mcs: Convert osq lock to atomic_t to reduce overhead
        locking/spinlocks/mcs: Rename optimistic_spin_queue() to optimistic_spin_node()
        locking/rwsem: Allow conservative optimistic spinning when readers have lock
        tools/liblockdep: Account for bitfield changes in lockdeps lock_acquire
        tools/liblockdep: Remove debug print left over from development
        tools/liblockdep: Fix comparison of a boolean value with a value of 2
      d0571909