1. 12 11月, 2013 1 次提交
    • P
      perf ui tui progress: Don't force a refresh during progress update · d53e57d0
      Patrick Palka 提交于
      Each call to tui_progress__update() would forcibly refresh the entire
      screen.  This is somewhat inefficient and causes noticable flickering
      during the startup of perf-report, especially on large/slow terminals.
      
      It looks like the force-refresh in tui_progress__update() serves no
      purpose other than to clear the screen so that the progress bar of a
      previous operation does not subsume that of a subsequent operation.  But
      we can do just that in a much more efficient manner by clearing only the
      region that a previous progress bar may have occupied before repainting
      the new progress bar.  Then the force-refresh could be removed with no
      change in visuals.
      
      This patch disables the slow force-refresh in tui_progress__update() and
      instead calls SLsmg_fill_region() on the entire area that the progress
      bar may occupy before repainting it.  This change makes the startup of
      perf-report much faster and appear much "smoother".
      
      It turns out that this was a big bottleneck in the startup speed of
      perf-report -- with this patch, perf-report starts up ~2x faster (1.1s
      vs 0.55s) on my machines.  (These numbers were measured by running "time
      perf report" on an 8MB perf.data and pressing 'q' immediately.)
      Signed-off-by: NPatrick Palka <patrick@parcs.ath.cx>
      Acked-by: NIngo Molnar <mingo@kernel.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/1382747149-9716-1-git-send-email-patrick@parcs.ath.cxSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      d53e57d0
  2. 11 11月, 2013 1 次提交
  3. 10 11月, 2013 2 次提交
    • O
      uprobes: Fix the memory out of bound overwrite in copy_insn() · 2ded0980
      Oleg Nesterov 提交于
      1. copy_insn() doesn't look very nice, all calculations are
         confusing and it is not immediately clear why do we read
         the 2nd page first.
      
      2. The usage of inode->i_size is wrong on 32-bit machines.
      
      3. "Instruction at end of binary" logic is simply wrong, it
         doesn't handle the case when uprobe->offset > inode->i_size.
      
         In this case "bytes" overflows, and __copy_insn() writes to
         the memory outside of uprobe->arch.insn.
      
         Yes, uprobe_register() checks i_size_read(), but this file
         can be truncated after that. All i_size checks are racy, we
         do this only to catch the obvious mistakes.
      
      Change copy_insn() to call __copy_insn() in a loop, simplify
      and fix the bytes/nbytes calculations.
      
      Note: we do not care if we read extra bytes after inode->i_size
      if we got the valid page. This is fine because the task gets the
      same page after page-fault, and arch_uprobe_analyze_insn() can't
      know how many bytes were actually read anyway.
      Signed-off-by: NOleg Nesterov <oleg@redhat.com>
      2ded0980
    • O
      uprobes: Fix the wrong usage of current->utask in uprobe_copy_process() · 70d7f987
      Oleg Nesterov 提交于
      Commit aa59c53f "uprobes: Change uprobe_copy_process() to dup
      xol_area" has a stupid typo, we need to setup t->utask->vaddr but
      the code wrongly uses current->utask.
      
      Even with this bug dup_xol_work() works "in practice", but only
      because get_unmapped_area(NULL, TASK_SIZE - PAGE_SIZE) likely
      returns the same address every time.
      Signed-off-by: NOleg Nesterov <oleg@redhat.com>
      70d7f987
  4. 07 11月, 2013 13 次提交
  5. 06 11月, 2013 19 次提交
  6. 05 11月, 2013 4 次提交