Skip to content

L
linux
Switch branch/tag
  1. 10 Sep, 2014 6 commits
    • Dave Hansen's avatar
      tracing: generate RCU warnings even when tracepoints are disabled · 3a630178
      Dave Hansen authored 
      Dave Jones reported seeing a bug from one of my TLB tracepoints:

	http://lkml.kernel.org/r/20140806181801.GA4605@redhat.com

I've been running these patches for months and never saw this.
But, a big chunk of my testing, especially with all the debugging
enabled, was in a vm where intel_idle doesn't work.  On the
systems where I was using intel_idle, I never had lockdep enabled
and this tracepoint on at the same time.

This patch ensures that whenever we have lockdep available, we do
_some_ RCU activity at the site of the tracepoint, despite
whether the tracepoint's condition matches or even if the
tracepoint itself is completely disabled.  This is a bit of a
hack, but it is pretty self-contained.

I confirmed that with this patch plus lockdep I get the same
splat as Dave Jones did, but without enabling the tracepoint
explicitly.

Link: http://lkml.kernel.org/p/20140807175204.C257CAC5@viggo.jf.intel.comSigned-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
Cc: Dave Hansen <dave@sr71.net>
Cc: Dave Jones <davej@redhat.com>,
Cc: paulmck@linux.vnet.ibm.com
Cc: Ingo Molnar <mingo@redhat.com>
Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      3a630178
    • Steven Rostedt (Red Hat)'s avatar
      ftrace: Replace tramp_hash with old_*_hash to save space · fef5aeee
      Steven Rostedt (Red Hat) authored 
      Allowing function callbacks to declare their own trampolines requires
that each ftrace_ops that has a trampoline must have some sort of
accounting that keeps track of which ops has a trampoline attached
to a record.

The easy way to solve this was to add a "tramp_hash" that created a
hash entry for every function that a ops uses with a trampoline.
But since we can have literally tens of thousands of functions being
traced, that means we need tens of thousands of descriptors to map
the ops to the function in the hash. This is quite expensive and
can cause enabling and disabling the function graph tracer to take
some time to start and stop. It can take up to several seconds to
disable or enable all functions in the function graph tracer for this
reason.

The better approach albeit more complex, is to keep track of how ops
are being enabled and disabled, and use that along with the counting
of the number of ops attached to records, to determive what ops has
a trampoline attached to a record at enabling and disabling of
tracing.

To do this, the tramp_hash has been replaced with an old_filter_hash
and old_notrace_hash, which get the copy of the ops filter_hash and
notrace_hash respectively. The old hashes is kept until the ops has
been modified or removed and the old hashes are used with the logic
of the accounting to determine the ops that have the trampoline of
a record. The reason this has less of a footprint is due to the trick
that an "empty" hash in the filter_hash means "all functions" and
an empty hash in the notrace hash means "no functions" in the hash.

This is much more efficienct, doesn't have the delay, and takes up
much less memory, as we do not need to map all the functions but
just figure out which functions are mapped at the time it is
enabled or disabled.
Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      fef5aeee
    • Steven Rostedt (Red Hat)'s avatar
      ftrace: Annotate the ops operation on update · e1effa01
      Steven Rostedt (Red Hat) authored 
      Add three new flags for ftrace_ops:

  FTRACE_OPS_FL_ADDING
  FTRACE_OPS_FL_REMOVING
  FTRACE_OPS_FL_MODIFYING

These will be set for the ftrace_ops when they are first added
to the function tracing, being removed from function tracing
or just having their functions changed from function tracing,
respectively.

This will be needed to remove the tramp_hash, which can grow quite
big. The tramp_hash is used to note what functions a ftrace_ops
is using a trampoline for. Denoting which ftrace_ops is being
modified, will allow us to use the ftrace_ops hashes themselves,
which are much smaller as they have a global flag to denote if
a ftrace_ops is tracing all functions, as well as a notrace hash
if the ftrace_ops is tracing all but a few. The tramp_hash just
creates a hash item for every function, which can go into the 10s
of thousands if all functions are using the ftrace_ops trampoline.
Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      e1effa01
    • Steven Rostedt (Red Hat)'s avatar
      ftrace: Grab any ops for a rec for enabled_functions output · 5fecaa04
      Steven Rostedt (Red Hat) authored 
      When dumping the enabled_functions, use the first op that is
found with a trampoline to the record, as there should only be
one, as only one ops can be registered to a function that has
a trampoline.
Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      5fecaa04
    • Steven Rostedt (Red Hat)'s avatar
      ftrace: Remove freeing of old_hash from ftrace_hash_move() · 3296fc4e
      Steven Rostedt (Red Hat) authored 
      ftrace_hash_move() currently frees the old hash that is passed to it
after replacing the pointer with the new hash. Instead of having the
function do that chore, have the caller perform the free.

This lets the ftrace_hash_move() be used a bit more freely, which
is needed for changing the way the trampoline logic is done.
Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      3296fc4e
    • Steven Rostedt (Red Hat)'s avatar
      ftrace: Set callback to ftrace_stub when no ops are registered · f7aad4e1
      Steven Rostedt (Red Hat) authored 
      The clean up that adds the helper function ftrace_ops_get_func()
caused the default function to not change when DYNAMIC_FTRACE was not
set and no ftrace_ops were registered. Although static tracing is
not very useful (not having DYNAMIC_FTRACE set), it is still supported
and we don't want to break it.

Clean up the if statement even more to specifically have the default
function call ftrace_stub when no ftrace_ops are registered. This
fixes the small bug for static tracing as well as makes the code a
bit more understandable.
Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      f7aad4e1
  3. 09 Sep, 2014 2 commits
  5. 07 Sep, 2014 11 commits
  7. 06 Sep, 2014 6 commits
    • Linus Torvalds's avatar
      Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm · 2b12164b
      Linus Torvalds authored 
      Pull kvm fixes from Paolo Bonzini:
 "A smattering of bug fixes across most architectures"

* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
  powerpc/kvm/cma: Fix panic introduces by signed shift operation
  KVM: s390/mm: Fix guest storage key corruption in ptep_set_access_flags
  KVM: s390/mm: Fix storage key corruption during swapping
  arm/arm64: KVM: Complete WFI/WFE instructions
  ARM/ARM64: KVM: Nuke Hyp-mode tlbs before enabling MMU
  KVM: s390/mm: try a cow on read only pages for key ops
  KVM: s390: Fix user triggerable bug in dead code
      2b12164b
    • Linus Torvalds's avatar
      Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc · 56c22854
      Linus Torvalds authored 
      Pull ARM SoC fixes from Kevin Hilman:
 "Another round of fixes from arm-soc land, which are mostly DT fixes
  for:

   - OMAP: handful of DT fixes devices on newly supported hardware
   - davinci: fix 2nd EDMA channel
   - ux500: extend previous pinctrl fix to another board
   - at91: clock registration fixes, compatibility string precision

  And one more fix for event cleanup in drivers/bus/arm-ccn"

* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
  bus: arm-ccn: Move event cleanup routine
  ARM: at91/dt: rm9200: fix usb clock definition
  ARM: at91: rm9200: fix clock registration
  ARM: at91/dt: sam9g20: set at91sam9g20 pllb driver
  ARM: dts: dra7-evm: Add vtt regulator support
  ARM: dts: dra7-evm: Fix spi1 mux documentation
  ARM: dts: am43x-epos-evm: Disable QSPI to prevent conflict with GPMC-NAND
  ARM: OMAP2+: gpmc: Don't complain if wait pin is used without r/w monitoring
  ARM: dts: am43xx-epos-evm: Don't use read/write wait monitoring
  ARM: dts: am437x-gp-evm: Don't use read/write wait monitoring
  ARM: dts: am437x-gp-evm: Use BCH16 ECC scheme instead of BCH8
  ARM: dts: am43x-epos-evm: Use BCH16 ECC scheme instead of BCH8
  ARM: dts: am4372: fix USB regs size
  ARM: dts: am437x-gp: switch i2c0 to 100KHz
  ARM: dts: dra7-evm: Fix 8th NAND partition's name
  ARM: dts: dra7-evm: Fix i2c3 pinmux and frequency
  ARM: ux500: disable msp2 node on Snowball
  ARM: edma: Fix configuration parsing for SoCs with multiple eDMA3 CC
  ARM: dts: set 'ti,set-rate-parent' for dpll4_m5x2 clock
      56c22854
    • Linus Torvalds's avatar
      Merge tag 'xfs-for-linus-3.17-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs · 11e97398
      Linus Torvalds authored 
      Pull xfs fixes from Dave Chinner:
 "The fixes all address recently discovered data corruption issues.

  The original Direct IO issue was discovered by Chris Mason @ Facebook
  on a production workload which mixed buffered reads with direct reads
  and writes IO to the same file.  The fix for that exposed other issues
  with page invalidation (exposed by millions of fsx operations) failing
  due to dirty buffers beyond EOF.

  Finally, the collapse_range code could also cause problems due to
  racing writeback changing the extent map while it was being shifted
  around.  The commits for that problem are simple mitigation fixes that
  prevent the problem from occuring.  A more robust fix for 3.18 that
  addresses the underlying problem is currently being worked on by
  Brian.

  Summary of fixes:
   - a direct IO read/buffered read data corruption
   - the associated fallout from the DIO data corruption fix
   - collapse range bugs that are potential data corruption issues"

* tag 'xfs-for-linus-3.17-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs:
  xfs: trim eofblocks before collapse range
  xfs: xfs_file_collapse_range is delalloc challenged
  xfs: don't log inode unless extent shift makes extent modifications
  xfs: use ranged writeback and invalidation for direct IO
  xfs: don't zero partial page cache pages during O_DIRECT writes
  xfs: don't zero partial page cache pages during O_DIRECT writes
  xfs: don't dirty buffers beyond EOF
      11e97398
    • Linus Torvalds's avatar
      Merge tag 'for-linus-20140905' of git://git.infradead.org/linux-mtd · 925e0ea4
      Linus Torvalds authored 
      Pull mtd fixes from Brian Norris:
 "Two trivial MTD updates for 3.17-rc4:

   - a tiny comment tweak, to kill a bunch of DocBook warnings added
     during the merge window

   - a small fixup to the OTP routines' error handling"

* tag 'for-linus-20140905' of git://git.infradead.org/linux-mtd:
  mtd: nand: fix DocBook warnings on nand_sdr_timings doc
  mtd: cfi_cmdset_0002: check return code for get_chip()
      925e0ea4
    • Thomas Gleixner's avatar
      timekeeping: Update timekeeper before updating vsyscall and pvclock · 9bf2419f
      Thomas Gleixner authored 
      The update_walltime() code works on the shadow timekeeper to make the
seqcount protected region as short as possible. But that update to the
shadow timekeeper does not update all timekeeper fields because it's
sufficient to do that once before it becomes life. One of these fields
is tkr.base_mono. That stays stale in the shadow timekeeper unless an
operation happens which copies the real timekeeper to the shadow.

The update function is called after the update calls to vsyscall and
pvclock. While not correct, it did not cause any problems because none
of the invoked update functions used base_mono.

commit cbcf2dd3 (x86: kvm: Make kvm_get_time_and_clockread()
nanoseconds based) changed that in the kvm pvclock update function, so
the stale mono_base value got used and caused kvm-clock to malfunction.

Put the update where it belongs and fix the issue.
Reported-by: default avatarChris J Arges <chris.j.arges@canonical.com>
Reported-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
Cc: Gleb Natapov <gleb@kernel.org>
Cc: John Stultz <john.stultz@linaro.org>
Link: http://lkml.kernel.org/r/alpine.DEB.2.10.1409050000570.3333@nanosSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      9bf2419f
    • Thomas Gleixner's avatar
      compat: nanosleep: Clarify error handling · 849151dd
      Thomas Gleixner authored 
      The error handling in compat_sys_nanosleep() is correct, but
completely non obvious. Document it and restrict it to the
-ERESTART_RESTARTBLOCK return value for clarity.
Reported-by: default avatarKees Cook <keescook@chromium.org>
Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      849151dd
  9. 05 Sep, 2014 15 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7