linux-sg2042/include
Linus Torvalds 4e02370f64 During testing Sedat Dilek hit a "suspicious RCU usage" splat that pointed
out a real bug. During suspend and resume the tlb_flush tracepoint is
 called when the CPU is going offline. As the CPU has been noted as offline,
 RCU is ignoring that CPU, which means that it can not use RCU protected
 locks. When tracepoints are activated, they require RCU locking, and
 if RCU is ignoring a CPU that runs a tracepoint, there is a chance that
 the tracepoint could cause corruption.
 
 The solution was to change the tracepoint into a TRACE_EVENT_CONDITION()
 which allows us to check a condition to determine if the tracepoint
 should be called or not. If the condition is not met, the rcu protected
 code will not be executed. By adding the condition
 "cpu_online(smp_processor_id())", this will prevent the RCU protected
 code from being executed if the CPU is marked offline.
 
 After adding this, another bug was discovered. As RCU checks rcu callers,
 if a rcu call is not done, there is no check (obviously). We found that
 tracepoints could be added in RCU ignored locations and not have lockdep
 complain until the tracepoint is activated. This missed places where
 tracepoints were added in places they should not have been. To fix this,
 code was added in 3.18 that if lockdep is enabled, any tracepoint will
 still call the rcu checks even if the tracepoint is not enabled. The bug
 here, is that the check does not take the CONDITION into account. As the
 condition may prevent tracepoints from being activated in RCU ignored
 areas (as the one patch does), we get false positives when we enable
 lockdep and hit a tracepoint that the condition prevents it from being
 called in a RCU ignored location. The fix for this is to add the
 CONDITION to the rcu checks, even if the tracepoint is not enabled.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQEcBAABAgAGBQJU1rQfAAoJEEjnJuOKh9ld19UH/juFLZFjpYBgtRmbCZa/54Zk
 i2Fa3U8jQe8MHHEYOjCLT9MQTYo/42btmJhr7kWKtIoUgDEli4lkOpbs+H0qar5y
 Vv9+1cLeNFQzgIE3nwV7cjAw7Jufoyzd1lstDqIQvcmzZnQ5sNyyVeigMcxGv8Ls
 4FyqzG6zCVgiDL4LyYNHdNcMr6qLs3KTFDEqp+kQreeO7R1r3ZEpq3JoWaEUgoPP
 qrYv/rqVosLBUGA0pd7RmiGOxhjeKm15qz1GkiPeeus6DDWC6bvPC8cAc/FfkXH0
 hYpoQghSZVnXGy0LzVsd44gj7tYx1FHEpYy1s8G6d5WJcNOGZ6OoZOdOZMyjPVw=
 =PeL2
 -----END PGP SIGNATURE-----

Merge tag 'trace-fixes-v3.19-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace

Pull ftrace fixes from Steven Rostedt:
 "During testing Sedat Dilek hit a "suspicious RCU usage" splat that
  pointed out a real bug.  During suspend and resume the tlb_flush
  tracepoint is called when the CPU is going offline.  As the CPU has
  been noted as offline, RCU is ignoring that CPU, which means that it
  can not use RCU protected locks.  When tracepoints are activated, they
  require RCU locking, and if RCU is ignoring a CPU that runs a
  tracepoint, there is a chance that the tracepoint could cause
  corruption.

  The solution was to change the tracepoint into a
  TRACE_EVENT_CONDITION() which allows us to check a condition to
  determine if the tracepoint should be called or not.  If the condition
  is not met, the rcu protected code will not be executed.  By adding
  the condition "cpu_online(smp_processor_id())", this will prevent the
  RCU protected code from being executed if the CPU is marked offline.

  After adding this, another bug was discovered.  As RCU checks rcu
  callers, if a rcu call is not done, there is no check (obviously).  We
  found that tracepoints could be added in RCU ignored locations and not
  have lockdep complain until the tracepoint is activated.  This missed
  places where tracepoints were added in places they should not have
  been.  To fix this, code was added in 3.18 that if lockdep is enabled,
  any tracepoint will still call the rcu checks even if the tracepoint
  is not enabled.  The bug here, is that the check does not take the
  CONDITION into account.  As the condition may prevent tracepoints from
  being activated in RCU ignored areas (as the one patch does), we get
  false positives when we enable lockdep and hit a tracepoint that the
  condition prevents it from being called in a RCU ignored location.

  The fix for this is to add the CONDITION to the rcu checks, even if
  the tracepoint is not enabled"

* tag 'trace-fixes-v3.19-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
  x86/tlb/trace: Do not trace on CPU that is offline
  tracing: Add condition check to RCU lockdep checks
2015-02-08 18:08:14 -08:00
..
acpi ACPI / processor: Convert apic_id to phys_id to make it arch agnostic 2015-01-05 23:32:42 +01:00
asm-generic mm: mmu_gather: use tlb->end != 0 only for TLB invalidation 2015-01-13 15:20:40 +13:00
clocksource
crypto crypto: af_alg - add user space interface for AEAD 2014-12-05 23:56:55 +08:00
drm Revert "drm/gem: Warn on illegal use of the dumb buffer interface v2" 2014-12-24 13:13:22 +10:00
dt-bindings ARM: dt: GIC: Spelling s/specific/specifier/, s/flaggs/flags/ 2015-01-13 13:48:16 -06:00
keys
kvm arm/arm64: KVM: Require in-kernel vgic for the arch timers 2014-12-15 11:50:42 +01:00
linux During testing Sedat Dilek hit a "suspicious RCU usage" splat that pointed 2015-02-08 18:08:14 -08:00
math-emu
media [media] media: v4l2-image-sizes.h: correct the SVGA height definition 2014-12-04 13:56:56 -02:00
memory
misc
net ipv6: fix sparse errors in ip6_make_flowlabel() 2015-02-05 00:42:28 -08:00
pcmcia
ras
rdma Revert "IB/core: Add support for extended query device caps" 2015-02-06 00:54:33 -08:00
rxrpc
scsi SCSI for-linus on 20141220 2014-12-20 13:42:57 -08:00
soc Merge branch 'at91/cleanup5' into next/drivers 2014-12-08 18:29:20 +01:00
sound ASoC: AC'97 fixes 2015-02-05 21:31:19 +01:00
target target: Drop left-over fabric_max_sectors attribute 2015-01-09 15:22:05 -08:00
trace During testing Sedat Dilek hit a "suspicious RCU usage" splat that pointed 2015-02-08 18:08:14 -08:00
uapi Revert "IB/core: Add support for extended query device caps" 2015-02-06 00:54:33 -08:00
video OMAPDSS: Remove all references to obsolete HDMI audio callbacks 2014-12-01 11:09:59 +02:00
xen x86/xen: properly retrieve NMI reason 2015-01-13 09:39:50 +00:00
Kbuild