<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/tools, branch v5.4.43</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=v5.4.43</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=v5.4.43'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2020-05-27T15:46:36+00:00</updated>
<entry>
<title>KVM: selftests: Fix build for evmcs.h</title>
<updated>2020-05-27T15:46:36+00:00</updated>
<author>
<name>Peter Xu</name>
<email>peterx@redhat.com</email>
</author>
<published>2020-05-04T22:06:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=67a5c3104d126800bc5a2c155713b0b8706c3a57'/>
<id>urn:sha1:67a5c3104d126800bc5a2c155713b0b8706c3a57</id>
<content type='text'>
[ Upstream commit 8ffdaf9155ebe517cdec5edbcca19ba6e7ee9c3c ]

I got this error when building kvm selftests:

/usr/bin/ld: /home/xz/git/linux/tools/testing/selftests/kvm/libkvm.a(vmx.o):/home/xz/git/linux/tools/testing/selftests/kvm/include/evmcs.h:222: multiple definition of `current_evmcs'; /tmp/cco1G48P.o:/home/xz/git/linux/tools/testing/selftests/kvm/include/evmcs.h:222: first defined here
/usr/bin/ld: /home/xz/git/linux/tools/testing/selftests/kvm/libkvm.a(vmx.o):/home/xz/git/linux/tools/testing/selftests/kvm/include/evmcs.h:223: multiple definition of `current_vp_assist'; /tmp/cco1G48P.o:/home/xz/git/linux/tools/testing/selftests/kvm/include/evmcs.h:223: first defined here

I think it's because evmcs.h is included both in a test file and a lib file so
the structs have multiple declarations when linking.  After all it's not a good
habit to declare structs in the header files.

Cc: Vitaly Kuznetsov &lt;vkuznets@redhat.com&gt;
Signed-off-by: Peter Xu &lt;peterx@redhat.com&gt;
Message-Id: &lt;20200504220607.99627-1-peterx@redhat.com&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ftrace/selftest: make unresolved cases cause failure if --fail-unresolved set</title>
<updated>2020-05-27T15:46:33+00:00</updated>
<author>
<name>Alan Maguire</name>
<email>alan.maguire@oracle.com</email>
</author>
<published>2020-02-19T09:33:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=1ae9f1a62a5093458ab905e8e3cc1836467440c3'/>
<id>urn:sha1:1ae9f1a62a5093458ab905e8e3cc1836467440c3</id>
<content type='text'>
[ Upstream commit b730d668138cb3dd9ce78f8003986d1adae5523a ]

Currently, ftracetest will return 1 (failure) if any unresolved cases
are encountered.  The unresolved status results from modules and
programs not being available, and as such does not indicate any
issues with ftrace itself.  As such, change the behaviour of
ftracetest in line with unsupported cases; if unsupported cases
happen, ftracetest still returns 0 unless --fail-unsupported.  Here
--fail-unresolved is added and the default is to return 0 if
unresolved results occur.

Signed-off-by: Alan Maguire &lt;alan.maguire@oracle.com&gt;
Acked-by: Masami Hiramatsu &lt;mhiramat@kernel.org&gt;
Acked-by: Steven Rostedt (VMware) &lt;rostedt@goodmis.org&gt;
Signed-off-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>bpf: Test_progs, fix test_get_stack_rawtp_err.c build</title>
<updated>2020-05-20T06:20:41+00:00</updated>
<author>
<name>Kamal Mostafa</name>
<email>kamal@canonical.com</email>
</author>
<published>2020-04-28T17:21:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=ecb3f529a554fcd5b58afde1fe69be771f41901a'/>
<id>urn:sha1:ecb3f529a554fcd5b58afde1fe69be771f41901a</id>
<content type='text'>
The linux-5.4.y commit 8781011a302b ("bpf: Test_progs, add test to catch
retval refine error handling") fails to build when libbpf headers are
not installed, as it tries to include &lt;bpf/bpf_helpers.h&gt;:

  progs/test_get_stack_rawtp_err.c:4:10:
      fatal error: 'bpf/bpf_helpers.h' file not found

For 5.4-stable (only) the new test prog needs to include "bpf_helpers.h"
instead (like all the rest of progs/*.c do) because 5.4-stable does not
carry commit e01a75c15969 ("libbpf: Move bpf_{helpers, helper_defs,
endian, tracing}.h into libbpf").

Signed-off-by: Kamal Mostafa &lt;kamal@canonical.com&gt;
Fixes: 8781011a302b ("bpf: Test_progs, add test to catch retval refine error handling")
Cc: &lt;stable@vger.kernel.org&gt; # v5.4
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>selftest/bpf: fix backported test_select_reuseport selftest changes</title>
<updated>2020-05-20T06:20:40+00:00</updated>
<author>
<name>Andrii Nakryiko</name>
<email>andriin@fb.com</email>
</author>
<published>2020-05-16T00:40:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=aee43146cc103483f87c072c74833204676fb893'/>
<id>urn:sha1:aee43146cc103483f87c072c74833204676fb893</id>
<content type='text'>
Fix up RET_IF as CHECK macro to make selftests compile again.

Fixes: b911c5e8686a ("selftests: bpf: Reset global state between reuseport test runs")
Signed-off-by: Andrii Nakryiko &lt;andriin@fb.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>libbpf: Extract and generalize CPU mask parsing logic</title>
<updated>2020-05-20T06:20:40+00:00</updated>
<author>
<name>Andrii Nakryiko</name>
<email>andriin@fb.com</email>
</author>
<published>2019-12-12T01:35:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=35d9107ad30b6b075764d879a83c71227b1bb181'/>
<id>urn:sha1:35d9107ad30b6b075764d879a83c71227b1bb181</id>
<content type='text'>
commit 6803ee25f0ead1e836808acb14396bb9a9849113 upstream.

This logic is re-used for parsing a set of online CPUs. Having it as an
isolated piece of code working with input string makes it conveninent to test
this logic as well. While refactoring, also improve the robustness of original
implementation.

Signed-off-by: Andrii Nakryiko &lt;andriin@fb.com&gt;
Signed-off-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
Link: https://lore.kernel.org/bpf/20191212013548.1690564-1-andriin@fb.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;


</content>
</entry>
<entry>
<title>selftests/ftrace: Check the first record for kprobe_args_type.tc</title>
<updated>2020-05-20T06:20:14+00:00</updated>
<author>
<name>Xiao Yang</name>
<email>yangx.jy@cn.fujitsu.com</email>
</author>
<published>2020-04-07T06:34:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=d12d7bf92b08d12b426c695b6c2ff0e118284c3c'/>
<id>urn:sha1:d12d7bf92b08d12b426c695b6c2ff0e118284c3c</id>
<content type='text'>
[ Upstream commit f0c0d0cf590f71b2213b29a7ded2cde3d0a1a0ba ]

It is possible to get multiple records from trace during test and then more
than 4 arguments are assigned to ARGS.  This situation results in the failure
of kprobe_args_type.tc.  For example:
-----------------------------------------------------------
grep testprobe trace
   ftracetest-5902  [001] d... 111195.682227: testprobe: (_do_fork+0x0/0x460) arg1=334823024 arg2=334823024 arg3=0x13f4fe70 arg4=7
     pmlogger-5949  [000] d... 111195.709898: testprobe: (_do_fork+0x0/0x460) arg1=345308784 arg2=345308784 arg3=0x1494fe70 arg4=7
 grep testprobe trace
 sed -e 's/.* arg1=\(.*\) arg2=\(.*\) arg3=\(.*\) arg4=\(.*\)/\1 \2 \3 \4/'
ARGS='334823024 334823024 0x13f4fe70 7
345308784 345308784 0x1494fe70 7'
-----------------------------------------------------------

We don't care which process calls do_fork so just check the first record to
fix the issue.

Signed-off-by: Xiao Yang &lt;yangx.jy@cn.fujitsu.com&gt;
Acked-by: Masami Hiramatsu &lt;mhiramat@kernel.org&gt;
Signed-off-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>selftests/bpf: fix goto cleanup label not defined</title>
<updated>2020-05-20T06:20:07+00:00</updated>
<author>
<name>Hangbin Liu</name>
<email>liuhangbin@gmail.com</email>
</author>
<published>2020-05-15T03:38:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=a761f65879e80b43e27195c7af998684fb47e64d'/>
<id>urn:sha1:a761f65879e80b43e27195c7af998684fb47e64d</id>
<content type='text'>
kernel test robot found a warning when build bpf selftest for 5.4.y stable
tree:

prog_tests/stacktrace_build_id_nmi.c:55:3: error: label ‘cleanup’ used but not defined
   goto cleanup;
   ^~~~

This is because we are lacking upstream commit dde53c1b763b
("selftests/bpf: Convert few more selftest to skeletons"). But this
commit is too large and need more backports. To fix it, the
easiest way is just use the current goto label 'close_prog'.

Reported-by: kernel test robot &lt;rong.a.chen@intel.com&gt;
Fixes: da43712a7262 ("selftests/bpf: Skip perf hw events test if the setup disabled it")
Signed-off-by: Hangbin Liu &lt;liuhangbin@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ftrace/selftests: workaround cgroup RT scheduling issues</title>
<updated>2020-05-20T06:20:05+00:00</updated>
<author>
<name>Alan Maguire</name>
<email>alan.maguire@oracle.com</email>
</author>
<published>2020-02-19T09:33:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=23a0a0914a1e2bb630a94be9318dc95acf079be2'/>
<id>urn:sha1:23a0a0914a1e2bb630a94be9318dc95acf079be2</id>
<content type='text'>
[ Upstream commit 57c4cfd4a2eef8f94052bd7c0fce0981f74fb213 ]

wakeup_rt.tc and wakeup.tc tests in tracers/ subdirectory
fail due to the chrt command returning:

 chrt: failed to set pid 0's policy: Operation not permitted.

To work around this, temporarily disable grout RT scheduling
during ftracetest execution.  Restore original value on
test run completion.  With these changes in place, both
tests consistently pass.

Fixes: c575dea2c1a5 ("selftests/ftrace: Add wakeup_rt tracer testcase")
Fixes: c1edd060b413 ("selftests/ftrace: Add wakeup tracer testcase")
Signed-off-by: Alan Maguire &lt;alan.maguire@oracle.com&gt;
Acked-by: Steven Rostedt (VMware) &lt;rostedt@goodmis.org&gt;
Signed-off-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>objtool: Fix stack offset tracking for indirect CFAs</title>
<updated>2020-05-14T05:58:29+00:00</updated>
<author>
<name>Josh Poimboeuf</name>
<email>jpoimboe@redhat.com</email>
</author>
<published>2020-04-25T10:03:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=1a31c4456af924341c6c070880a82d52d13500f5'/>
<id>urn:sha1:1a31c4456af924341c6c070880a82d52d13500f5</id>
<content type='text'>
commit d8dd25a461e4eec7190cb9d66616aceacc5110ad upstream.

When the current frame address (CFA) is stored on the stack (i.e.,
cfa-&gt;base == CFI_SP_INDIRECT), objtool neglects to adjust the stack
offset when there are subsequent pushes or pops.  This results in bad
ORC data at the end of the ENTER_IRQ_STACK macro, when it puts the
previous stack pointer on the stack and does a subsequent push.

This fixes the following unwinder warning:

  WARNING: can't dereference registers at 00000000f0a6bdba for ip interrupt_entry+0x9f/0xa0

Fixes: 627fce14809b ("objtool: Add ORC unwind table generation")
Reported-by: Vince Weaver &lt;vincent.weaver@maine.edu&gt;
Reported-by: Dave Jones &lt;dsj@fb.com&gt;
Reported-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Reported-by: Vegard Nossum &lt;vegard.nossum@oracle.com&gt;
Reported-by: Joe Mario &lt;jmario@redhat.com&gt;
Reviewed-by: Miroslav Benes &lt;mbenes@suse.cz&gt;
Signed-off-by: Josh Poimboeuf &lt;jpoimboe@redhat.com&gt;
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: Andy Lutomirski &lt;luto@kernel.org&gt;
Cc: Jann Horn &lt;jannh@google.com&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Link: https://lore.kernel.org/r/853d5d691b29e250333332f09b8e27410b2d9924.1587808742.git.jpoimboe@redhat.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>iocost: protect iocg-&gt;abs_vdebt with iocg-&gt;waitq.lock</title>
<updated>2020-05-14T05:58:27+00:00</updated>
<author>
<name>Tejun Heo</name>
<email>tj@kernel.org</email>
</author>
<published>2020-05-04T23:27:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=34ca080088e2d2d4c6b8be02168f67bb6358a9de'/>
<id>urn:sha1:34ca080088e2d2d4c6b8be02168f67bb6358a9de</id>
<content type='text'>
commit 0b80f9866e6bbfb905140ed8787ff2af03652c0c upstream.

abs_vdebt is an atomic_64 which tracks how much over budget a given cgroup
is and controls the activation of use_delay mechanism. Once a cgroup goes
over budget from forced IOs, it has to pay it back with its future budget.
The progress guarantee on debt paying comes from the iocg being active -
active iocgs are processed by the periodic timer, which ensures that as time
passes the debts dissipate and the iocg returns to normal operation.

However, both iocg activation and vdebt handling are asynchronous and a
sequence like the following may happen.

1. The iocg is in the process of being deactivated by the periodic timer.

2. A bio enters ioc_rqos_throttle(), calls iocg_activate() which returns
   without anything because it still sees that the iocg is already active.

3. The iocg is deactivated.

4. The bio from #2 is over budget but needs to be forced. It increases
   abs_vdebt and goes over the threshold and enables use_delay.

5. IO control is enabled for the iocg's subtree and now IOs are attributed
   to the descendant cgroups and the iocg itself no longer issues IOs.

This leaves the iocg with stuck abs_vdebt - it has debt but inactive and no
further IOs which can activate it. This can end up unduly punishing all the
descendants cgroups.

The usual throttling path has the same issue - the iocg must be active while
throttled to ensure that future event will wake it up - and solves the
problem by synchronizing the throttling path with a spinlock. abs_vdebt
handling is another form of overage handling and shares a lot of
characteristics including the fact that it isn't in the hottest path.

This patch fixes the above and other possible races by strictly
synchronizing abs_vdebt and use_delay handling with iocg-&gt;waitq.lock.

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Reported-by: Vlad Dmitriev &lt;vvd@fb.com&gt;
Cc: stable@vger.kernel.org # v5.4+
Fixes: e1518f63f246 ("blk-iocost: Don't let merges push vtime into the future")
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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