<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/kernel, branch v4.13.5</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=v4.13.5</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=v4.13.5'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2017-10-05T07:47:34+00:00</updated>
<entry>
<title>futex: Fix pi_state-&gt;owner serialization</title>
<updated>2017-10-05T07:47:34+00:00</updated>
<author>
<name>Peter Zijlstra</name>
<email>peterz@infradead.org</email>
</author>
<published>2017-09-22T15:48:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=d3d86d580864a0b4430b3cd53e0487fc7a1c72c7'/>
<id>urn:sha1:d3d86d580864a0b4430b3cd53e0487fc7a1c72c7</id>
<content type='text'>
commit c74aef2d06a9f59cece89093eecc552933cba72a upstream.

There was a reported suspicion about a race between exit_pi_state_list()
and put_pi_state(). The same report mentioned the comment with
put_pi_state() said it should be called with hb-&gt;lock held, and it no
longer is in all places.

As it turns out, the pi_state-&gt;owner serialization is indeed broken. As per
the new rules:

  734009e96d19 ("futex: Change locking rules")

pi_state-&gt;owner should be serialized by pi_state-&gt;pi_mutex.wait_lock.
For the sites setting pi_state-&gt;owner we already hold wait_lock (where
required) but exit_pi_state_list() and put_pi_state() were not and
raced on clearing it.

Fixes: 734009e96d19 ("futex: Change locking rules")
Reported-by: Gratian Crisan &lt;gratian.crisan@ni.com&gt;
Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: dvhart@infradead.org
Link: https://lkml.kernel.org/r/20170922154806.jd3ffltfk24m4o4y@hirez.programming.kicks-ass.net
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>irq/generic-chip: Don't replace domain's name</title>
<updated>2017-10-05T07:47:34+00:00</updated>
<author>
<name>Jeffy Chen</name>
<email>jeffy.chen@rock-chips.com</email>
</author>
<published>2017-09-28T04:37:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=2cfa35c2f21437421d6afeda3be7d7341d2b15af'/>
<id>urn:sha1:2cfa35c2f21437421d6afeda3be7d7341d2b15af</id>
<content type='text'>
commit 72364d320644c12948786962673772f271039a4a upstream.

When generic irq chips are allocated for an irq domain the domain name is
set to the irq chip name. That was done to have named domains before the
recent changes which enforce domain naming were done.

Since then the overwrite causes a memory leak when the domain name is
dynamically allocated and even worse it would cause the domain free code to
free the wrong name pointer, which might point to a constant.

Remove the name assignment to prevent this.

Fixes: d59f6617eef0 ("genirq: Allow fwnode to carry name information only")
Signed-off-by: Jeffy Chen &lt;jeffy.chen@rock-chips.com&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Link: https://lkml.kernel.org/r/20170928043731.4764-1-jeffy.chen@rock-chips.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>sched/sysctl: Check user input value of sysctl_sched_time_avg</title>
<updated>2017-10-05T07:47:33+00:00</updated>
<author>
<name>Ethan Zhao</name>
<email>ethan.zhao@oracle.com</email>
</author>
<published>2017-09-04T05:59:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=de8c137cb712c65f59f4e97e5a3b90d75b7edf59'/>
<id>urn:sha1:de8c137cb712c65f59f4e97e5a3b90d75b7edf59</id>
<content type='text'>
commit 5ccba44ba118a5000cccc50076b0344632459779 upstream.

System will hang if user set sysctl_sched_time_avg to 0:

  [root@XXX ~]# sysctl kernel.sched_time_avg_ms=0

  Stack traceback for pid 0
  0xffff883f6406c600 0 0 1 3 R 0xffff883f6406cf50 *swapper/3
  ffff883f7ccc3ae8 0000000000000018 ffffffff810c4dd0 0000000000000000
  0000000000017800 ffff883f7ccc3d78 0000000000000003 ffff883f7ccc3bf8
  ffffffff810c4fc9 ffff883f7ccc3c08 00000000810c5043 ffff883f7ccc3c08
  Call Trace:
  &lt;IRQ&gt; [&lt;ffffffff810c4dd0&gt;] ? update_group_capacity+0x110/0x200
  [&lt;ffffffff810c4fc9&gt;] ? update_sd_lb_stats+0x109/0x600
  [&lt;ffffffff810c5507&gt;] ? find_busiest_group+0x47/0x530
  [&lt;ffffffff810c5b84&gt;] ? load_balance+0x194/0x900
  [&lt;ffffffff810ad5ca&gt;] ? update_rq_clock.part.83+0x1a/0xe0
  [&lt;ffffffff810c6d42&gt;] ? rebalance_domains+0x152/0x290
  [&lt;ffffffff810c6f5c&gt;] ? run_rebalance_domains+0xdc/0x1d0
  [&lt;ffffffff8108a75b&gt;] ? __do_softirq+0xfb/0x320
  [&lt;ffffffff8108ac85&gt;] ? irq_exit+0x125/0x130
  [&lt;ffffffff810b3a17&gt;] ? scheduler_ipi+0x97/0x160
  [&lt;ffffffff81052709&gt;] ? smp_reschedule_interrupt+0x29/0x30
  [&lt;ffffffff8173a1be&gt;] ? reschedule_interrupt+0x6e/0x80
   &lt;EOI&gt; [&lt;ffffffff815bc83c&gt;] ? cpuidle_enter_state+0xcc/0x230
  [&lt;ffffffff815bc80c&gt;] ? cpuidle_enter_state+0x9c/0x230
  [&lt;ffffffff815bc9d7&gt;] ? cpuidle_enter+0x17/0x20
  [&lt;ffffffff810cd6dc&gt;] ? cpu_startup_entry+0x38c/0x420
  [&lt;ffffffff81053373&gt;] ? start_secondary+0x173/0x1e0

Because divide-by-zero error happens in function:

update_group_capacity()
  update_cpu_capacity()
    scale_rt_capacity()
     {
          ...
          total = sched_avg_period() + delta;
          used = div_u64(avg, total);
          ...
     }

To fix this issue, check user input value of sysctl_sched_time_avg, keep
it unchanged when hitting invalid input, and set the minimum limit of
sysctl_sched_time_avg to 1 ms.

Reported-by: James Puthukattukaran &lt;james.puthukattukaran@oracle.com&gt;
Signed-off-by: Ethan Zhao &lt;ethan.zhao@oracle.com&gt;
Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: efault@gmx.de
Cc: ethan.kernel@gmail.com
Cc: keescook@chromium.org
Cc: mcgrof@kernel.org
Link: http://lkml.kernel.org/r/1504504774-18253-1-git-send-email-ethan.zhao@oracle.com
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>fix infoleak in waitid(2)</title>
<updated>2017-10-05T07:47:33+00:00</updated>
<author>
<name>Al Viro</name>
<email>viro@zeniv.linux.org.uk</email>
</author>
<published>2017-09-29T17:43:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=c8b679ba7c65457e45af7c086c5df0748522aa2f'/>
<id>urn:sha1:c8b679ba7c65457e45af7c086c5df0748522aa2f</id>
<content type='text'>
commit 6c85501f2fabcfc4fc6ed976543d252c4eaf4be9 upstream.

kernel_waitid() can return a PID, an error or 0.  rusage is filled in the first
case and waitid(2) rusage should've been copied out exactly in that case, *not*
whenever kernel_waitid() has not returned an error.  Compat variant shares that
braino; none of kernel_wait4() callers do, so the below ought to fix it.

Reported-and-tested-by: Alexander Potapenko &lt;glider@google.com&gt;
Fixes: ce72a16fa705 ("wait4(2)/waitid(2): separate copying rusage to userland")
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>seccomp: fix the usage of get/put_seccomp_filter() in seccomp_get_filter()</title>
<updated>2017-10-05T07:47:32+00:00</updated>
<author>
<name>Oleg Nesterov</name>
<email>oleg@redhat.com</email>
</author>
<published>2017-09-27T15:25:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=257ac6ecaba725861b15caa26f1f2d384e144b9b'/>
<id>urn:sha1:257ac6ecaba725861b15caa26f1f2d384e144b9b</id>
<content type='text'>
commit 66a733ea6b611aecf0119514d2dddab5f9d6c01e upstream.

As Chris explains, get_seccomp_filter() and put_seccomp_filter() can end
up using different filters. Once we drop -&gt;siglock it is possible for
task-&gt;seccomp.filter to have been replaced by SECCOMP_FILTER_FLAG_TSYNC.

Fixes: f8e529ed941b ("seccomp, ptrace: add support for dumping seccomp filters")
Reported-by: Chris Salls &lt;chrissalls5@gmail.com&gt;
Signed-off-by: Oleg Nesterov &lt;oleg@redhat.com&gt;
[tycho: add __get_seccomp_filter vs. open coding refcount_inc()]
Signed-off-by: Tycho Andersen &lt;tycho@docker.com&gt;
[kees: tweak commit log]
Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>extable: Enable RCU if it is not watching in kernel_text_address()</title>
<updated>2017-10-05T07:47:32+00:00</updated>
<author>
<name>Steven Rostedt (VMware)</name>
<email>rostedt@goodmis.org</email>
</author>
<published>2017-09-22T21:36:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=b3fa97213993d1fb0f6dfa0f0bdac1680729d355'/>
<id>urn:sha1:b3fa97213993d1fb0f6dfa0f0bdac1680729d355</id>
<content type='text'>
commit e8cac8b1d10589be45671a5ade0926a639b543b7 upstream.

If kernel_text_address() is called when RCU is not watching, it can cause an
RCU bug because is_module_text_address(), the is_kprobe_*insn_slot()
and is_bpf_text_address() functions require the use of RCU.

Only enable RCU if it is not currently watching before it calls
is_module_text_address(). The use of rcu_nmi_enter() is used to enable RCU
because kernel_text_address() can happen pretty much anywhere (like an NMI),
and even from within an NMI. It is called via save_stack_trace() that can be
called by any WARN() or tracing function, which can happen while RCU is not
watching (for example, going to or coming from idle, or during CPU take down
or bring up).

Fixes: 0be964be0 ("module: Sanitize RCU usage and locking")
Acked-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
Signed-off-by: Steven Rostedt (VMware) &lt;rostedt@goodmis.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>extable: Consolidate *kernel_text_address() functions</title>
<updated>2017-10-05T07:47:32+00:00</updated>
<author>
<name>Steven Rostedt (VMware)</name>
<email>rostedt@goodmis.org</email>
</author>
<published>2017-09-22T21:22:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=eb4cadd0abf27dccbcf8119467f0c5a94aae76f7'/>
<id>urn:sha1:eb4cadd0abf27dccbcf8119467f0c5a94aae76f7</id>
<content type='text'>
commit 9aadde91b3c035413c806619beb3e3ef6e697953 upstream.

The functionality between kernel_text_address() and _kernel_text_address()
is the same except that _kernel_text_address() does a little more (that
function needs a rename, but that can be done another time). Instead of
having duplicate code in both, simply have _kernel_text_address() calls
kernel_text_address() instead.

This is marked for stable because there's an RCU bug that can happen if
one of these functions gets called while RCU is not watching. That fix
depends on this fix to keep from having to write the fix twice.

Fixes: 0be964be0 ("module: Sanitize RCU usage and locking")
Acked-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
Signed-off-by: Steven Rostedt (VMware) &lt;rostedt@goodmis.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>rcu: Allow for page faults in NMI handlers</title>
<updated>2017-10-05T07:47:31+00:00</updated>
<author>
<name>Paul E. McKenney</name>
<email>paulmck@linux.vnet.ibm.com</email>
</author>
<published>2017-09-22T21:10:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=55c2ca358b290ae6d33866725384bae725671653'/>
<id>urn:sha1:55c2ca358b290ae6d33866725384bae725671653</id>
<content type='text'>
commit 28585a832602747cbfa88ad8934013177a3aae38 upstream.

A number of architecture invoke rcu_irq_enter() on exception entry in
order to allow RCU read-side critical sections in the exception handler
when the exception is from an idle or nohz_full CPU.  This works, at
least unless the exception happens in an NMI handler.  In that case,
rcu_nmi_enter() would already have exited the extended quiescent state,
which would mean that rcu_irq_enter() would (incorrectly) cause RCU
to think that it is again in an extended quiescent state.  This will
in turn result in lockdep splats in response to later RCU read-side
critical sections.

This commit therefore causes rcu_irq_enter() and rcu_irq_exit() to
take no action if there is an rcu_nmi_enter() in effect, thus avoiding
the unscheduled return to RCU quiescent state.  This in turn should
make the kernel safe for on-demand RCU voyeurism.

Link: http://lkml.kernel.org/r/20170922211022.GA18084@linux.vnet.ibm.com

Fixes: 0be964be0 ("module: Sanitize RCU usage and locking")
Reported-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Signed-off-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
Signed-off-by: Steven Rostedt (VMware) &lt;rostedt@goodmis.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>tracing: Remove RCU work arounds from stack tracer</title>
<updated>2017-10-05T07:47:26+00:00</updated>
<author>
<name>Steven Rostedt (VMware)</name>
<email>rostedt@goodmis.org</email>
</author>
<published>2017-09-21T17:00:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=38f8ae6d625eeebb73c47e4a2876066af3e62cdb'/>
<id>urn:sha1:38f8ae6d625eeebb73c47e4a2876066af3e62cdb</id>
<content type='text'>
commit 15516c89acce948debc4c598e03c3fee53045797 upstream.

Currently the stack tracer calls rcu_irq_enter() to make sure RCU
is watching when it records a stack trace. But if the stack tracer
is triggered while tracing inside of a rcu_irq_enter(), calling
rcu_irq_enter() unconditionally can be problematic.

The reason for having rcu_irq_enter() in the first place has been
fixed from within the saving of the stack trace code, and there's no
reason for doing it in the stack tracer itself. Just remove it.

Fixes: 0be964be0 ("module: Sanitize RCU usage and locking")
Acked-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
Suggested-by: "Paul E. McKenney" &lt;paulmck@linux.vnet.ibm.com&gt;
Signed-off-by: Steven Rostedt (VMware) &lt;rostedt@goodmis.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>tracing: Erase irqsoff trace with empty write</title>
<updated>2017-10-05T07:47:26+00:00</updated>
<author>
<name>Bo Yan</name>
<email>byan@nvidia.com</email>
</author>
<published>2017-09-18T17:03:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=422f1a31123dd1b75a1964acabb63c23566ced16'/>
<id>urn:sha1:422f1a31123dd1b75a1964acabb63c23566ced16</id>
<content type='text'>
commit 8dd33bcb7050dd6f8c1432732f930932c9d3a33e upstream.

One convenient way to erase trace is "echo &gt; trace". However, this
is currently broken if the current tracer is irqsoff tracer. This
is because irqsoff tracer use max_buffer as the default trace
buffer.

Set the max_buffer as the one to be cleared when it's the trace
buffer currently in use.

Link: http://lkml.kernel.org/r/1505754215-29411-1-git-send-email-byan@nvidia.com

Cc: &lt;mingo@redhat.com&gt;
Fixes: 4acd4d00f ("tracing: give easy way to clear trace buffer")
Signed-off-by: Bo Yan &lt;byan@nvidia.com&gt;
Signed-off-by: Steven Rostedt (VMware) &lt;rostedt@goodmis.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
