On Mon, Jul 06, 2020 at 04:23:07PM -0700, Scott Branden wrote:
> Add Broadcom VK driver offload engine.
> This driver interfaces to the VK PCIe offload engine to perform
> should offload functions as video transcoding on multiple streams
> in parallel. VK device is booted from files loaded using
> request_firmware_into_buf mechanism. After booted card status is updated
> and messages can then be sent to the card.
> Such messages contain scatter gather list of addresses
> to pull data from the host to perform operations on.
>
> Signed-off-by: Scott Branden <scott.branden(a)broadcom.com>
> Signed-off-by: Desmond Yan <desmond.yan(a)broadcom.com>
nit: your S-o-b chain doesn't make sense (I would expect you at the end
since you're sending it and showing as the Author). Is it Co-developed-by?
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when…
> [...]
> +
> + max_buf = SZ_4M;
> + bufp = dma_alloc_coherent(dev,
> + max_buf,
> + &boot_dma_addr, GFP_KERNEL);
> + if (!bufp) {
> + dev_err(dev, "Error allocating 0x%zx\n", max_buf);
> + ret = -ENOMEM;
> + goto err_buf_out;
> + }
> +
> + bcm_vk_buf_notify(vk, bufp, boot_dma_addr, max_buf);
> + } else {
> + dev_err(dev, "Error invalid image type 0x%x\n", load_type);
> + ret = -EINVAL;
> + goto err_buf_out;
> + }
> +
> + ret = request_partial_firmware_into_buf(&fw, filename, dev,
> + bufp, max_buf, 0);
Unless I don't understand what's happening here, this needs to be
reordered if you're going to keep Mimi happy and disallow the device
being able to see the firmware before it has been verified. (i.e. please
load the firmware before mapping DMA across the buffer.)
--
Kees Cook
From: Uriel Guajardo <urielguajardo(a)google.com>
With these patches, KUnit can access and manually run kmemleak in every test
case. Any errors caught by kmemleak will cause the KUnit test to fail.
This patchset relies on "kunit: KASAN integration", which places the
currently running kunit test in task_struct. [1]
[1] https://lore.kernel.org/linux-kselftest/20200606040349.246780-2-davidgow@go…
Uriel Guajardo (2):
kunit: support kunit failures from debugging tools
kunit: kmemleak integration
include/kunit/test-bug.h | 15 +++++++++++++
include/kunit/test.h | 1 +
include/linux/kmemleak.h | 11 ++++++++++
lib/Kconfig.debug | 26 +++++++++++++++++++++++
lib/kunit/test.c | 46 +++++++++++++++++++++++++++++++++++-----
mm/kmemleak.c | 27 +++++++++++++++++------
6 files changed, 115 insertions(+), 11 deletions(-)
create mode 100644 include/kunit/test-bug.h
--
2.27.0.212.ge8ba1cc988-goog
The patch series introduces a mechanism to measure wakeup latency for
IPI and timer based interrupts
The motivation behind this series is to find significant deviations
behind advertised latency and resisdency values
To achieve this, we introduce a kernel module and expose its control
knobs through the debugfs interface that the selftests can engage with.
The kernel module provides the following interfaces within
/sys/kernel/debug/latency_test/ for,
1. IPI test:
ipi_cpu_dest # Destination CPU for the IPI
ipi_cpu_src # Origin of the IPI
ipi_latency_ns # Measured latency time in ns
2. Timeout test:
timeout_cpu_src # CPU on which the timer to be queued
timeout_expected_ns # Timer duration
timeout_diff_ns # Difference of actual duration vs expected timer
To include the module, check option and include as module
kernel hacking -> Cpuidle latency selftests
The selftest inserts the module, disables all the idle states and
enables them one by one testing:
1. Keeping source CPU constant, iterates through all the CPUS measuring
IPI latency for baseline (CPU is busy with "yes" workload) and the
when the CPU is at rest
2. Iterating through all the CPUs, sending expected timer durations to
be equivalent to the residency of the the deepest idle state
enabled and extracting the difference in time between the time of
wakeup and the expected timer duration
Usage
-----
Can be used in conjuction to the rest of the selftests.
Default Output location in: tools/testing/cpuidle/cpuidle.log
To run this test specifically:
$ make -C tools/testing/selftests TARGETS="cpuidle" run_tests
There are a few optinal arguments too that the script can take
[-h <help>]
[-m <location of the module>]
[-o <location of the output>]
Sample output snippet
---------------------
--IPI Latency Test---
---Enabling state: 0---
SRC_CPU DEST_CPU Base_IPI_Latency(ns) IPI_Latency(ns)
0 0 328 291
0 1 1500 1071
0 2 1070 1062
0 3 1557 1668
. . . .
Expected IPI latency(ns): 1000
Baseline Average IPI latency(ns): 1113
Observed Average IPI latency(ns): 1023
--Timeout Latency Test--
---Enabling state: 0---
Wakeup_src Baseline_delay(ns) Delay(ns)
0 3134 2128
1 2275 2107
2 2222 2198
3 2421 2325
. . . .
Expected timeout(ns): 200
Baseline Average timeout diff(ns): 2513
Observed Average timeout diff(ns): 2189
Pratik Rajesh Sampat (2):
cpuidle: Trace IPI based and timer based wakeup latency from idle
states
selftest/cpuidle: Add support for cpuidle latency measurement
drivers/cpuidle/Makefile | 1 +
drivers/cpuidle/test-cpuidle_latency.c | 150 +++++++++++++
lib/Kconfig.debug | 10 +
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/cpuidle/Makefile | 6 +
tools/testing/selftests/cpuidle/cpuidle.sh | 240 +++++++++++++++++++++
tools/testing/selftests/cpuidle/settings | 1 +
7 files changed, 409 insertions(+)
create mode 100644 drivers/cpuidle/test-cpuidle_latency.c
create mode 100644 tools/testing/selftests/cpuidle/Makefile
create mode 100755 tools/testing/selftests/cpuidle/cpuidle.sh
create mode 100644 tools/testing/selftests/cpuidle/settings
--
2.25.4
Calling ksft_exit_* results in executing fewer tests than planned, which
is wrong for ksft_exit_skip or suboptimal (because it results in a bail
out) for ksft_exit_fail_msg.
Using ksft_test_result_skip instead skips only one test and lets the
test plan proceed as promised by ksft_set_plan.
Paolo
v3->v4: remove useless initialization
Paolo Bonzini (2):
selftests: pidfd: do not use ksft_exit_skip after ksft_set_plan
selftests: pidfd: skip test if unshare fails with EPERM
tools/testing/selftests/pidfd/pidfd_test.c | 55 ++++++++++++++++++----
1 file changed, 46 insertions(+), 9 deletions(-)
--
2.26.2
Calling ksft_exit_* results in executing fewer tests than planned, which
is wrong for ksft_exit_skip or suboptimal (because it results in a bail
out) for ksft_exit_fail_msg.
Using ksft_test_result_skip instead skips only one test and lets the
test plan proceed as promised by ksft_set_plan.
Paolo
Paolo Bonzini (2):
selftests: pidfd: do not use ksft_exit_skip after ksft_set_plan
selftests: pidfd: skip test if unshare fails with EPERM
tools/testing/selftests/pidfd/pidfd_test.c | 55 ++++++++++++++++++----
1 file changed, 46 insertions(+), 9 deletions(-)
--
2.26.2
From: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
commit 5be206eaac9a68992fc3b06fb5dd5634e323de86 upstream.
The reverted commit illegitly uses tpm2-tools. External dependencies are
absolutely forbidden from these tests. There is also the problem that
clearing is not necessarily wanted behavior if the test/target computer is
not used only solely for testing.
Fixes: a9920d3bad40 ("tpm: selftest: cleanup after unseal with wrong auth/policy test")
Cc: Tadeusz Struk <tadeusz.struk(a)intel.com>
Cc: stable(a)vger.kernel.org
Cc: linux-integrity(a)vger.kernel.org
Cc: linux-kselftest(a)vger.kernel.org
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
Signed-off-by: Shuah Khan <skhan(a)linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/testing/selftests/tpm2/test_smoke.sh | 5 -----
1 file changed, 5 deletions(-)
--- a/tools/testing/selftests/tpm2/test_smoke.sh
+++ b/tools/testing/selftests/tpm2/test_smoke.sh
@@ -3,8 +3,3 @@
python -m unittest -v tpm2_tests.SmokeTest
python -m unittest -v tpm2_tests.AsyncTest
-
-CLEAR_CMD=$(which tpm2_clear)
-if [ -n $CLEAR_CMD ]; then
- tpm2_clear -T device
-fi
This is v2 of the patch to fix TAP output for skipped tests. I noticed
and fixed two other occurrences of "not ok ... # SKIP" which according
to the TAP specification should be marked as "ok ... # SKIP" instead.
Unfortunately, closer analysis showed ksft_exit_skip to be a badly
misused API. It should be used when the remainder of the testcase
is being skipped, but TAP only supports this before the test plan
has been emitted (in which case you're supposed to print "1..0 # SKIP".
Therefore, in patch 1 I'm mostly trying to do something sensible,
printing "1..0 # SKIP" is possible or "ok ... # SKIP" if not (which is
no worse than what was doing before). The remaining five patches
show what needs to be done in order to avoid ksft_exit_skip misuse;
while working on them I found other bugs that I've fixed at the same
time; see patch 2 for an example.
In the interest of full disclosure, I won't be able to do more cleanups
of ksft_exit_skip callers. However, I have fixed all those that did
call ksft_set_plan() as those at least try to produce TAP output.
Paolo
Paolo Bonzini (6):
kselftest: fix TAP output for skipped tests
selftests: breakpoints: fix computation of test plan
selftests: breakpoints: do not use ksft_exit_skip after ksft_set_plan
selftests: pidfd: do not use ksft_exit_skip after ksft_set_plan
selftests: sigaltstack: do not use ksft_exit_skip after ksft_set_plan
selftests: sync_test: do not use ksft_exit_skip after ksft_set_plan
.../breakpoints/step_after_suspend_test.c | 53 +++++++++++--------
tools/testing/selftests/kselftest.h | 28 +++++++---
tools/testing/selftests/kselftest/runner.sh | 2 +-
tools/testing/selftests/pidfd/pidfd_test.c | 39 +++++++++++---
tools/testing/selftests/sigaltstack/sas.c | 4 +-
tools/testing/selftests/sync/sync_test.c | 2 +-
6 files changed, 87 insertions(+), 41 deletions(-)
--
2.26.2
The --defconfig option in kunit_tool was removed in [1], but the getting
started and kunit_tool documentation still encouraged its use. Update
those documents to reflect that it's no-longer required, and is the
default behaviour if no .kunitconfig is found.
Also update a couple of places where .kunitconfig is still referred to
as kunitconfig (this was changed in [2]).
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git/c…
[2]:
https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git/c…
Signed-off-by: David Gow <davidgow(a)google.com>
---
Documentation/dev-tools/kunit/kunit-tool.rst | 17 +++++------------
Documentation/dev-tools/kunit/start.rst | 2 +-
2 files changed, 6 insertions(+), 13 deletions(-)
diff --git a/Documentation/dev-tools/kunit/kunit-tool.rst b/Documentation/dev-tools/kunit/kunit-tool.rst
index 949af2da81e5..29ae2fee8123 100644
--- a/Documentation/dev-tools/kunit/kunit-tool.rst
+++ b/Documentation/dev-tools/kunit/kunit-tool.rst
@@ -19,13 +19,13 @@ compiles the kernel as a standalone Linux executable that can be run like any
other program directly inside of a host operating system. To be clear, it does
not require any virtualization support: it is just a regular program.
-What is a kunitconfig?
-======================
+What is a .kunitconfig?
+=======================
It's just a defconfig that kunit_tool looks for in the base directory.
kunit_tool uses it to generate a .config as you might expect. In addition, it
verifies that the generated .config contains the CONFIG options in the
-kunitconfig; the reason it does this is so that it is easy to be sure that a
+.kunitconfig; the reason it does this is so that it is easy to be sure that a
CONFIG that enables a test actually ends up in the .config.
How do I use kunit_tool?
@@ -46,16 +46,9 @@ However, you most likely want to use it with the following options:
- ``--timeout`` sets a maximum amount of time to allow tests to run.
- ``--jobs`` sets the number of threads to use to build the kernel.
-If you just want to use the defconfig that ships with the kernel, you can
-append the ``--defconfig`` flag as well:
-
-.. code-block:: bash
-
- ./tools/testing/kunit/kunit.py run --timeout=30 --jobs=`nproc --all` --defconfig
-
.. note::
- This command is particularly helpful for getting started because it
- just works. No kunitconfig needs to be present.
+ This command will work even without a .kunitconfig file: if no
+ .kunitconfig is present, a default one will be used instead.
For a list of all the flags supported by kunit_tool, you can run:
diff --git a/Documentation/dev-tools/kunit/start.rst b/Documentation/dev-tools/kunit/start.rst
index bb112cf70624..d23385e3e159 100644
--- a/Documentation/dev-tools/kunit/start.rst
+++ b/Documentation/dev-tools/kunit/start.rst
@@ -18,7 +18,7 @@ The wrapper can be run with:
.. code-block:: bash
- ./tools/testing/kunit/kunit.py run --defconfig
+ ./tools/testing/kunit/kunit.py run
For more information on this wrapper (also called kunit_tool) check out the
:doc:`kunit-tool` page.
--
2.27.0.212.ge8ba1cc988-goog