1. 23 1月, 2013 2 次提交
    • O
      ptrace: ensure arch_ptrace/ptrace_request can never race with SIGKILL · 9899d11f
      Oleg Nesterov 提交于
      putreg() assumes that the tracee is not running and pt_regs_access() can
      safely play with its stack.  However a killed tracee can return from
      ptrace_stop() to the low-level asm code and do RESTORE_REST, this means
      that debugger can actually read/modify the kernel stack until the tracee
      does SAVE_REST again.
      
      set_task_blockstep() can race with SIGKILL too and in some sense this
      race is even worse, the very fact the tracee can be woken up breaks the
      logic.
      
      As Linus suggested we can clear TASK_WAKEKILL around the arch_ptrace()
      call, this ensures that nobody can ever wakeup the tracee while the
      debugger looks at it.  Not only this fixes the mentioned problems, we
      can do some cleanups/simplifications in arch_ptrace() paths.
      
      Probably ptrace_unfreeze_traced() needs more callers, for example it
      makes sense to make the tracee killable for oom-killer before
      access_process_vm().
      
      While at it, add the comment into may_ptrace_stop() to explain why
      ptrace_stop() still can't rely on SIGKILL and signal_pending_state().
      Reported-by: NSalman Qazi <sqazi@google.com>
      Reported-by: NSuleiman Souhlal <suleiman@google.com>
      Suggested-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NOleg Nesterov <oleg@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9899d11f
    • O
      ptrace: introduce signal_wake_up_state() and ptrace_signal_wake_up() · 910ffdb1
      Oleg Nesterov 提交于
      Cleanup and preparation for the next change.
      
      signal_wake_up(resume => true) is overused. None of ptrace/jctl callers
      actually want to wakeup a TASK_WAKEKILL task, but they can't specify the
      necessary mask.
      
      Turn signal_wake_up() into signal_wake_up_state(state), reintroduce
      signal_wake_up() as a trivial helper, and add ptrace_signal_wake_up()
      which adds __TASK_TRACED.
      
      This way ptrace_signal_wake_up() can work "inside" ptrace_request()
      even if the tracee doesn't have the TASK_WAKEKILL bit set.
      Signed-off-by: NOleg Nesterov <oleg@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      910ffdb1
  2. 21 1月, 2013 9 次提交
  3. 20 1月, 2013 2 次提交
  4. 19 1月, 2013 7 次提交
  5. 18 1月, 2013 14 次提交
  6. 17 1月, 2013 6 次提交
    • J
      drm/i915: fix FORCEWAKE posting reads · b5144075
      Jani Nikula 提交于
      We stopped reading FORCEWAKE for posting reads in
      
      commit 8dee3eea
      Author: Ben Widawsky <ben@bwidawsk.net>
      Date:   Sat Sep 1 22:59:50 2012 -0700
      
          drm/i915: Never read FORCEWAKE
      
      and started using something from the same cacheline instead. On the
      bug reporter's machine this broke entering rc6 states after a
      suspend/resume cycle. It turns out reading ECOBUS as posting read
      worked fine, while GTFIFODBG did not, preventing RC6 states after
      suspend/resume per the bug report referenced below. It's not entirely
      clear why, but clearly GTFIFODBG was nowhere near the same cacheline
      or address range as FORCEWAKE.
      
      Trying out various registers for posting reads showed that all tested
      registers for which NEEDS_FORCE_WAKE() (in i915_drv.c) returns true
      work. Conversely, most (but not quite all) registers for which
      NEEDS_FORCE_WAKE() returns false do not work. Details in the referenced
      bug.
      
      Based on the above, add posting reads on ECOBUS where GTFIFODBG was
      previously relied on.
      
      In true cargo cult spirit, add posting reads for FORCEWAKE_VLV writes as
      well, but instead of ECOBUS, use FORCEWAKE_ACK_VLV which is in the same
      address range as FORCEWAKE_VLV.
      
      v2: Add more details to the commit message. No functional changes.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52411Reported-and-tested-by: NAlexander Bersenev <bay@hackerdom.ru>
      CC: Ben Widawsky <ben@bwidawsk.net>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: stable@vger.kernel.org
      [danvet: add cc: stable and make the commit message a bit clearer that
      this is a regression fix and what exactly broke.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      b5144075
    • L
      Merge tag 'for-linus-v3.8-rc4' of git://oss.sgi.com/xfs/xfs · dfdebc24
      Linus Torvalds 提交于
      Pull xfs bugfixes from Ben Myers:
      
       - fix(es) for compound buffers
      
       - fix for dquot soft timer asserts due to overflow of d_blk_softlimit
      
       - fix for regression in dir v2 code introduced in commit 20f7e9f3
         ("xfs: factor dir2 block read operations")
      
      * tag 'for-linus-v3.8-rc4' of git://oss.sgi.com/xfs/xfs:
        xfs: recalculate leaf entry pointer after compacting a dir2 block
        xfs: remove int casts from debug dquot soft limit timer asserts
        xfs: fix the multi-segment log buffer format
        xfs: fix segment in xfs_buf_item_format_segment
        xfs: rename bli_format to avoid confusion with bli_formats
        xfs: use b_maps[] for discontiguous buffers
      dfdebc24
    • L
      Merge tag 'pm+acpi-for-3.8-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm · 309b51e8
      Linus Torvalds 提交于
      Pull ACPI and power management fixes from Rafael Wysocki:
      
       - cpuidle regression fix related to the initialization of state
         kobjects from Krzysztof Mazur.
      
       - cpuidle fix removing some not very useful code and making some
         user-visible problems go away at the same time.  From Daniel Lezcano.
      
       - ACPI build fix from Yinghai Lu.
      
      * tag 'pm+acpi-for-3.8-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
        cpuidle: remove the power_specified field in the driver
        ACPI / glue: Fix build with ACPI_GLUE_DEBUG set
        cpuidle: fix number of initialized/destroyed states
      309b51e8
    • E
      xfs: recalculate leaf entry pointer after compacting a dir2 block · 37f13561
      Eric Sandeen 提交于
      Dave Jones hit this assert when doing a compile on recent git, with
      CONFIG_XFS_DEBUG enabled:
      
      XFS: Assertion failed: (char *)dup - (char *)hdr == be16_to_cpu(*xfs_dir2_data_unused_tag_p(dup)), file: fs/xfs/xfs_dir2_data.c, line: 828
      
      Upon further digging, the tag found by xfs_dir2_data_unused_tag_p(dup)
      contained "2" and not the proper offset, and I found that this value was
      changed after the memmoves under "Use a stale leaf for our new entry."
      in xfs_dir2_block_addname(), i.e.
      
                              memmove(&blp[mid + 1], &blp[mid],
                                      (highstale - mid) * sizeof(*blp));
      
      overwrote it.
      
      What has happened is that the previous call to xfs_dir2_block_compact()
      has rearranged things; it changes btp->count as well as the
      blp array.  So after we make that call, we must recalculate the
      proper pointer to the leaf entries by making another call to
      xfs_dir2_block_leaf_p().
      
      Dave provided a metadump image which led to a simple reproducer
      (create a particular filename in the affected directory) and this
      resolves the testcase as well as the bug on his live system.
      
      Thanks also to dchinner for looking at this one with me.
      Signed-off-by: NEric Sandeen <sandeen@redhat.com>
      Tested-by: NDave Jones <davej@redhat.com>
      Reviewed-by: NDave Chinner <dchinner@redhat.com>
      Reviewed-by: NMark Tinguely <tinguely@sgi.com>
      Signed-off-by: NBen Myers <bpm@sgi.com>
      37f13561
    • B
      xfs: remove int casts from debug dquot soft limit timer asserts · ab7eac22
      Brian Foster 提交于
      The int casts here make it easy to trigger an assert with a large
      soft limit. For example, set a >4TB soft limit on an empty volume
      to reproduce a (0 > -x) comparison due to an overflow of
      d_blk_softlimit.
      Signed-off-by: NBrian Foster <bfoster@redhat.com>
      Reviewed-by: NBen Myers <bpm@sgi.com>
      Signed-off-by: NBen Myers <bpm@sgi.com>
      ab7eac22
    • M
      xfs: fix the multi-segment log buffer format · 91e4bac0
      Mark Tinguely 提交于
      Per Dave Chinner suggestion, this patch:
       1) Corrects the detection of whether a multi-segment buffer is
          still tracking data.
       2) Clears all the buffer log formats for a multi-segment buffer.
      Signed-off-by: NMark Tinguely <tinguely@sgi.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NDave Chinner <dchinner@redhat.com>
      Signed-off-by: NBen Myers <bpm@sgi.com>
      91e4bac0