Fix flaky results with PACKET_FANOUT_HASH depending on whether the
two flows hash into the same packet socket or not.
Also adds tests for PACKET_FANOUT_LB and PACKET_FANOUT_CPU and
replaces the counting method with a packet ring.
Signed-off-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Changes:
v3->v2: rebase (no other changes)
passes selftest
v2->v1: read f->num_members only once
fix bug: test rollover mode + flag
Minimize packet drop in a fanout group. If one socket is full,
roll over packets to another from the group. Maintain flow
affinity during normal load using an rxhash fanout policy, while
dispersing unexpected traffic storms that hit a single cpu, such
as spoofed-source DoS flows. Rollover breaks affinity for flows
arriving at saturated sockets during those conditions.
The patch adds a fanout policy ROLLOVER that rotates between sockets,
filling each socket before moving to the next. It also adds a fanout
flag ROLLOVER. If passed along with any other fanout policy, the
primary policy is applied until the chosen socket is full. Then,
rollover selects another socket, to delay packet drop until the
entire system is saturated.
Probing sockets is not free. Selecting the last used socket, as
rollover does, is a greedy approach that maximizes chance of
success, at the cost of extreme load imbalance. In practice, with
sufficiently long queues to absorb bursts, sockets are drained in
parallel and load balance looks uniform in `top`.
To avoid contention, scales counters with number of sockets and
accesses them lockfree. Values are bounds checked to ensure
correctness.
Tested using an application with 9 threads pinned to CPUs, one socket
per thread and sufficient busywork per packet operation to limits each
thread to handling 32 Kpps. When sent 500 Kpps single UDP stream
packets, a FANOUT_CPU setup processes 32 Kpps in total without this
patch, 270 Kpps with the patch. Tested with read() and with a packet
ring (V1).
Also, passes psock_fanout.c unit test added to selftests.
Signed-off-by: Willem de Bruijn <willemb@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
To save connecting and searching for a given grub menu for each test,
ktest.pl will cache the grub number it found. The problem is that
different tests might use a different grub menu, but ktest.pl will
ignore it.
Instead, have ktest.pl check if the grub menu it used to cache the
content is the same as when it grabbed the menu. If not, grab it again,
otherwise just return the cached value.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Stricter validation was introduced with commit da27a24383
("efivarfs: guid part of filenames are case-insensitive") and commit
47f531e8ba ("efivarfs: Validate filenames much more aggressively"),
which is necessary for the guid portion of efivarfs filenames, but we
don't need to be so strict with the first part, the variable name. The
UEFI specification doesn't impose any constraints on variable names
other than they be a NULL-terminated string.
The above commits caused a regression that resulted in users seeing
the following message,
$ sudo mount -v /sys/firmware/efi/efivars mount: Cannot allocate memory
whenever pstore EFI variables were present in the variable store,
since their variable names failed to pass the following check,
/* GUID should be right after the first '-' */
if (s - 1 != strchr(str, '-'))
as a typical pstore filename is of the form, dump-type0-10-1-<guid>.
The fix is trivial since the guid portion of the filename is GUID_LEN
bytes, we can use (len - GUID_LEN) to ensure the '-' character is
where we expect it to be.
(The bogus ENOMEM error value will be fixed in a separate patch.)
Reported-by: Joseph Yasi <joe.yasi@gmail.com>
Tested-by: Joseph Yasi <joe.yasi@gmail.com>
Reported-by: Lingzhu Xiang <lxiang@redhat.com>
Cc: Josh Boyer <jwboyer@redhat.com>
Cc: Jeremy Kerr <jk@ozlabs.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: <stable@vger.kernel.org> # v3.8
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
This change adds a little documentation to the tests under
tools/testing/selftests/, based on akpm's explanation.
[akpm@linux-foundation.org: move from Documentation to tools/testing/selftests/README.txt]
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Cc: Dave Young <dyoung@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The index of a line where a warning is tested can be returned
differently on different versions of gcc (or same version compiled
differently). That is, a tab + space can give different results. This
causes the warning check to produce a false positive. Removing the
index from the check fixes this issue.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
The reboot just wants to get to the next kernel. But if a warning (Call
Trace) appears, the monitor will report an error, and the reboot will
think something went wrong and power cycle the box, even though we
successfully made it to the next kernel.
Ignore warnings during the reboot until we get to the next kernel. It
will still timeout if we never get to the next kernel and then a power
cycle will happen. That's what we want it to do.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Sometimes when a test kernel passed fine, but on reboot it crashed,
ktest could get stuck and not proceed. This would be frustrating if you
let a test run overnight to find out the next morning that it was stuck
on the first test.
To fix this, I made reboot check for the REBOOT_SUCCESS_LINE. If the
line was not detected, then it would power cycle the box.
What it didn't cover was if the REBOOT_SUCCESS_LINE wasn't defined or if
a 'good' kernel did not display the line. Instead have it search for the
Linux banner "Linux version". The reboot just needs to get to the start
of the next kernel, it does not need to test if the next kernel makes it
to a boot prompt.
After we find the next kernel has booted, then we just wait for either
the REBOOT_SUCCESS_LINE to appear or the timeout.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Although the patchcheck test checks for warnings in the files that were
changed, this check does not catch warnings that were caused by header
file changes and the warnings appear in C files not touched by the
commit.
Add a new option called WARNINGS_FILE. If this option is set, then the
file it points to is read before bulid, and the file should contain a
list of known warnings. If a warning appears in the build, this file is
checked, and if the warning does not exist in this file, then it fails
the build showing the new warning.
If the WARNINGS_FILE points to a file that does not exist, this will
cause any warning in the build to fail.
A new test is also added called "make_warnings_file". This test will
create do a build and record any warnings it finds into the
WARNINGS_FILE. This test is something that can be run before other tests
to build a warnings file of "known warnings", ie, warnings that were
there before your changes.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Options are allowed to use other options, for example:
LOG_FILE = ${OUTPUT_DIR}/${MACHINE}.log
where the option LOG_FILE used the options OUTPUT_DIR and MACHINE.
But if a test option were to use a default option, it will not get
substituted:
OUTPUT_DIR = ${THIS_DIR}/${MACHINE}
TEST_START
OUTPUT_DIR = ${OUTPUT_DIR}/t1
For the above test, OUTPUT_DIR will stay literally "${OUTPUT_DIR}/t1"
and not be converted to "${THIS_DIR}/${MACHINE}/t1". When the test runs,
it will pass the ${OUTPUT_DIR} to the shell, which would probaly
interpret it as "", and the output directory will end up as "/t1".
Change the code where if a test option has its own option name in
its defined field, and a default option exists, then substitute the
default option in its place.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
The patchcheck test looks at what files are modified for each patch it
checks and makes sure that those files do not produce any warnings.
Unfortunately, when it read the diffstat, the newlines were added on the
files and this made compares miss warnings, and commits that should not
have passed, ktest let pass.
Fix this by using the perl command "chomp" that strips off whitespace at
the end of lines.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
If the user is doing a build or install bisect, there's no reason to
have them define CONSOLE, as the console does not need to be read. The
console only needs to be read for boot tests.
CONSOLE is not required for normal build or install tests, let's not
require it for bisect tests with BISECT_TYPE of build or install.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
I was curious why sys_kcmp wasn't working, which led me to the testcase.
It turned out I hadn't enabled CHECKPOINT_RESTORE in the kernel I was
testing. Add a decoding of errno to the testcase to make that obvious.
Signed-off-by: Dave Jones <davej@redhat.com>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
