| Age | Commit message (Collapse) | Author |
|---|
|
Some BPF commands return ENOTSUPP (524) to user space: iterating local
storage maps, element operations on ringbuf maps, creating an LRU hash
map without preallocation, freezing a struct_ops map, or running a
program type that has no test_run. ENOTSUPP is kernel internal, so
strerror() only gives "Unknown error 524":
# bpftool map getnext pinned /sys/fs/bpf/sk_storage
Error: can't get next key: Unknown error 524
Add a small helper that knows ENOTSUPP and use it where bpftool prints
the error of map create, map element operations, map freeze and prog
run.
Suggested-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Maxim Skokov <skokovmaksimevg@gmail.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Quentin Monnet <qmo@kernel.org>
Link: https://patch.msgid.link/20261016194825.230433-2-skokovmaksimevg@gmail.com
|
|
The mmap size used when none is asked for is derived from
kernel.perf_event_mlock_kb itself (see perf_event_mlock_kb_in_pages()),
that after rounding down to a power of two number of pages ends up being
about all of a single CPU's share of that per user budget, so with 'perf
test' starting all the selected tests at once, any further mapping done
while another test still has its ring buffers mapped fails with:
Permission error mapping pages.
Consider increasing /proc/sys/kernel/perf_event_mlock_kb,
or try again with a smaller value of -m/--mmap_pages.
that then shows up as a failure or, worse, as an "unsupp" skip in tests
like the attr ones, i.e. as a false pass.
Instead of making those tests exclusive, which would serialize them
against every other test, keep them running in parallel with the tests
that don't map ring buffers and have them take turns using the budget,
via a robust, process-shared mutex (see mutex_init_pshared_robust()) in
a MAP_SHARED|MAP_ANONYMOUS area that is inherited by the forked test
processes: a test killed by a signal doesn't leave the budget locked,
the kernel marks the mutex owner-died and the next locker takes it over;
a signal that is caught rather than kills ends up the same way, with the
longjmp out of child_test_sig_handler() leaving it held until the child
exits and the kernel hands it over.
Perf's struct mutex is used, so the lock discipline is checked in clang
builds via -Wthread-safety; as the thread safety analysis can't verify
conditionally held locks, the tests that map ring buffers run through a
helper taking the mutex unconditionally around the test function call.
Robust mutexes aren't always available, at build time or, as glibc and
musl can do when get_robust_list(2)/set_robust_list(2) aren't usable, at
run time: in that case the budget is not shared and the tests run as
before, failing or skipping on starvation instead of hanging on a lock
left behind by a test killed by a signal.
Taking turns is unnecessary when nothing can exhaust the budget: once it is
spent, whatever maps on top of it is charged against RLIMIT_MEMLOCK and the
mapping is refused with EPERM when that runs out too, but only for the
processes the kernel is paranoid about and that have no CAP_IPC_LOCK to
lift the check, see perf_mmap_calc_limits(). Root, then, has no turns to
take: it never has a mapping refused, so the turnstile only buys it the
wall clock cost measured below, for a budget nothing is contending for.
The area is shared by the tests of one 'perf test' invocation only: a
second invocation running at the same time maps its own, so the two
don't take turns with each other.
The sysctl is left alone. Growing it, to leave room for whatever else
the user has running, would need the original value shared between the
invocations, so that the last one out puts it back, and it only helps a
user who can write the sysctl but lacks CAP_IPC_LOCK, the one capability
that lifts the limit.
Raising the soft RLIMIT_MEMLOCK to the hard one when a mapping is refused
is left for a follow-up: it would buy back the wall clock above without
taking turns, where the hard limit allows the raise.
None of this is done when just one of the selected tests maps ring
buffers, as there is nothing to share the budget with in that case.
Taking turns isn't free: a test that hangs while holding the budget now
holds with it every other test mapping ring buffers, where before it
would fail, or skip, by itself. And there is a cost even when nothing
goes wrong, this being the whole suite on a Ryzen 9 9950X3D, kernel 7.2.7,
32 CPUs, with the default 516 KiB budget, before and after taking turns:
budget not shared: 42 s wall clock, 72 tests Ok, 28 failed
tests take turns: 133 s wall clock, 101 tests Ok, 10 failed
Both are non-root runs of the whole series applied, the shell test markings
included, and none of the ten failures is about the budget: eight of them
pass as root, where it can't be exhausted, and the two that fail there too,
the addr2line inline unwinding one, with no branch stack sampling to ask
this machine for, and the BPF metadata collection one, whose output isn't
what the test expects, are not budget related either.
Reviewed-by: Ian Rogers <irogers@google.com>
Tested-by: Ian Rogers <irogers@google.com>
Assisted-by: LLM
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
|
A mutex held by a process that can die before unlocking it, like the
tests forked by 'perf test' that will take turns using the per user
budget set in kernel.perf_event_mlock_kb, has to be taken over by the
next locker instead of staying locked forever.
Robust mutexes, on top of the kernel's robust futexes, do that: when an
owner dies while holding it the kernel marks the futex word owner-died
and the next pthread_mutex_lock() returns EOWNERDEAD, then mutex_lock()
makes it consistent and takes it over; mutex_trylock() and cond_wait()
come back with EOWNERDEAD too, so they take it over the same way, with
mutex_trylock() giving the mutex back when it can't be taken over: it
is held all the same, and a failed trylock must not leak it.
Add mutex_init_pshared_robust(), returning false when robust mutexes
aren't available: from libcs without the API, gated by a feature check,
to musl and glibc refusing them at runtime, when get_robust_list(2) or
set_robust_list(2) aren't usable. glibc only sets a flag in
pthread_mutexattr_setrobust(), refusing the mutex itself in
pthread_mutex_init() with ENOTSUP instead, other errors from it still
being reported. Robust mutexes being unavailable isn't an error, just a
debug message for whoever then falls back.
Reviewed-by: Ian Rogers <irogers@google.com>
Tested-by: Ian Rogers <irogers@google.com>
Assisted-by: LLM
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
|
Shell tests run perf, that maps ring buffers, so they take a turn using
the per user budget in kernel.perf_event_mlock_kb by default; the ones
that don't map them, like the ones running just 'perf stat', say
" (no_mlock)" in their description line and thus keep running in parallel
with the ones taking turns.
The 'perf sched stats' tests are among them, they synthesize the samples
from /proc/schedstat without mapping a ring buffer, and the tests already
marked " (exclusive)" don't need it, exclusive implies every other
requisite and keeps them running alone.
Reviewed-by: Ian Rogers <irogers@google.com>
Tested-by: Ian Rogers <irogers@google.com>
Assisted-by: LLM
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
|
The C tests that run 'perf record' in the test process itself map ring
buffers and so need room in the per user budget set in
kernel.perf_event_mlock_kb: mark them with the new 'needs_mlock' suite
flag, read by the turnstile added later in the series, so that they
take turns using that budget while the tests that don't map them keep
running in parallel.
Reviewed-by: Ian Rogers <irogers@google.com>
Tested-by: Ian Rogers <irogers@google.com>
Assisted-by: LLM
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
|
Each perf instance maps one ring buffer per CPU, all charged to the same
per user budget set in kernel.perf_event_mlock_kb, so suites that map
them need to be told apart from the ones that don't, to later have them
take turns using that budget while the other tests keep running in
parallel.
Add the flag to 'struct test_suite' and a DEFINE_SUITE_NEEDS_MLOCK()
variant for the suites using the DEFINE_SUITE() form.
Shell tests run perf, that maps ring buffers, so they are taken to need
room in that budget by default; the requisites, a comma separated list in
the parens ending their description line, name what a test needs and take
a "no_" prefix to waive it, e.g.:
# perf stat tests (no_mlock)
"mlock" is room in that budget, so stating it only spells the default
out, "no_mlock" waives it, and "exclusive" is the catch-all that keeps a
test from running alongside any other, so it runs alone, in sequence, and
implies every other requisite, which is why it can't be waived either.
More requisites are to come, each stating what a test needs, till the
catch-all isn't needed anymore.
'perf test requisites' lists what each test needs, reusing the listing
routine and taking the same test name fragments and numbers as 'list'.
Reviewed-by: Ian Rogers <irogers@google.com>
Tested-by: Ian Rogers <irogers@google.com>
Assisted-by: LLM
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
|
Per skip the default output shows a self contained one liner:
unsupp 'test-record-branch-filter-any' exit 255, expected 1, no attrs recorded to verify
skipped [kernel newer than 6.12] 'test-record-group-sampling'
skipped [arch = !aarch64, machine = aarch64] 'test-record-graph-default'
The extra notes explaining the reason, with a copy pasteable command to
observe the failure, come in the very same stream when the verbosity is
bumped, at -vvv, nothing is written to a separate place for later
consultation, it is just the logging ladder:
detail: '/root/bin/perf record -o /dev/null --no-bpf-event -j any kill'
exited with 255, the expectations want the workload's 1 exit, so there
are no attrs recorded to verify; this is normally a capability problem,
run '/root/bin/perf record -o /dev/null --no-bpf-event -j any kill' to
see why
Note that 'perf test -v/-vv/-vvv attribute' appends a single -v to the
shell test entry (shell_test__run()), so to see the notes one runs the
python module directly, f.i.:
python3 tests/shell/lib/attr.py -vvv -d tests/shell/attr -p ./perf
The skip functions now return the reason fragment when they want to skip
and None when the test can go on.
The command suggested to observe the failure writes to /dev/null, so it
doesn't leave a perf.data in the directory it is run from.
Reviewed-by: Ian Rogers <irogers@google.com>
Tested-by: Ian Rogers <irogers@google.com>
Assisted-by: LLM
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
|
read_format's PERF_FORMAT_GROUP bit asks for the group members to be read
along with the leader, which aside from this bit is verified with the
fd/group_fd based group checking in Test.compare(), and with more than
one core PMU a group whose members are pinned to one of them, say
'default_core', leaves the clones for the other core PMUs without any
members:
$ perf stat -e '{cycles,default_core/legacy-hardware-config=3/}:S'
... the A53 leader keeps its cohort, both A73 cycles clones are alone,
read_format 20 instead of 28
so that bit isn't there: whether it is there is a consequence of how the
evlist got expanded to more than one core PMU, not of the groupness the
expectations say about, which is verified structurally, so take it out on
both sides.
That leaves the A73 leader clones, now with:
expected read_format=28|31, got 20
matching the base event expectations again.
With a single core PMU there is nothing to expand, so there is nothing to
explain away: count the core PMUs when the script starts, from what perf
makes of 'cycles', see parse_events_multi_pmu_add(), and take the bit out
only when there is more than one, leaving the machines with a single core
PMU verifying what the expectations say about it. That count is 2 on the
Amlogic A311D, where its A53 and A73 PMUs both answer for 'cycles', and 1
on a machine with a single core PMU. Where there is no binding to ask,
as when attr.py runs without setup_python.sh, the count isn't available
and the bit is taken out as well.
core_pmu_count() takes the count from the same probe core_pmu_available()
uses, so the binding is asked once, and only when a comparison needs the
answer, not at import time.
The sample id bits hide_sample_id() takes out when the expectations ask
for none are another consequence of having more than one core PMU, so the
same single core PMU gate covers them; equating the two id bits, needed
when the evlist has more than one event even with a single core PMU, keeps
applying.
Reviewed-by: Ian Rogers <irogers@google.com>
Tested-by: Ian Rogers <irogers@google.com>
Assisted-by: LLM
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
|
On a hybrid machine the default stat metrics are opened on each core PMU,
and the events of the other one have their own encodings: on an i7-14700K
cpu_atom (type 10) opens UOPS_RETIRED.ALL, config 194, which the
expectations, written for cpu_core (type 4), don't name:
expected type=4, got 10
expected config=209|391, got 194
The test already masks the core PMU type out of 'config' for the legacy
events, but raw events keep their type and encoding, so leave out the
events of the core PMUs no expectation names, like the dummy tracking
event. Core PMUs are found as perf finds them: 'cpu' or 'cpum_cf', or a
PMU with a 'cpus' file in sysfs. Nothing is left out unless an
expectation names a core PMU, so single core PMU machines and the tests
with only legacy expectations are not affected.
Reviewed-by: Ian Rogers <irogers@google.com>
Tested-by: Ian Rogers <irogers@google.com>
Assisted-by: LLM
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
|
With more than one core PMU the requested events can't cover all the
CPUs, each cluster has its own PMU, so perf opens the software dummy
event to carry the tracking terms (mmap, comm, task, mmap_data), leaving
the requested events without them:
expected mmap=1, got 0
expected comm=1, got 0
expected task=1, got 0
That dummy event is not part of what the expectations are about, so
leave it out of the comparison, unless the expectations ask for one,
like system-wide-dummy and test-record-dummy-C0 do.
And when perf used it to carry the tracking terms, those terms can't be
matched on the requested events, leave them out of the match as well.
The terms are left out only where the dropped dummy actually carried them,
from the sample_type it was opened with, a dummy that didn't is no reason
to stop verifying them.
Reviewed-by: Ian Rogers <irogers@google.com>
Tested-by: Ian Rogers <irogers@google.com>
Assisted-by: LLM
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
|
evlist__config() asks for a way to tell the samples apart,
PERF_SAMPLE_IDENTIFIER where available, PERF_SAMPLE_ID otherwise:
bool sample_id = opts->sample_id;
...
if (opts->full_auxtrace || opts->sample_identifier) {
...
use_sample_identifier = perf_can_sample_identifier();
sample_id = true;
} else if (evlist__nr_entries(evlist) > 1) {
...
use_sample_identifier = perf_can_sample_identifier();
sample_id = true;
}
so the id is asked for whenever the evlist has more than one event, and
also when asked to outright, with --sample-identifier or by an auxtrace
session, or by record__config() for a pipe run, through opts->sample_id,
none of which depends on the sample types: 'perf record
--sample-identifier -e cycles' and the arm SPE expectations in this very
directory ask for it with a single event.
Which one it asks for depends on the composition of the evlist: with
more than one core PMU a request for 'cycles' becomes one event per core
PMU, the extra dummy tracking events then make the sample types differ and
perf goes for IDENTIFIER, while the expectations were written on machines
with a single core PMU, where perf asks for ID:
expected sample_type=263, got 65799 # 263 | (1 << 16)
expected sample_type=343, got 65815 # (343 & ~(1 << 6)) | (1 << 16), group-sampling
Both bits mean the same thing here, how the samples get associated with the
event that produced them, so when the expectation asks for one of them, ask
for "an id of some sort" on both sides, and when the expectation doesn't
ask for any, take the bits out of what got recorded: whether they are there
and which one it is are consequences of what was asked for and of how the
request got expanded, none of that is what these expectations are about.
Since Test.compare() looks at both directions, expectations matching the
recorded events and recorded events matching the expectations, keep track
of which side is the one perf recorded to take the bits out of the right
side.
The masking is only for the comparison: the warnings keep showing the
values as they are, nothing to un-mask by hand to see what is being
complained about.
Reviewed-by: Ian Rogers <irogers@google.com>
Tested-by: Ian Rogers <irogers@google.com>
Assisted-by: LLM
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
|
What hide_core_pmu_type() does is take a set of bits out of each of the
'|'-separated alternatives in a value, wildcards included, keeping the
rest of the expression: extract that as mask_bits() and implement
hide_core_pmu_type() in terms of it, a prep for using the same thing to
ignore, when comparing expectations, the sample id bit perf ends up
asking for and the read_format group bit that a PMU count can remove.
No change in behaviour.
Reviewed-by: Ian Rogers <irogers@google.com>
Tested-by: Ian Rogers <irogers@google.com>
Assisted-by: LLM
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
|
evsel__open_cpu() opens the events one by one and, when an open fails
with EINVAL and evsel__detect_missing_features() has a feature to leave
out, goes back to fallback_missing_features to open them all again from
start_cpu_map_idx, without closing what the abandoned attempt opened:
the fd of every CPU or thread that was opened before the failing one is
overwritten in the FD() array, leaking it.
Close them first, the same way out_close does when returning an error,
leaving the entries at -1 for the retry.
Fixes: af954f76eea5 ("perf tools: Check fallback error and order")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/r/sashiko-outbox-173532@kernel.org
Reviewed-by: Ian Rogers <irogers@google.com>
Tested-by: Ian Rogers <irogers@google.com>
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
|
Events opened just to ask if they are supported, i.e. the ones in
is_event_supported() and is_libpfm_event_supported(), go through the
regular evsel__open() path and thus end up in the event files written to
$PERF_TEST_ATTR, with everything but type, config and disabled zeroed:
[event-0-38654705664-3]
fd=3
cpu=-1
pid=0
type=0
size=0
config=38654705664
sample_type=0
...
which 'perf test attr' then takes as one of the events that were asked
for, failing with:
expected cpu=0, got -1
expected size=176, got 0
expected sample_type=65927, got 0
expected freq=1, got 0
This started showing up when there is more than one core PMU, as
perf_pmus__supports_extended_type() probes one such event per core PMU,
but these records were always bogus: nothing asked for them.
Flag those evsels as support probes, keeping the name clear of the
kprobe/uprobe meaning probe already has in evsel, and leave them out of
the dump.
Reported-by: Namhyung Kim <namhyung@kernel.org>
Link: https://lore.kernel.org/linux-perf-users/asWQvXRdqp_RK85c@google.com/
Reviewed-by: Ian Rogers <irogers@google.com>
Tested-by: Ian Rogers <irogers@google.com>
Assisted-by: LLM
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
|
Since
commit 55bcf6ef314a ("perf: Extend PERF_TYPE_HARDWARE and PERF_TYPE_HW_CACHE")
in v5.13, and arm_pmu opted in with
commit 5c816728651a ("arm_pmu: Add PERF_PMU_CAP_EXTENDED_HW_TYPE capability")
in v6.6, the kernel can
be told which core PMU a legacy type event is meant for, with its type in
the top 32 bits of 'config', see
perf_pmus__supports_extended_type(), which __parse_events_add_numeric()
does for HARDWARE and HW_CACHE events, but only when there is more than
one core PMU, i.e. on heterogeneous machines, where asking for one event
ends up being one event per core PMU:
$ perf stat -e cycles -a -- sleep 1
20,520,998 armv8_cortex_a53/cycles/
13,029,350 armv8_cortex_a73/cycles/
and what lands in PERF_TEST_ATTR is the extended encoding:
type=0
config=38654705664 # core PMU type 9, PERF_COUNT_HW_CPU_CYCLES
so the expectations written for the single core PMU case fail with:
expected config=0|1, got 38654705664
expected config=0, got 38654705664 # 'perf stat -d' L1-dcache events
which is what now happens on an Amlogic A311D (2 Cortex-A53 + 4
Cortex-A73), a machine that just got the CPU PMU nodes it was missing.
Take those bits out when comparing the 'config' of legacy type events,
keeping what these expectations mean on machines with a single core PMU:
which of the PMUs is counting is not what we're asking here.
Reviewed-by: Ian Rogers <irogers@google.com>
Tested-by: Ian Rogers <irogers@google.com>
Assisted-by: LLM
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
|
Opening a group with perf record on a machine with perf_event_paranoid >
1 and no CAP_PERFMON fails the first perf_event_open() with EACCES, after
which evsel__open_cpu() clears evsel->supported; evsel__fallback() then
adds exclude_kernel and record__open() retries, and the retry succeeds
with supported left false. get_group_fd() treats unsupported events as
ungroupable, so the retry opens the group members without their leader:
sys_perf_event_open: pid 12345 cpu 0 group_fd -1
FAILED '.../test-record-group-sampling1' - group failure
which fails the group subtests of "perf test 82", the Perf attribute
expectations test, when it is run as a regular user, while it passes as
root or with CAP_PERFMON, where the first open doesn't fail.
commit 2cc7aa995ce9 ("perf stat: Refactor retry/skip/fatal error handling")
dropped the pos->supported = true that record__open() did after a
successful open and moved the resets into the stat code only, while
saying "When an event is tried the supported is set to true again". Do
that in evsel__open_cpu(), which every open entry point funnels through,
so that a retry describes its own try instead of the previous failure.
Fixes: 2cc7aa995ce9ecd8 ("perf stat: Refactor retry/skip/fatal error handling")
Reviewed-by: Ian Rogers <irogers@google.com>
Tested-by: Ian Rogers <irogers@google.com>
Cc: Ian Rogers <irogers@google.com>
Assisted-by: LLM
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
|
When matching the recorded events back against the expectations,
attr.py requires every event opened in a group to match an expectation
that declares the same group. The perf stat default metrics open the
events of each metric in groups, but the test expectations only verify
the event attributes, so test-stat-default fails with:
FAILED '.../test-stat-default' - group failure
Only enforce the group of a recorded event when the expectation it
matches declares one. Expectations that ask for a group are still
verified in both directions.
Fixes: c7adeb0974f18da4 ("perf jevents: Add set of common metrics based on default ones")
Fixes: 2dfc0cab3da4a205 ("perf stat: Add detail -d,-dd,-ddd metrics")
Reviewed-by: Ian Rogers <irogers@google.com>
Tested-by: Ian Rogers <irogers@google.com>
Assisted-by: LLM
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
|
Since commit c7adeb0974f1 ("perf jevents: Add set of common metrics based
on default ones") and commit 2dfc0cab3da4 ("perf stat: Add detail -d,-dd,-ddd
metrics") the perf stat default metrics open their events in groups, so
group leaders and members have read_format=15 and members are enabled
without enable_on_exec, while standalone events keep read_format=3 and
are disabled until exec.
Also, since commit b1c5efbfd92e ("perf parse-events: Remove hard coded
legacy hardware and cache parsing") bare hardware events resolve to the
core PMU sysfs/JSON events (type 4), so add the raw encodings the Intel
and AMD core PMUs use for instructions, branch-misses, cpu-cycles and
stalled-cycles-frontend/backend to test-stat-default and
test-stat-detailed-1/2/3.
Add base-stat-group, that accepts both the standalone and the group
variants of read_format, disabled and enable_on_exec, and point the four
default/detailed expectations at it. test-stat-basic, test-stat-C0 and
test-stat-no-inherit keep base-stat, whose events aren't opened in a
group: for those, a change that groups or enables them differently is
still something to catch. test-stat-group1 does open its events in a
group, but pins read_format, disabled and enable_on_exec itself, the very
terms base-stat-group loosens, so it doesn't need it either.
Fixes: b1c5efbfd92eb84d ("perf parse-events: Remove hard coded legacy hardware and cache parsing")
Fixes: c7adeb0974f18da4 ("perf jevents: Add set of common metrics based on default ones")
Fixes: 2dfc0cab3da4a205 ("perf stat: Add detail -d,-dd,-ddd metrics")
Reviewed-by: Ian Rogers <irogers@google.com>
Tested-by: Ian Rogers <irogers@google.com>
Assisted-by: LLM
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
|
Since commit b1c5efbfd92e ("perf parse-events: Remove hard coded legacy
hardware and cache parsing"), event names are resolved with sysfs/JSON
priority over the legacy encodings, so bare cache-misses and
instructions now become the core PMU sysfs/JSON events (on x86 type 4,
configs 0x412e and 0xc0) rather than the legacy
PERF_TYPE_HARDWARE/config=3 and config=1 events the tests expect, e.g.:
expected config=3, got 0
expected disabled=0, got 1
expected mmap=0, got 1
expected comm=0, got 1
expected freq=0, got 1
expected enable_on_exec=0, got 1
expected task=0, got 1
FAILED '.../test-record-group-sampling1' - match failure
The shown diff is against the cycles group leader, as no result event
matches the expected cache-misses member anymore.
Request the legacy encodings explicitly with the legacy-hardware-config
term, added in commit 0012e0fa221bf9cc ("perf jevents: Add
legacy-hardware and legacy-cache json"), keeping the original
attribute expectations unchanged, in:
test-record-group1
test-record-group2
test-record-group3
test-record-group-sampling
test-record-group-sampling1
test-record-group-sampling2
test-stat-group1
This went unnoticed until tests/attr.sh stopped ignoring attr.py's
return value.
Fixes: b1c5efbfd92eb84d ("perf parse-events: Remove hard coded legacy hardware and cache parsing")
Reviewed-by: Ian Rogers <irogers@google.com>
Tested-by: Ian Rogers <irogers@google.com>
Assisted-by: LLM
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
|
On machines without a usable core PMU, like an aarch64 box with no DT
node for the ARM PMU, the expectations that pin the legacy hardware
encoding can't be checked: without a core PMU at all 'cycles' doesn't
even resolve, and with one that can't be opened 'perf record' takes the
software fallback and records attributes they can never match:
expected type=0, got 1
expected config=0, got 1
FAILED '.../attr/test-record-group-sampling1' - match failure
And since attr.py stops at the first failure, every expectation that
would come after that one ends up not being run at all.
Add a 'requires' limitation, modelled after the existing 'arch', 'auxv'
and 'kernel_since/until' ones, with 'core-pmu' as its first value, that
is checked by asking perf itself to open 'cycles' via its python
binding: a parse failure or an ENOENT means there is no PMU that can
count it, hence nothing to check and the test gets skipped, while any
other error means we can't tell, so the test keeps running as it does
today, where there is no binding to ask either.
When there is no core PMU, asking the binding fails and prints a parse
error, once for every test that asks, so the answer is kept: it is asked
once per run. A value other than 'core-pmu' is warned about, not
silently ignored, so a typo can't turn the skip into a no-op.
An old distro python package may have a 'perf' module without
parse_events(), i.e. there is nothing to ask with, so that
AttributeError gets the same treatment as the ImportError: let the
expectations speak.
The expectations that have a strict 'type=0', plus the group tests,
where the fallback drops a member and leaves nothing to compare the
group leader attributes with, now state that they require a core PMU.
They are marked here, before the commit that has the group tests ask for
the legacy encodings, so the requisite comes with that dependency.
Reviewed-by: Ian Rogers <irogers@google.com>
Tested-by: Ian Rogers <irogers@google.com>
Assisted-by: LLM
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
|
pyrf__parse_events() prints the entries parse_events_error__print()
receives with the details of a failed parse, but returns without freeing
them, leaking whatever parse_events_error__handle() allocated, so call
parse_events_error__exit() on both paths, as the other parse_events()
callers do.
The perf test attr core PMU probe takes this failure path on machines
without a core PMU, where the leak then happens on every test run.
Fixes: f081defccd93 ("perf python: Add parse_events function")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/r/sashiko-outbox-173525@kernel.org
Reviewed-by: Ian Rogers <irogers@google.com>
Tested-by: Ian Rogers <irogers@google.com>
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
|
Since commit bdd051e24914 ("perf record: Split --data-mmap option"),
record_opts__parse_callchain() sets record_data_mmap instead of
record->sample_address for the DWARF unwind mode, so -d/--data and its
implied PERF_SAMPLE_DATA_SRC are not enabled implicitly anymore.
As a result, --call-graph dwarf no longer sets PERF_SAMPLE_ADDR and
PERF_SAMPLE_DATA_SRC, making the test fail:
expected sample_type=45359, got 12583
where 45359 (0xb12f) is:
IP|TID|TIME|ADDR|CALLCHAIN|PERIOD|REGS_USER|STACK_USER|DATA_SRC
and 12583 (0x3127) is:
IP|TID|TIME|CALLCHAIN|PERIOD|REGS_USER|STACK_USER
i.e. the values differ exactly by PERF_SAMPLE_ADDR (0x8) and
PERF_SAMPLE_DATA_SRC (0x8000). The mmap_data=1 expectation is still
correct as DWARF now enables record_data_mmap.
This went unnoticed until tests/attr.sh stopped ignoring attr.py's
return value.
Fixes: bdd051e249141c79 ("perf record: Split --data-mmap option")
Reviewed-by: Ian Rogers <irogers@google.com>
Tested-by: Ian Rogers <irogers@google.com>
Assisted-by: LLM
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
|
Send bulk TCP through GRE tunnels carried over UDP by FOU and by GUE,
each over IPv4 and IPv6, with GRO on at the receiving veth and
segmentation off at the sender so the receiver gets wire-sized packets
to merge. Check that the receiver counts no UDP errors.
Verified under virtme-ng: without the previous patch, all four cases
fail, with the encapsulation socket counting every merged packet in
UdpInErrors or Udp6InErrors. With it, they pass in a few seconds.
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
Link: https://patch.msgid.link/20261011-bradfitz-gre-fou-gro-b4-v1-2-df713aad1531@tailscale.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Now that bareudp allows BIG TCP too, run the same checks over bareudp as
for vxlan and geneve.
bareudp only works in external mode, so attach the tunnel metadata to
all packets sent through the device with a tc tunnel_key action on
egress. The device uses ethertype ipv4 with multiproto, so that both
IPv4 and IPv6 traffic can go through it. Its MTU does not account for
the encapsulation, so lower it to leave room for the IPv6 and UDP
headers, otherwise the encapsulated packets would be fragmented.
Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20261011102023.1603595-3-yanhaishuang@cmss.chinamobile.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The bareudp tests only send pings, which are not GSO packets, so the
segmentation path of bareudp is not covered.
Copy a file over TCP from NS0 to NS3 with socat after the IPv4 and IPv6
ping tests, with UDP tunnel segmentation offload disabled on the
underlay veths, so that the GSO packets encapsulated by bareudp are
segmented in software. Raise the MTU of the underlay veths, so that full
sized packets fit with the encapsulation, as there is no path MTU
discovery through bareudp.
The MPLS overlay gets no stream test: bareudp does not set
mpls_features, so MPLS GSO packets are segmented by mpls_gso before
they reach bareudp, and are dropped if mpls_gso is not available.
The ping and stream tests share the result reporting, so move it into
report_result(). Without socat or ethtool, the stream tests are skipped.
Without commit c57b2e60d4bf ("bareudp: set the inner protocol to the
protocol of the packet"), the IPv4 and IPv6 streams over UDPv6, and the
IPv6 stream over UDPv4 in multiproto mode, time out.
Suggested-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20261011104300.1606351-1-yanhaishuang@cmss.chinamobile.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Manual merge fixup in ns_common_types.h:ns_common to work around a conflict
with the nsfs RCU grace period fix.
* lsm/dev:
lsm: remove redundant NULL check in security_init()
selftests/landlock: Check full ioctl commands in audit records
lsm: Preserve full ioctl commands in audit records
doc: fix LSM ordering description for /sys/kernel/security/lsm
doc: describe CONFIG_LSM and lsm= as the selection mechanism
selftests/bpf: verify mount idmaps reach inode hooks
lsm: expose mount idmaps to inode hooks
rust: lsm: replace `core::mem::zeroed` with `pin_init::zeroed`
cred: prevent slab cache merging for cred_jar
lsm: don't call security_backing_file_free() multiple times
lsm: delete duplicate assignment in lsm_prepare()
lsm: update the BUILD_BUG_ON() in audit_log_lsm_data()
lsm: add LSM_AUDIT_DATA_NS for namespace audit records
lsm: add LSM blob and hooks for namespaces
ns: Free anonymous mount namespaces via ns_common_free()
cred: clarify that task_struct::cred is only for the current task
|
|
Add a test to test_pids.c that checks a fork rejected by pids.max
increments pids.events and generates an IN_MODIFY inotify event on that
file. The test cgroup is the one over the limit, so the notification is
expected both on a default mount and with pids_localevents.
This covers the fix in commit 1765a153d985 ("cgroup/pids: Restore
pids.events notifications in local mode"), where a rejected fork changed
pids.events without waking its pollers when pids_localevents was enabled.
Tested on x86_64 under QEMU without KVM, on kernels built from the
cgroup for-7.4 branch (eb69e955de7b) and from the same tree with that
fix reverted. With the fix, the new test passes on a default cgroup2
mount and on a pids_localevents mount. With the fix reverted, it passes
on a default mount and fails on a pids_localevents mount. No kernel
warnings were logged.
Link: https://lore.kernel.org/r/20261013064812.875787-1-sahaj123.sc@gmail.com
Signed-off-by: Sahaj Chaudhari <sahaj123.sc@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
|
|
Add two functions to the BPF target program of the int128_tgt_prog test.
callee_split() takes a struct holding an __int128 after five u64s, so
on x86-64 it is passed split between r9 and the stack. fentry and fexit
programs check that the trampoline takes it from there and hands it back
there.
callee_unreliable() takes six u64-sized arguments, the first a plain
pointer, which makes its BTF unreliable while the sixth is still passed
on the stack. The new tgt_prog_unreliable subtest checks that an fentry
program cannot be attached to it.
Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://patch.msgid.link/20261016183125.1136468-1-yonghong.song@linux.dev
|
|
Attach fentry and fexit programs to two functions of another BPF
program, each taking a struct holding an __int128 at an odd argument
slot:
- callee_odd(): the struct after a single u64, where arm64 would
leave a register empty.
- callee_stack(): the struct after seven u64s, where x86-64 would
leave a stack slot empty and arm64 a register.
BPF code calls them with the arguments packed in the BPF convention, so
that is where the trampoline has to take them from. The fentry programs
take the arguments with BPF_PROG2(), which reads each from its slots in
ctx[], and the fexit programs check the return value, weighted by slot,
which is only right if the function got its arguments back where its
caller put them. Both take a struct by value, which GCC passes by
reference instead, so they are only built with clang, and callee_stack()
only with a clang that supports stack arguments.
Unlike a kernel function taking an __int128, which s390x passes by
reference, nothing in the test depends on how the arch passes a 16-byte
value, so it runs on s390x as well as on x86_64 and arm64. BPF_PROG2()
reads the struct from its two context slots the way BPF code passed it,
so its halves come out right on big-endian s390x too. The s390 JIT does
not take stack arguments, so callee_stack() is only built for x86 and
arm64, and only callee_odd() is traced on s390x.
Describing the functions to the trampoline by the types of their
arguments, rather than as one u64 per slot, the x86-64 trampoline fails
the test with:
test_int128_tgt_prog:FAIL:stack:h.lo unexpected stack:h.lo: actual 9 != expected 8
test_int128_tgt_prog:FAIL:stack:h.hi unexpected stack:h.hi: actual 10 != expected 9
Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://patch.msgid.link/20261016183115.1135762-1-yonghong.song@linux.dev
|
|
Add two bpf_testmod functions whose 16-byte aligned argument, a struct
holding an __int128, is passed on the stack after a hole:
- bpf_testmod_test_int128_stack(): seven u64s before the struct, so it
leaves a register empty on arm64 and a stack slot empty on x86-64.
- bpf_testmod_test_int128_backfill(): a 16-byte struct of two longs
moves to the x86-64 stack and gives R9 back to the next argument; the
struct then leaves a stack slot empty on both x86-64 and arm64.
The __int128 is wrapped in a struct because btf_ctx_access() refuses a
program reading an integer argument wider than eight bytes, while it
lets the program read each slot of a struct argument.
The fentry programs read each argument slot from ctx[] and check that
the trampoline packs them in the BPF convention, and the fexit programs
check the return value, weighted by argument slot, which is only right
if the original function got its arguments back where its convention
wants them.
Without the preceding x86 fix the test fails with:
test_int128_args:FAIL:s:h.lo unexpected s:h.lo: actual 2 != expected 8
...
test_int128_args:FAIL:s ret unexpected s ret: actual 285 != expected 385
Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://patch.msgid.link/20261016183110.1135597-1-yonghong.song@linux.dev
|
|
This follows up the series "bpf: Support by-value struct and __int128
arguments" [1]. The __int128 kfunc tests it added pass the __int128 at
an even argument slot, after two u64s, or past the argument registers,
where it lands on an even arm64 stack slot. So neither the AAPCS64 rule
that rounds the register number up to an even one for an argument
aligned to 16 bytes, nor the same rule for a stack slot, is exercised.
Each leaves a hole the arm64 JIT has to open by moving the __int128 and
every argument after it up a slot.
Add three kfuncs. Like the earlier ones, each weighs its arguments by
argument slot, so that two eightbytes landing in each other's slots are
caught as well as one landing in a hole:
- bpf_kfunc_call_test_i128_arg_odd(): the __int128 at an odd register
slot.
- bpf_kfunc_call_test_i128_arg_odd_many(): the same, with arguments
after it that arm64 shifts onto its stack, and a second __int128 at
an odd arm64 stack slot.
- bpf_kfunc_call_test_i128_arg_stack_hole(): a struct holding an
__int128 at an odd stack slot on both x86-64 and arm64, after x86-64
gives R9 back to an argument following a 16-byte struct.
x86-64 has no register alignment rule and places the first two like the
BPF convention, so they check that its JIT leaves them where they are.
The last two need more than the five BPF argument registers and are only
built with a compiler that supports stack arguments.
On arm64 the first two kfuncs get BTF only with the pahole patch
"dwarf_loader: Skip the argument register the arm64 ABI leaves as a hole"
[2], in pahole master after v1.32. An older pahole finds the argument
after the __int128 in an unexpected register, x4 rather than x3, and
leaves the function out of BTF, so the tests fail to load there.
Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20260912195156.980886-1-yonghong.song@linux.dev/ [1]
Link: https://lore.kernel.org/dwarves/20260917164043.1577508-1-yonghong.song@linux.dev/ [2]
Link: https://patch.msgid.link/20261016183054.1134162-1-yonghong.song@linux.dev
|
|
Test the previous patch with a target program made of two call chains:
run() -> call_stack() -> callee_stack(a, b, c, d, e, f, g, h)
run() -> subprog_tail() -> bpf_tail_call()
callee_stack() takes eight u64 arguments, so g and h are passed on the
stack. Because run() can reach a tail call, a trampoline on any function
of the program keeps the tail call counter pointer. callee_stack()
itself does not lead to the tail call, which is why the verifier still
lets it take stack arguments.
Attach fentry and fexit programs to callee_stack(). The fentry program
checks that it sees g and h, and the test checks the value that
callee_stack() returns when the fexit trampoline calls it.
Without the previous patch, the function takes the counter pointer for
its first stack argument:
test_stack_arg_tailcall:FAIL:stack ret unexpected stack ret: actual -359789677662885869 != expected 204
test_stack_arg_tailcall:FAIL:stack fexit ret unexpected stack fexit ret: actual -359789677662885869 != expected 204
Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://patch.msgid.link/20261016183049.1133231-1-yonghong.song@linux.dev
|
|
The arena and/or/xor tests never exercised the fetching form of the
instruction. Commit 2897b1e2a2f4 ("selftests/bpf: Fix arena_atomics
failure due to llvm change") deliberately switched them to
__c11_atomic_fetch_*() with memory_order_relaxed, which clang lowers to a
non-fetching locked instruction when the result is unused, because
x86-64 could not JIT the fetching one against an arena.
It can now, so check the returned old value with __sync_fetch_and_*().
Keep a __c11_atomic_fetch_*() of each width per operation with the result
discarded: that spelling is what selects the non-fetching insn, which
would otherwise lose its only coverage, on every architecture rather than
just x86. Compiling the prog with clang 22 before and after confirms the
split: 6 non-fetching and no fetching arena and/or/xor before, 6 and 22
after.
The new globals go in their operation's block, and the or block keeps its
u32s first, so .addr_space.1 stays free of the padding holes that clang
before 18 cannot fill when it is built without address space casts.
Add a fetch_r0 test for the two register assignments the x86 JIT has to
special-case, where the operand and where the arena pointer is R0 and
BPF_REG_AX is substituted for it. Clang picks its own registers and will
not reliably produce either, so spell the instructions out. The values
have bits set above 32 so that a truncating move on that path shows up.
Add both forms to the uaf test as well, since the substitution only
reaches the exception table when such an access faults, and check that
the fault cleared the fetched register and left the address alone. They
fault on the page after the freed one: the freed page is the first of the
arena, whose 32-bit address is 0, which would make the address check
empty. The address is read back afterwards, which gives 0 if the JIT's
exception table entry recovered the fault, but not if the arena had
mapped its zeroed scratch page and let the access succeed. The powerpc64
JIT does not clear the register of a faulting atomic yet, so those checks
are skipped there.
Both spell addr_space_cast textually, which needs LLVM 19, so uaf gains
the __BPF_FEATURE_ADDR_SPACE_CAST guard that every other textual use in
the file already has. It was plain C before and built on older clang.
Drop x86 from the exclusion list of the uaf test, which covers the fault
path. Its page is gone before the first access, so it faults on the load;
the CMPXCHG entry is only reached when the page goes away between the two
accesses, which a test cannot arrange.
Finally cover fetching AND/OR/XOR through a number in
verifier_arena_scalar, on x86-64 and arm64. Both widths are run with the
operand in a register and in R0, which is where the x86-64 JIT keeps the
operand on the stack because BPF_REG_AX holds the address. The 32-bit
operands have bits set above 32 so that a missing zero-extension shows.
The page is also freed first, after storing a nonzero value in it so that
an access which did not fault would show, and the test checks that the
fetched register comes back 0 and R0 is left alone, and that reading the
address back gives 0. R0 is compared with a value derived from the page
address: the verifier would decide a comparison with a constant at load
time and drop it.
Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Tejun Heo <tj@kernel.org>
Link: https://patch.msgid.link/20261016171319.1623447-3-puranjay@kernel.org
|
|
Close gaps in the JIT instruction tests found by earlier Sashiko review,
by comparing the programs with what reaches the JIT, and by a sweep
through RFC9669 to construct tests for corner cases. Non-exhaustive list:
- The staggered jumps loaded their operands once, so the verifier decided
the later guards of ja and gotol and the later jumps of jeq_k and
jlt32_k, and a landing short of the target passed with r0 at zero.
Reload the operands per region and let r0 carry the region number
from the jump to its target.
- The matching 32-bit cmpxchg compared an r0 the mismatching one had zero
extended. Reload r0 with the full value first and check that the source
register keeps its upper half, as test_bpf did.
- The 32-bit atomics wrote and read back only their word, so a JIT touching
all 64 bits passed when the other half was zero. Fill and read back the
whole slot.
- The sub-word loads of the zero offset, offsets and probe_mem tests landed
in a register holding nothing in particular. Set it to all ones first.
- Let probe_mem load every size, sign extending too, and run ld_imm64 into
every register, not only r1.
- Drop the load-acquire probe: a JIT without the instruction fails like for
any other one instead of skipping.
# LDLIBS=-static PKG_CONFIG='pkg-config --static' ./vmtest.sh -- ./test_progs -t jit_insns
[...]
#191/1 jit_insns/arena access with zero offset:OK
#191/2 jit_insns/cast to a user address:OK
#191/3 jit_insns/alu_imm:OK
#191/4 jit_insns/alu_reg:OK
#191/5 jit_insns/alu_imm_regs:OK
#191/6 jit_insns/div_const:OK
#191/7 jit_insns/alu_reg_pairs:OK
#191/8 jit_insns/alu_edges:OK
#191/9 jit_insns/shifts:OK
#191/10 jit_insns/shift_counts:OK
#191/11 jit_insns/atomics:OK
#191/12 jit_insns/atomic_reg_pairs:OK
#191/13 jit_insns/xadd_chain:OK
#191/14 jit_insns/ld_imm64:OK
#191/15 jit_insns/jmp_imm:OK
#191/16 jit_insns/jmp_reg:OK
#191/17 jit_insns/jmp_reg_pairs:OK
#191/18 jit_insns/jmp_edges:OK
#191/19 jit_insns/staggered_jumps:OK
#191/20 jit_insns/max_jmp:OK
#191/21 jit_insns/convergence:OK
#191/22 jit_insns/calls:OK
#191/23 jit_insns/helper_calls:OK
#191/24 jit_insns/ldst_zero_off:OK
#191/25 jit_insns/ldst_offsets:OK
#191/26 jit_insns/acq_rel:OK
#191/27 jit_insns/movsx:OK
#191/28 jit_insns/jset_imm:OK
#191/29 jit_insns/cmp_imm:OK
#191/30 jit_insns/alu_consts:OK
#191/31 jit_insns/bswap:OK
#191/32 jit_insns/probe_mem:OK
#191 jit_insns:OK
#192/1 jit_insns_blinded/alu_imm:OK
#192/2 jit_insns_blinded/alu_imm_regs:OK
#192/3 jit_insns_blinded/alu_edges:OK
#192/4 jit_insns_blinded/div_const:OK
#192/5 jit_insns_blinded/shifts:OK
#192/6 jit_insns_blinded/xadd_chain:OK
#192/7 jit_insns_blinded/ld_imm64:OK
#192/8 jit_insns_blinded/jmp_imm:OK
#192/9 jit_insns_blinded/jmp_edges:OK
#192/10 jit_insns_blinded/ldst_zero_off:OK
#192/11 jit_insns_blinded/ldst_offsets:OK
#192/12 jit_insns_blinded/jset_imm:OK
#192/13 jit_insns_blinded/cmp_imm:OK
#192/14 jit_insns_blinded/alu_consts:OK
#192 jit_insns_blinded:OK
Summary: 2/46 PASSED, 0 SKIPPED, 0/0 FAILED
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://patch.msgid.link/20261016101822.632891-3-daniel@iogearbox.net
|
|
The bpf_jit_convergence je <-> jmp test reproduces the cycle fixed by
commit c8831bdbfbab ("bpf, x64: Fix a jit convergence issue") with 125
bytes of x86-64 code between the je to l0 and l0 when the last goto l9 is
two bytes and 128 when it is five, so that the je fits into an imm8 only
while the jmp does not and the two flip each other's size from pass to
pass.
The recent JIT changes shortened that code by five bytes: the three loads
and stores with a zero offset lost their displacement byte with commit
44df4d88aa63 ("bpf, x86: Omit the displacement byte for zero offsets"),
and r2 += 0x1 became an inc and r3 &= 0x1 an and without REX.W with commit
d59f47e031ae ("bpf, x86: Use shorter and faster forms for some ALU
immediates"). At 120 and 123 bytes the je fits either way, nothing flips,
and the test passes without exercising the fix.
Add a five byte mov to the region to get the distance back. The je is
forced into its long form again as the fix intends:
# ./vmtest.sh -- ./test_progs -v -t verifier_jit_convergence
[...]
96: 0f 84 7d 00 00 00 je L14
117: eb 83 jmp L6
119: bf 03 00 00 00 L14: movl $0x3, %edi
[...]
#668/1 verifier_jit_convergence/bpf_jit_convergence je <-> jmp:OK
#668 verifier_jit_convergence:OK
Summary: 1/1 PASSED, 0 SKIPPED, 0/0 FAILED
Reported-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://patch.msgid.link/20261016101822.632891-2-daniel@iogearbox.net
|
|
Extend test_ksock_wq() added in 'c93cbdb13f99 ("selftests/bpf: Add ksock
test for async callback guard")' to test that the bpf_ksock_connect()
and bpf_ksock_send() kfuncs are now allowed and work when called from
workqueues.
Signed-off-by: Mahe Tardy <mahe.tardy@gmail.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Tested-by: Alan Maguire (Oracle) <almagui@kernel.org>
Link: https://patch.msgid.link/20261016133318.33999-2-mahe.tardy@gmail.com
|
|
configfs_rmdir() drops the last reference to an item while its dentry is
still hashed, so a symlink(2) resolving that target takes a reference on
freed memory. syzbot reported it [1].
Race mkdir/rmdir of a target against symlink/unlink of a link to it,
watching /sys/kernel/warn_count.
Fails until the fix [2] lands.
Link: https://syzkaller.appspot.com/bug?extid=6b16e3d085833cbf3e25 [1]
Link: https://lore.kernel.org/all/20260730093435.195441-1-vasilisalmpanis@gmail.com/ [2]
Link: https://patch.msgid.link/20260826-config_selftest-v1-4-e364b07e91ac@debian.org
Signed-off-by: Breno Leitao <leitao@debian.org>
|
|
samples/configfs had nothing to link from, so symlink(2) went untested
beyond the EPERM a subsystem without ->allow_link() returns.
Cover creating and removing a link, the relative body configfs stores, the
count ->allow_link() and ->drop_link() keep, the busy errors both ends
return, and what get_target() rejects.
Link: https://patch.msgid.link/20260826-config_selftest-v1-3-e364b07e91ac@debian.org
Signed-off-by: Breno Leitao <leitao@debian.org>
|
|
configfs has no selftest coverage. Its userspace ABI is entirely
mkdir/rmdir/read/write on attribute files, and the error each of those
returns is part of the contract.
Add tests driving the subsystems samples/configfs registers, each in its
own mount namespace on a private configfs mount.
Link: https://patch.msgid.link/20260826-config_selftest-v1-1-e364b07e91ac@debian.org
Signed-off-by: Breno Leitao <leitao@debian.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux
Pull gpio fixes from Bartosz Golaszewski:
- gracefully handle unsupported fwnode-only, no-device GPIO lookup for
shared pins
- mark the GPIO controller as sleeping in gpio-nct6694
- fix a GPIO device reference leak in kunit tests
- fix memory leak in error path in gpiod_set_array_value_complex()
- fix races in GPIO controller and its associated irqchip setup in
gpio-mxc
- use atomic bitops where races can occur in gpio-mxc
- fix build failure in gpio tools
* tag 'gpio-fixes-for-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
gpio: mxc: fix race between gpiochip registration and IRQ domain setup
gpio: mxc: fix wakeup_pads bit operations
gpio: mxc: fix both_edges bit operations
gpio: mxc: fix race between chained IRQ handler install and probe completion
gpiolib: fix memory leak in gpiod_set_array_value_complex() on error paths
gpio: kunit: fix GPIO device reference leak with __free()
gpio: shared: gracefully handle no-device lookup of shared GPIOs
gpio: shared: fix use-after-free bug when adding shared proxies
tools: gpio: fix building from the top level with O=
gpio: nct6694: Mark the GPIO controller as sleeping
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs
Pull vfs fixes from Christian Brauner:
- Fix a range of use-after-frees during rcu pathwalk caused by non-rcu
frees.
Whatever ->permission(), ->d_revalidate(), ->get_link(), ->d_hash()
and ->d_compare() read in rcu mode has to be freed after a grace
period. umount(2) hides most of it because namespace_unlock() waits
for one, but a chdir() out of a lazily unmounted directory or the
close() of the last file on it drops the last reference without.
* ext4_get_link() reads the sbi and the extent status counters for a
symlink stored in a data block. Both are freed after a grace
period now.
* The unicode map of casefolded ext4, f2fs and tmpfs was freed under
generic_ci_d_hash() and generic_ci_d_compare().
* ntfs3 with nocase freed its sbi and mount options under its dentry
hash and compare. A remount freed the old options right away too.
* eventfs freed an eventfs_inode after an SRCU grace period only
while tracefs_d_revalidate() reads it under rcu_read_lock().
* afs and 9p are only saved by the grace period their private bdi
gets in bdi_unregister(). They stop depending on it.
* create_ipc_ns() leaked the mqueue mount and its superblock on a
late failure. A long-term mount needs kern_unmount().
- Don't let idle threads pin the initramfs.
The idle threads of the secondary cpus are forked from PID 1 with a
private copy of its fs_struct, aren't on the task list so
pivot_root() never moves them and never exit. So the initramfs stayed
pinned forever on every machine with more than one cpu, 70 to 150 MB
in the reports. They share init_fs now like init_task does.
- A mount that copy_tree() leaves out can't take over a lock.
copy_tree() drops mounts of mount namespace files from the copies it
makes for unshare(CLONE_NEWNS) and propagation without looking at
MNT_LOCKED. So root in a user namespace could bind a child's
/proc/<pid>/ns/mnt beneath a locked cover, let it take the lock over,
unshare(CLONE_NEWNS) and read the file. copy_tree() refuses with
EPERM now and the move beneath a locked mount is refused up front.
- Revert "namei: don't reveal overmounted entries in refwalk" from the
rc7 fixes. The bug class is bigger than that patch.
- namei: lookup_fast_for_open() checked ->d_inode while
traverse_mounts() checks the type in d_flags, which is set second, so
a refwalk racing the instantiation could fail an O_CREAT open with
ENOENT. Use d_is_negative() in both places.
- Drop the smp_mb()s in mntput_no_expire_slowpath() and do_umount()
that mnt_get_count()'s own barrier made redundant.
- fsnotify: a mark added while fsnotify_destroy_marks() walks the
connector could be missed and the connector detached, so an fdinfo
read called igrab(NULL). New marks are refused during teardown.
- pipe: a failed second fasync enable on an O_RDWR FIFO removed the
existing reader entry and cleared FASYNC while the writer entry
stayed, a use-after-free in send_sigio() later.
- watch_queue: post_one_notification() could see nr_notes before the
note pool behind it and dereference a NULL array. An unprivileged
user can trigger that with a key watch. Publish nr_notes last.
- pid_namespace: zap_pid_ns_processes() waits without bound for a
tracer outside the namespace to reap its zombies and neither wait was
freezable, so every suspend attempt failed.
- exit: is_child_subreaper and has_child_subreaper shared a word with
other bitfields written without a common lock, so racing prctl()s
lost a bit. They are separate bools now.
- autofs: a notification write that failed on a pipe the daemon had
already replaced put the superblock into catatonic mode again and
closed the replacement. Only do that for the current pipe.
- ovl: reject a lowerdir ending with an unescaped backslash with EINVAL
instead of a confusing ENOENT later.
- ocfs2/dlm: take dlm_reco_state_lock when the debugfs state file walks
the recovery participant list.
- samples/pidfd: fix the userprogs typo that kept pidfd-metadata from
being built.
* tag 'vfs-7.3-rc8.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: (24 commits)
Revert "namei: don't reveal overmounted entries in refwalk"
selftests/filesystems: test that a mntns file can't take over a lock
fs: let idle threads share init_fs
namespace: a mount that copy_tree() leaves out can't take over a lock
namei: test for a negative dentry the way traverse_mounts() does
fs: pass flags to copy_fs()
ovl: reject lowerdir ending with unescaped backslash
fsnotify: prevent mark additions during connector teardown
pid_namespace: make zap_pid_ns_processes() freezable
fs: drop the smp_mb()s that mnt_get_count() made redundant
autofs: ignore notification errors from a replaced pipe
ntfs3: free replaced mount options after a grace period
ntfs3: free the sbi after a grace period
unicode: free the map after a grace period
ipc: drop the mqueue mount with kern_unmount() on setup failure
eventfs: free the eventfs_inode after an rcu grace period too
9p: free the session after a grace period
watch_queue: Fix note pool publication race in watch_queue_set_size()
afs: free the super info after a grace period
pipe: preserve existing fasync readers on writer setup failure
...
|
|
There are spelling mistakes in the descr literal strings. Fix them.
Fixes: 095ddb501b39 ("selftests/bpf: Add sockopt case to verify prog_type")
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20261012212334.183116-1-colin.i.king@gmail.com
|
|
The /proc/mounts fallback in get_tracefs_pipe() accepts only non-tracefs
mount points, so a tracefs mounted outside the default locations is
ignored: bpftool prog tracelog then mounts a second tracefs, or exits
silently with --nomount. Negate the condition.
Fixes: be3245e22d22 ("tools: bpftool: attempt to mount tracefs if required for tracelog cmd")
Signed-off-by: Yuan Chen <chenyuan@kylinos.cn>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20261016015057.127061-1-chenyuan_fl@163.com
|
|
missed_kprobe attaches test1 to bpf_fentry_test1 and test2 to
bpf_kfunc_common_test, which test1 calls. test_missed_perf_kprobe()
expects the kprobe of test2 to miss exactly one run, the one test1
triggers, since kprobes don't nest.
The test is not serial, and the kprobe on bpf_fentry_test1 is global.
Any other test that does bpf_prog_test_run() on a fentry/fexit program
calls bpf_fentry_test1() and thereby fires test1, which calls
bpf_kfunc_common_test() from kprobe context. The kprobe of test2 then
counts an extra miss, and the test reads 2 instead of 1.
Expect at least one miss, as missed_kprobe_recursion does since commit
08a7078feacf ("selftests/bpf: Improve missed_kprobe_recursion test
robustness").
Fixes: 01e4ae474e39 ("selftests/bpf: Add test for missed counts of perf event link kprobe")
Signed-off-by: Qiliang Yuan <odys.yuan@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20261009-selftests-bpf-missed-perf-kprobe-v1-1-c9d0f75f6f99@gmail.com
|
|
Commit a6ca1a573e1f ("selftests/fuse: add test for FUSE_HAS_SYNCFS
privilege gating") registered test_syncfs in the fuse selftest Makefile
and .gitignore, but the test source was not part of the applied commit,
so building the fuse selftests fails:
make[1]: *** No rule to make target '.../test_syncfs', needed by 'all'.
Add test_syncfs.c as posted in Jimmy Zuber's v3 submission. The test
talks the raw FUSE protocol over /dev/fuse, so it can choose whether to
advertise FUSE_HAS_SYNCFS and directly observe whether the kernel
forwards a FUSE_SYNCFS request. It covers three cases:
T1: host-root mount, server sets FUSE_HAS_SYNCFS
-> FUSE_SYNCFS must reach the server.
T2: host-root mount, server does not opt in
-> FUSE_SYNCFS must not be sent (back-compat).
T3: server opts in but opened /dev/fuse without CAP_SYS_ADMIN while
still in the initial user namespace
-> FUSE_SYNCFS must be withheld.
Fixes: a6ca1a573e1f ("selftests/fuse: add test for FUSE_HAS_SYNCFS privilege gating")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/r/202609021808.5OxsIter-lkp@intel.com/
Closes: https://lore.kernel.org/r/202609230913.G4keWCG7-lkp@intel.com/
Link: https://lore.kernel.org/r/20260820130158.254808-3-jamz@amazon.com
Originally-by: Jimmy Zuber <jamz@amazon.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
|
|
into HEAD
KVM PPC selftests support for 7.4
Rework KVM selftest's handling of memory regions all so that PPC can force its
page table allocations to be naturally aligned, and then add initial selftests
support for PPC.
|
|
KVM selftests changes and a few KVM x86 fixes for 7.4
- Fix emulation of VMPTRST and VMPTRLD when eVMCS is in-use to match real
Hyper-V's behavior.
- Saturate L2's TSC frequency if stacking L1 and L2 scaling multipliers
exceeds what hardware supports, as attempting to run L2 with an illegal
multiplier will either cause VM-Entry to fail (VMX) or trigger a #GP when
writing MSR_AMD64_TSC_RATIO (SVM). The #GP is thankfully benign in the
grand scheme as even "unsafe" WRMSRs have exception fixup.
- Rework KVM selftest's handling of memory regions so that PPC can force its
page table allocations to be naturally aligned.
- Clean up selftest's VMX instruction helpers, and drop an absurd number of
completely useless return values, e.g. functions that unconditionally
return %true and then have every caller assert success.
- Add selftests support for Zhaoxin CPUs.
- Overhaul the TSC scaling test to add a regression test for the saturation
behavior, and to increase its coverage in general.
- Fix selftests usage various NUMA syscalls to account for an undocumented,
but known since 2007, off-by-one kernel bug. Add helpers to try and avoid
re-introducing the same flaws in the future.
- Automatically run xAPIC IPI migration test (between NUMA nodes) when
possible, as the entire point of the test is verify KVM's handling of page
migration of the APIC backing page.
- Misc cleanups.
|
|
tc_netkit_scrub attaches tc8 to the primary netkit device, sends an ICMP
echo with a mark and a priority through it, and checks the mark and the
priority that tc8 saw against what the scrub mode lets through.
tc8 records the mark and priority of every packet it sees, and the
device also carries what the system sends on its own once the device
is up, like IPv6 neighbor discovery or the mDNS of avahi-daemon. When
such a packet goes out after the echo, it overwrites what tc8 recorded,
and the test finds a mark and a priority of 0. Record only IPv4 ICMP
packets in tc8.
tc_netkit_scrub run 100 times on a bpf-next kernel with KASAN enabled,
x86_64 VM with 32 vCPUs and avahi-daemon running, before and after this
patch:
before after
outcome 2 of 100 failed (mark and priority 0) 0 of 100 failed
Fixes: 716fa7dadf11 ("selftests/bpf: Extend netkit tests to validate skb meta data")
Signed-off-by: Qiliang Yuan <odys.yuan@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20261016-selftests-bpf-tc-netkit-scrub-v2-1-b484a7ce2a63@gmail.com
|
|
KVM x86 misc changes for 7.4
- Mask off the address space ID when checking for illegal usage of
kvm_set_internal_memslot() to prevent false negatives on the sanity check.
- Explicitly zero reserved flags when delivering a SynIC message to avoid
leaking a byte of stack information to the guest.
- Rework TDX's handling of the canonical MMU root level to not rely on
userspace to fill CPUID correctly, as doing so lets userspace trivially
trigger a KVM_BUG_ON().
- Reject KVM_SET_NESTED_STATE if userspace "restores" L1 with EFER.LMA=1 &&
EFER.LME=0, which confuses KVM into trying to configure an 64-bit MMU
without PAE.
- Ignore EFER.LMA (clear it from KVM's cached save state) if EFER.LME=0 when
preparing L2 state, to fix another way to confuse KVM's MMU (and because
real hardware also ignores EFER.LMA).
- Improve KVM's sanity checks for a misconfigured MMU to (hopefully) detect
all of the ways KVM can botch EFER.LMA vs. CR4.PAE.
- Remove the "full" out-param from kvm_x86_ops.flush_tlb_gva() as the param
is only used to avoid what effectively amounts to a single memory write.
- Fix a mostly-benign bug where KVM can write through a guest's read-only
mapping due to not checking the error code when expediting emulated MMIO
page faults.
- Honor the guest's view of the "EFER.LMSLE must be zero" defeature so that
userspace can provide migration compatibility between Rome and Milan+.
- Pend a KVM_REQ_EVENT request when an exception is morphed into a nested
VM-Exit, otherwise KVM can fail to actually deliver the nested VM-Exit,
e.g. when injecting a page fault.
- Add support for PML on SVM.
- Add support for virtualizing Bus Lock Detect on SVM, and fix a number of
DR6 bugs and warts along the way.
- Misc fixes and cleanups.
|
|
KVM guest_memfd and CoCo changes for 7.4
- Take the invalidate lock when unbinding a dying file to fix a race with
kvm_gmem_invalidate_end() that results in KVM leaving the MMU invalidation
count elevated. Not taking the lock in the first place was pure misguided
paranoid.
- When binding a memslot, purge the bindings if storing the new memslot fails,
as Xarray's "store range" API can subtly fail partway through.
- Establish memslot<=>guest_memfd bindings *after* the memslot is ready, as
the memslot becomes reachable the instant the binding is installed.
- Don't grab a page refcount when reloading an SNP VMSA and stop returning a
"struct page" from guest_memfd's PFN lookup altogether, to ensure that KVM
doesn't hold any unnecessary refcounts (the lifetime of the page is ensured
by MMU notifiers and similar hooks). Preventing unnecessary refcounts
greatly simplifies supporting in-place SHARED=>PRIVATE conversions.
- Add support for in-place PRIVATE<=>SHARED conversion, i.e. allow a single
guest_memfd instance to be used for both PRIVATE and SHARED variations of
CoCo guests' memory (though not at the same time). This eliminates the need
to double allocate guest memory for TDX and SNP, and is basically a hard
requirement for pKVM, which relies on being able to preserve memory contents
on conversions.
- Hack-a-fix a deadlock bug in ->error_remove_folio() by returning -EBUSY if
the filemap invalidate lock is contended. Punt on a proper fix for the
moment, as a proper fix likely involves reworking truncate_error_folio().
- Add a pile of selftests for in-place conversions.
- Misc guest_memfd cleanups
Conflicts in arch/arm64/kvm/mmu.c: convert to use s2vi.
|
