<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/kernel, branch v3.15-rc4</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>Merge branch 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip</title>
<updated>2014-05-03T15:32:48+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2014-05-03T15:32:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=0384dcae2b18db80c49117ac57ea15211ca48751'/>
<id>0384dcae2b18db80c49117ac57ea15211ca48751</id>
<content type='text'>
Pull irq fixes from Thomas Gleixner:
 "This udpate delivers:

   - A fix for dynamic interrupt allocation on x86 which is required to
     exclude the GSI interrupts from the dynamic allocatable range.

     This was detected with the newfangled tablet SoCs which have GPIOs
     and therefor allocate a range of interrupts.  The MSI allocations
     already excluded the GSI range, so we never noticed before.

   - The last missing set_irq_affinity() repair, which was delayed due
     to testing issues

   - A few bug fixes for the armada SoC interrupt controller

   - A memory allocation fix for the TI crossbar interrupt controller

   - A trivial kernel-doc warning fix"

* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  irqchip: irq-crossbar: Not allocating enough memory
  irqchip: armanda: Sanitize set_irq_affinity()
  genirq: x86: Ensure that dynamic irq allocation does not conflict
  linux/interrupt.h: fix new kernel-doc warnings
  irqchip: armada-370-xp: Fix releasing of MSIs
  irqchip: armada-370-xp: implement the -&gt;check_device() msi_chip operation
  irqchip: armada-370-xp: fix invalid cast of signed value into unsigned variable
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull irq fixes from Thomas Gleixner:
 "This udpate delivers:

   - A fix for dynamic interrupt allocation on x86 which is required to
     exclude the GSI interrupts from the dynamic allocatable range.

     This was detected with the newfangled tablet SoCs which have GPIOs
     and therefor allocate a range of interrupts.  The MSI allocations
     already excluded the GSI range, so we never noticed before.

   - The last missing set_irq_affinity() repair, which was delayed due
     to testing issues

   - A few bug fixes for the armada SoC interrupt controller

   - A memory allocation fix for the TI crossbar interrupt controller

   - A trivial kernel-doc warning fix"

* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  irqchip: irq-crossbar: Not allocating enough memory
  irqchip: armanda: Sanitize set_irq_affinity()
  genirq: x86: Ensure that dynamic irq allocation does not conflict
  linux/interrupt.h: fix new kernel-doc warnings
  irqchip: armada-370-xp: Fix releasing of MSIs
  irqchip: armada-370-xp: implement the -&gt;check_device() msi_chip operation
  irqchip: armada-370-xp: fix invalid cast of signed value into unsigned variable
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip</title>
<updated>2014-05-03T15:31:45+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2014-05-03T15:31:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=98facf0e1ee3d2db313863a283e499ed1c0b5b79'/>
<id>98facf0e1ee3d2db313863a283e499ed1c0b5b79</id>
<content type='text'>
Pull timer fixes from Thomas Gleixner:
 "This update brings along:

   - Two fixes for long standing bugs in the hrtimer code, one which
     prevents remote enqueuing and the other preventing arbitrary delays
     after a interrupt hang was detected

   - A fix in the timer wheel which prevents math overflow

   - A fix for a long standing issue with the architected ARM timer
     related to the C3STOP mechanism.

   - A trivial compile fix for nspire SoC clocksource"

* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  timer: Prevent overflow in apply_slack
  hrtimer: Prevent remote enqueue of leftmost timers
  hrtimer: Prevent all reprogramming if hang detected
  clocksource: nspire: Fix compiler warning
  clocksource: arch_arm_timer: Fix age-old arch timer C3STOP detection issue
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull timer fixes from Thomas Gleixner:
 "This update brings along:

   - Two fixes for long standing bugs in the hrtimer code, one which
     prevents remote enqueuing and the other preventing arbitrary delays
     after a interrupt hang was detected

   - A fix in the timer wheel which prevents math overflow

   - A fix for a long standing issue with the architected ARM timer
     related to the C3STOP mechanism.

   - A trivial compile fix for nspire SoC clocksource"

* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  timer: Prevent overflow in apply_slack
  hrtimer: Prevent remote enqueue of leftmost timers
  hrtimer: Prevent all reprogramming if hang detected
  clocksource: nspire: Fix compiler warning
  clocksource: arch_arm_timer: Fix age-old arch timer C3STOP detection issue
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'trace-fixes-v3.15-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace</title>
<updated>2014-05-03T15:30:44+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2014-05-03T15:30:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=00622e61eda46c7f8833afbee6bd34449a9a4e7e'/>
<id>00622e61eda46c7f8833afbee6bd34449a9a4e7e</id>
<content type='text'>
Pull tracing fix from Steven Rostedt:
 "This is a small fix where the trigger code used the wrong
  rcu_dereference().  It required rcu_dereference_sched() instead of the
  normal rcu_dereference().  It produces a nasty RCU lockdep splat due
  to the incorrect rcu notation"

Acked-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;

* tag 'trace-fixes-v3.15-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
  tracing: Use rcu_dereference_sched() for trace event triggers
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull tracing fix from Steven Rostedt:
 "This is a small fix where the trigger code used the wrong
  rcu_dereference().  It required rcu_dereference_sched() instead of the
  normal rcu_dereference().  It produces a nasty RCU lockdep splat due
  to the incorrect rcu notation"

Acked-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;

* tag 'trace-fixes-v3.15-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
  tracing: Use rcu_dereference_sched() for trace event triggers
</pre>
</div>
</content>
</entry>
<entry>
<title>tracing: Use rcu_dereference_sched() for trace event triggers</title>
<updated>2014-05-03T03:12:42+00:00</updated>
<author>
<name>Steven Rostedt (Red Hat)</name>
<email>rostedt@goodmis.org</email>
</author>
<published>2014-05-02T17:30:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=561a4fe851ccab9dd0d14989ab566f9392d9f8b5'/>
<id>561a4fe851ccab9dd0d14989ab566f9392d9f8b5</id>
<content type='text'>
As trace event triggers are now part of the mainline kernel, I added
my trace event trigger tests to my test suite I run on all my kernels.
Now these tests get run under different config options, and one of
those options is CONFIG_PROVE_RCU, which checks under lockdep that
the rcu locking primitives are being used correctly. This triggered
the following splat:

===============================
[ INFO: suspicious RCU usage. ]
3.15.0-rc2-test+ #11 Not tainted
-------------------------------
kernel/trace/trace_events_trigger.c:80 suspicious rcu_dereference_check() usage!

other info that might help us debug this:

rcu_scheduler_active = 1, debug_locks = 0
4 locks held by swapper/1/0:
 #0:  ((&amp;(&amp;j_cdbs-&gt;work)-&gt;timer)){..-...}, at: [&lt;ffffffff8104d2cc&gt;] call_timer_fn+0x5/0x1be
 #1:  (&amp;(&amp;pool-&gt;lock)-&gt;rlock){-.-...}, at: [&lt;ffffffff81059856&gt;] __queue_work+0x140/0x283
 #2:  (&amp;p-&gt;pi_lock){-.-.-.}, at: [&lt;ffffffff8106e961&gt;] try_to_wake_up+0x2e/0x1e8
 #3:  (&amp;rq-&gt;lock){-.-.-.}, at: [&lt;ffffffff8106ead3&gt;] try_to_wake_up+0x1a0/0x1e8

stack backtrace:
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.15.0-rc2-test+ #11
Hardware name:                  /DG965MQ, BIOS MQ96510J.86A.0372.2006.0605.1717 06/05/2006
 0000000000000001 ffff88007e083b98 ffffffff819f53a5 0000000000000006
 ffff88007b0942c0 ffff88007e083bc8 ffffffff81081307 ffff88007ad96d20
 0000000000000000 ffff88007af2d840 ffff88007b2e701c ffff88007e083c18
Call Trace:
 &lt;IRQ&gt;  [&lt;ffffffff819f53a5&gt;] dump_stack+0x4f/0x7c
 [&lt;ffffffff81081307&gt;] lockdep_rcu_suspicious+0x107/0x110
 [&lt;ffffffff810ee51c&gt;] event_triggers_call+0x99/0x108
 [&lt;ffffffff810e8174&gt;] ftrace_event_buffer_commit+0x42/0xa4
 [&lt;ffffffff8106aadc&gt;] ftrace_raw_event_sched_wakeup_template+0x71/0x7c
 [&lt;ffffffff8106bcbf&gt;] ttwu_do_wakeup+0x7f/0xff
 [&lt;ffffffff8106bd9b&gt;] ttwu_do_activate.constprop.126+0x5c/0x61
 [&lt;ffffffff8106eadf&gt;] try_to_wake_up+0x1ac/0x1e8
 [&lt;ffffffff8106eb77&gt;] wake_up_process+0x36/0x3b
 [&lt;ffffffff810575cc&gt;] wake_up_worker+0x24/0x26
 [&lt;ffffffff810578bc&gt;] insert_work+0x5c/0x65
 [&lt;ffffffff81059982&gt;] __queue_work+0x26c/0x283
 [&lt;ffffffff81059999&gt;] ? __queue_work+0x283/0x283
 [&lt;ffffffff810599b7&gt;] delayed_work_timer_fn+0x1e/0x20
 [&lt;ffffffff8104d3a6&gt;] call_timer_fn+0xdf/0x1be^M
 [&lt;ffffffff8104d2cc&gt;] ? call_timer_fn+0x5/0x1be
 [&lt;ffffffff81059999&gt;] ? __queue_work+0x283/0x283
 [&lt;ffffffff8104d823&gt;] run_timer_softirq+0x1a4/0x22f^M
 [&lt;ffffffff8104696d&gt;] __do_softirq+0x17b/0x31b^M
 [&lt;ffffffff81046d03&gt;] irq_exit+0x42/0x97
 [&lt;ffffffff81a08db6&gt;] smp_apic_timer_interrupt+0x37/0x44
 [&lt;ffffffff81a07a2f&gt;] apic_timer_interrupt+0x6f/0x80
 &lt;EOI&gt;  [&lt;ffffffff8100a5d8&gt;] ? default_idle+0x21/0x32
 [&lt;ffffffff8100a5d6&gt;] ? default_idle+0x1f/0x32
 [&lt;ffffffff8100ac10&gt;] arch_cpu_idle+0xf/0x11
 [&lt;ffffffff8107b3a4&gt;] cpu_startup_entry+0x1a3/0x213
 [&lt;ffffffff8102a23c&gt;] start_secondary+0x212/0x219

The cause is that the triggers are protected by rcu_read_lock_sched() but
the data is dereferenced with rcu_dereference() which expects it to
be protected with rcu_read_lock(). The proper reference should be
rcu_dereference_sched().

Cc: Tom Zanussi &lt;tom.zanussi@linux.intel.com&gt;
Cc: stable@vger.kernel.org # 3.14+
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
As trace event triggers are now part of the mainline kernel, I added
my trace event trigger tests to my test suite I run on all my kernels.
Now these tests get run under different config options, and one of
those options is CONFIG_PROVE_RCU, which checks under lockdep that
the rcu locking primitives are being used correctly. This triggered
the following splat:

===============================
[ INFO: suspicious RCU usage. ]
3.15.0-rc2-test+ #11 Not tainted
-------------------------------
kernel/trace/trace_events_trigger.c:80 suspicious rcu_dereference_check() usage!

other info that might help us debug this:

rcu_scheduler_active = 1, debug_locks = 0
4 locks held by swapper/1/0:
 #0:  ((&amp;(&amp;j_cdbs-&gt;work)-&gt;timer)){..-...}, at: [&lt;ffffffff8104d2cc&gt;] call_timer_fn+0x5/0x1be
 #1:  (&amp;(&amp;pool-&gt;lock)-&gt;rlock){-.-...}, at: [&lt;ffffffff81059856&gt;] __queue_work+0x140/0x283
 #2:  (&amp;p-&gt;pi_lock){-.-.-.}, at: [&lt;ffffffff8106e961&gt;] try_to_wake_up+0x2e/0x1e8
 #3:  (&amp;rq-&gt;lock){-.-.-.}, at: [&lt;ffffffff8106ead3&gt;] try_to_wake_up+0x1a0/0x1e8

stack backtrace:
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.15.0-rc2-test+ #11
Hardware name:                  /DG965MQ, BIOS MQ96510J.86A.0372.2006.0605.1717 06/05/2006
 0000000000000001 ffff88007e083b98 ffffffff819f53a5 0000000000000006
 ffff88007b0942c0 ffff88007e083bc8 ffffffff81081307 ffff88007ad96d20
 0000000000000000 ffff88007af2d840 ffff88007b2e701c ffff88007e083c18
Call Trace:
 &lt;IRQ&gt;  [&lt;ffffffff819f53a5&gt;] dump_stack+0x4f/0x7c
 [&lt;ffffffff81081307&gt;] lockdep_rcu_suspicious+0x107/0x110
 [&lt;ffffffff810ee51c&gt;] event_triggers_call+0x99/0x108
 [&lt;ffffffff810e8174&gt;] ftrace_event_buffer_commit+0x42/0xa4
 [&lt;ffffffff8106aadc&gt;] ftrace_raw_event_sched_wakeup_template+0x71/0x7c
 [&lt;ffffffff8106bcbf&gt;] ttwu_do_wakeup+0x7f/0xff
 [&lt;ffffffff8106bd9b&gt;] ttwu_do_activate.constprop.126+0x5c/0x61
 [&lt;ffffffff8106eadf&gt;] try_to_wake_up+0x1ac/0x1e8
 [&lt;ffffffff8106eb77&gt;] wake_up_process+0x36/0x3b
 [&lt;ffffffff810575cc&gt;] wake_up_worker+0x24/0x26
 [&lt;ffffffff810578bc&gt;] insert_work+0x5c/0x65
 [&lt;ffffffff81059982&gt;] __queue_work+0x26c/0x283
 [&lt;ffffffff81059999&gt;] ? __queue_work+0x283/0x283
 [&lt;ffffffff810599b7&gt;] delayed_work_timer_fn+0x1e/0x20
 [&lt;ffffffff8104d3a6&gt;] call_timer_fn+0xdf/0x1be^M
 [&lt;ffffffff8104d2cc&gt;] ? call_timer_fn+0x5/0x1be
 [&lt;ffffffff81059999&gt;] ? __queue_work+0x283/0x283
 [&lt;ffffffff8104d823&gt;] run_timer_softirq+0x1a4/0x22f^M
 [&lt;ffffffff8104696d&gt;] __do_softirq+0x17b/0x31b^M
 [&lt;ffffffff81046d03&gt;] irq_exit+0x42/0x97
 [&lt;ffffffff81a08db6&gt;] smp_apic_timer_interrupt+0x37/0x44
 [&lt;ffffffff81a07a2f&gt;] apic_timer_interrupt+0x6f/0x80
 &lt;EOI&gt;  [&lt;ffffffff8100a5d8&gt;] ? default_idle+0x21/0x32
 [&lt;ffffffff8100a5d6&gt;] ? default_idle+0x1f/0x32
 [&lt;ffffffff8100ac10&gt;] arch_cpu_idle+0xf/0x11
 [&lt;ffffffff8107b3a4&gt;] cpu_startup_entry+0x1a3/0x213
 [&lt;ffffffff8102a23c&gt;] start_secondary+0x212/0x219

The cause is that the triggers are protected by rcu_read_lock_sched() but
the data is dereferenced with rcu_dereference() which expects it to
be protected with rcu_read_lock(). The proper reference should be
rcu_dereference_sched().

Cc: Tom Zanussi &lt;tom.zanussi@linux.intel.com&gt;
Cc: stable@vger.kernel.org # 3.14+
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux</title>
<updated>2014-05-01T17:35:01+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2014-05-01T17:35:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=60b88f3941e1baa200d01481b40e963c44243672'/>
<id>60b88f3941e1baa200d01481b40e963c44243672</id>
<content type='text'>
Pull module fixes from Rusty Russell:
 "Fixed one missing place for the new taint flag, and remove a warning
  giving only false positives (now we finally figured out why)"

* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux:
  module: remove warning about waiting module removal.
  Fix: tracing: use 'E' instead of 'X' for unsigned module taint flag
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull module fixes from Rusty Russell:
 "Fixed one missing place for the new taint flag, and remove a warning
  giving only false positives (now we finally figured out why)"

* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux:
  module: remove warning about waiting module removal.
  Fix: tracing: use 'E' instead of 'X' for unsigned module taint flag
</pre>
</div>
</content>
</entry>
<entry>
<title>timer: Prevent overflow in apply_slack</title>
<updated>2014-04-30T11:46:17+00:00</updated>
<author>
<name>Jiri Bohac</name>
<email>jbohac@suse.cz</email>
</author>
<published>2014-04-18T15:23:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=98a01e779f3c66b0b11cd7e64d531c0e41c95762'/>
<id>98a01e779f3c66b0b11cd7e64d531c0e41c95762</id>
<content type='text'>
On architectures with sizeof(int) &lt; sizeof (long), the
computation of mask inside apply_slack() can be undefined if the
computed bit is &gt; 32.

E.g. with: expires = 0xffffe6f5 and slack = 25, we get:

expires_limit = 0x20000000e
bit = 33
mask = (1 &lt;&lt; 33) - 1  /* undefined */

On x86, mask becomes 1 and and the slack is not applied properly.
On s390, mask is -1, expires is set to 0 and the timer fires immediately.

Use 1UL &lt;&lt; bit to solve that issue.

Suggested-by: Deborah Townsend &lt;dstownse@us.ibm.com&gt;
Signed-off-by: Jiri Bohac &lt;jbohac@suse.cz&gt;
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/20140418152310.GA13654@midget.suse.cz
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
On architectures with sizeof(int) &lt; sizeof (long), the
computation of mask inside apply_slack() can be undefined if the
computed bit is &gt; 32.

E.g. with: expires = 0xffffe6f5 and slack = 25, we get:

expires_limit = 0x20000000e
bit = 33
mask = (1 &lt;&lt; 33) - 1  /* undefined */

On x86, mask becomes 1 and and the slack is not applied properly.
On s390, mask is -1, expires is set to 0 and the timer fires immediately.

Use 1UL &lt;&lt; bit to solve that issue.

Suggested-by: Deborah Townsend &lt;dstownse@us.ibm.com&gt;
Signed-off-by: Jiri Bohac &lt;jbohac@suse.cz&gt;
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/20140418152310.GA13654@midget.suse.cz
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>hrtimer: Prevent remote enqueue of leftmost timers</title>
<updated>2014-04-30T10:34:51+00:00</updated>
<author>
<name>Leon Ma</name>
<email>xindong.ma@intel.com</email>
</author>
<published>2014-04-30T08:43:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=012a45e3f4af68e86d85cce060c6c2fed56498b2'/>
<id>012a45e3f4af68e86d85cce060c6c2fed56498b2</id>
<content type='text'>
If a cpu is idle and starts an hrtimer which is not pinned on that
same cpu, the nohz code might target the timer to a different cpu.

In the case that we switch the cpu base of the timer we already have a
sanity check in place, which determines whether the timer is earlier
than the current leftmost timer on the target cpu. In that case we
enqueue the timer on the current cpu because we cannot reprogram the
clock event device on the target.

If the timers base is already the target CPU we do not have this
sanity check in place so we enqueue the timer as the leftmost timer in
the target cpus rb tree, but we cannot reprogram the clock event
device on the target cpu. So the timer expires late and subsequently
prevents the reprogramming of the target cpu clock event device until
the previously programmed event fires or a timer with an earlier
expiry time gets enqueued on the target cpu itself.

Add the same target check as we have for the switch base case and
start the timer on the current cpu if it would become the leftmost
timer on the target.

[ tglx: Rewrote subject and changelog ]

Signed-off-by: Leon Ma &lt;xindong.ma@intel.com&gt;
Link: http://lkml.kernel.org/r/1398847391-5994-1-git-send-email-xindong.ma@intel.com
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If a cpu is idle and starts an hrtimer which is not pinned on that
same cpu, the nohz code might target the timer to a different cpu.

In the case that we switch the cpu base of the timer we already have a
sanity check in place, which determines whether the timer is earlier
than the current leftmost timer on the target cpu. In that case we
enqueue the timer on the current cpu because we cannot reprogram the
clock event device on the target.

If the timers base is already the target CPU we do not have this
sanity check in place so we enqueue the timer as the leftmost timer in
the target cpus rb tree, but we cannot reprogram the clock event
device on the target cpu. So the timer expires late and subsequently
prevents the reprogramming of the target cpu clock event device until
the previously programmed event fires or a timer with an earlier
expiry time gets enqueued on the target cpu itself.

Add the same target check as we have for the switch base case and
start the timer on the current cpu if it would become the leftmost
timer on the target.

[ tglx: Rewrote subject and changelog ]

Signed-off-by: Leon Ma &lt;xindong.ma@intel.com&gt;
Link: http://lkml.kernel.org/r/1398847391-5994-1-git-send-email-xindong.ma@intel.com
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>hrtimer: Prevent all reprogramming if hang detected</title>
<updated>2014-04-30T10:34:51+00:00</updated>
<author>
<name>Stuart Hayes</name>
<email>stuart.w.hayes@gmail.com</email>
</author>
<published>2014-04-29T22:55:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6c6c0d5a1c949d2e084706f9e5fb1fccc175b265'/>
<id>6c6c0d5a1c949d2e084706f9e5fb1fccc175b265</id>
<content type='text'>
If the last hrtimer interrupt detected a hang it sets hang_detected=1
and programs the clock event device with a delay to let the system
make progress.

If hang_detected == 1, we prevent reprogramming of the clock event
device in hrtimer_reprogram() but not in hrtimer_force_reprogram().

This can lead to the following situation:

hrtimer_interrupt()
   hang_detected = 1;
   program ce device to Xms from now (hang delay)

We have two timers pending:
   T1 expires 50ms from now
   T2 expires 5s from now

Now T1 gets canceled, which causes hrtimer_force_reprogram() to be
invoked, which in turn programs the clock event device to T2 (5
seconds from now).

Any hrtimer_start after that will not reprogram the hardware due to
hang_detected still being set. So we effectivly block all timers until
the T2 event fires and cleans up the hang situation.

Add a check for hang_detected to hrtimer_force_reprogram() which
prevents the reprogramming of the hang delay in the hardware
timer. The subsequent hrtimer_interrupt will resolve all outstanding
issues.

[ tglx: Rewrote subject and changelog and fixed up the comment in
  	hrtimer_force_reprogram() ]

Signed-off-by: Stuart Hayes &lt;stuart.w.hayes@gmail.com&gt;
Link: http://lkml.kernel.org/r/53602DC6.2060101@gmail.com
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If the last hrtimer interrupt detected a hang it sets hang_detected=1
and programs the clock event device with a delay to let the system
make progress.

If hang_detected == 1, we prevent reprogramming of the clock event
device in hrtimer_reprogram() but not in hrtimer_force_reprogram().

This can lead to the following situation:

hrtimer_interrupt()
   hang_detected = 1;
   program ce device to Xms from now (hang delay)

We have two timers pending:
   T1 expires 50ms from now
   T2 expires 5s from now

Now T1 gets canceled, which causes hrtimer_force_reprogram() to be
invoked, which in turn programs the clock event device to T2 (5
seconds from now).

Any hrtimer_start after that will not reprogram the hardware due to
hang_detected still being set. So we effectivly block all timers until
the T2 event fires and cleans up the hang situation.

Add a check for hang_detected to hrtimer_force_reprogram() which
prevents the reprogramming of the hang delay in the hardware
timer. The subsequent hrtimer_interrupt will resolve all outstanding
issues.

[ tglx: Rewrote subject and changelog and fixed up the comment in
  	hrtimer_force_reprogram() ]

Signed-off-by: Stuart Hayes &lt;stuart.w.hayes@gmail.com&gt;
Link: http://lkml.kernel.org/r/53602DC6.2060101@gmail.com
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'trace-fixes-v3.15-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace</title>
<updated>2014-04-28T23:57:51+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2014-04-28T23:57:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=2aafe1a4d451866e3e7b476e2fa0813b69b313c1'/>
<id>2aafe1a4d451866e3e7b476e2fa0813b69b313c1</id>
<content type='text'>
Pull ftrace bugfix from Steven Rostedt:
 "Takao Indoh reported that he was able to cause a ftrace bug while
  loading a module and enabling function tracing at the same time.

  He uncovered a race where the module when loaded will convert the
  calls to mcount into nops, and expects the module's text to be RW.
  But when function tracing is enabled, it will convert all kernel text
  (core and module) from RO to RW to convert the nops to calls to ftrace
  to record the function.  After the convertion, it will convert all the
  text back from RW to RO.

  The issue is, it will also convert the module's text that is loading.
  If it converts it to RO before ftrace does its conversion, it will
  cause ftrace to fail and require a reboot to fix it again.

  This patch moves the ftrace module update that converts calls to
  mcount into nops to be done when the module state is still
  MODULE_STATE_UNFORMED.  This will ignore the module when the text is
  being converted from RW back to RO"

* tag 'trace-fixes-v3.15-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
  ftrace/module: Hardcode ftrace_module_init() call into load_module()
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull ftrace bugfix from Steven Rostedt:
 "Takao Indoh reported that he was able to cause a ftrace bug while
  loading a module and enabling function tracing at the same time.

  He uncovered a race where the module when loaded will convert the
  calls to mcount into nops, and expects the module's text to be RW.
  But when function tracing is enabled, it will convert all kernel text
  (core and module) from RO to RW to convert the nops to calls to ftrace
  to record the function.  After the convertion, it will convert all the
  text back from RW to RO.

  The issue is, it will also convert the module's text that is loading.
  If it converts it to RO before ftrace does its conversion, it will
  cause ftrace to fail and require a reboot to fix it again.

  This patch moves the ftrace module update that converts calls to
  mcount into nops to be done when the module state is still
  MODULE_STATE_UNFORMED.  This will ignore the module when the text is
  being converted from RW back to RO"

* tag 'trace-fixes-v3.15-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
  ftrace/module: Hardcode ftrace_module_init() call into load_module()
</pre>
</div>
</content>
</entry>
<entry>
<title>ftrace/module: Hardcode ftrace_module_init() call into load_module()</title>
<updated>2014-04-28T14:37:21+00:00</updated>
<author>
<name>Steven Rostedt (Red Hat)</name>
<email>rostedt@goodmis.org</email>
</author>
<published>2014-04-24T14:40:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=a949ae560a511fe4e3adf48fa44fefded93e5c2b'/>
<id>a949ae560a511fe4e3adf48fa44fefded93e5c2b</id>
<content type='text'>
A race exists between module loading and enabling of function tracer.

	CPU 1				CPU 2
	-----				-----
  load_module()
   module-&gt;state = MODULE_STATE_COMING

				register_ftrace_function()
				 mutex_lock(&amp;ftrace_lock);
				 ftrace_startup()
				  update_ftrace_function();
				   ftrace_arch_code_modify_prepare()
				    set_all_module_text_rw();
				   &lt;enables-ftrace&gt;
				    ftrace_arch_code_modify_post_process()
				     set_all_module_text_ro();

				[ here all module text is set to RO,
				  including the module that is
				  loading!! ]

   blocking_notifier_call_chain(MODULE_STATE_COMING);
    ftrace_init_module()

     [ tries to modify code, but it's RO, and fails!
       ftrace_bug() is called]

When this race happens, ftrace_bug() will produces a nasty warning and
all of the function tracing features will be disabled until reboot.

The simple solution is to treate module load the same way the core
kernel is treated at boot. To hardcode the ftrace function modification
of converting calls to mcount into nops. This is done in init/main.c
there's no reason it could not be done in load_module(). This gives
a better control of the changes and doesn't tie the state of the
module to its notifiers as much. Ftrace is special, it needs to be
treated as such.

The reason this would work, is that the ftrace_module_init() would be
called while the module is in MODULE_STATE_UNFORMED, which is ignored
by the set_all_module_text_ro() call.

Link: http://lkml.kernel.org/r/1395637826-3312-1-git-send-email-indou.takao@jp.fujitsu.com

Reported-by: Takao Indoh &lt;indou.takao@jp.fujitsu.com&gt;
Acked-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Cc: stable@vger.kernel.org # 2.6.38+
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A race exists between module loading and enabling of function tracer.

	CPU 1				CPU 2
	-----				-----
  load_module()
   module-&gt;state = MODULE_STATE_COMING

				register_ftrace_function()
				 mutex_lock(&amp;ftrace_lock);
				 ftrace_startup()
				  update_ftrace_function();
				   ftrace_arch_code_modify_prepare()
				    set_all_module_text_rw();
				   &lt;enables-ftrace&gt;
				    ftrace_arch_code_modify_post_process()
				     set_all_module_text_ro();

				[ here all module text is set to RO,
				  including the module that is
				  loading!! ]

   blocking_notifier_call_chain(MODULE_STATE_COMING);
    ftrace_init_module()

     [ tries to modify code, but it's RO, and fails!
       ftrace_bug() is called]

When this race happens, ftrace_bug() will produces a nasty warning and
all of the function tracing features will be disabled until reboot.

The simple solution is to treate module load the same way the core
kernel is treated at boot. To hardcode the ftrace function modification
of converting calls to mcount into nops. This is done in init/main.c
there's no reason it could not be done in load_module(). This gives
a better control of the changes and doesn't tie the state of the
module to its notifiers as much. Ftrace is special, it needs to be
treated as such.

The reason this would work, is that the ftrace_module_init() would be
called while the module is in MODULE_STATE_UNFORMED, which is ignored
by the set_all_module_text_ro() call.

Link: http://lkml.kernel.org/r/1395637826-3312-1-git-send-email-indou.takao@jp.fujitsu.com

Reported-by: Takao Indoh &lt;indou.takao@jp.fujitsu.com&gt;
Acked-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Cc: stable@vger.kernel.org # 2.6.38+
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
