Recent commit changed the semantics from NOT_VALID to VALID.
I didn't realize that the flags are not stored atomically
with the entry in XArray. There's still a race of reader
observing a VALID mark for a slot, getting interrupted,
writer replacing the entry with a different one, reader
continuing, fetching the entry which is now a different
pointer than the pointer for which VALID was meant.
The biggest consequence of this is that we may see a UAF
since net_shaper_rollback() assumed that entries without
VALID can be freed without observing RCU.
Looks like the XArray marks are buying us nothing at this
point. Let's convert the code to an explicit valid field.
The smp_load_acquire() / smp_store_release() barriers are
marginally cleaner.
Reported-by: Sashiko <sashiko-bot@kernel.org>
Fixes: 93954b40f6 ("net-shapers: implement NL set and delete operations")
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260515221325.1685455-3-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
As previously discussed we don't care about making the shaper
state fully RCU-compliant because the hierarchy itself can't
be dumped in one go over Netlink. Let's annotate the reads
and writes to make that clear.
The field-by-field assignments will also be useful for the
next commit which adds explicit "valid" field (which we don't
want to override with the current full struct assignment).
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260515221325.1685455-2-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
USB3 needs to have a GPIO pulled HIGH in order to function. Add vcc-gpio
to do so.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://lore.kernel.org/r/20260406220528.101340-1-rosenp@gmail.com
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
On boot there is this warning:
/axi@18000000/pinctrl@3f1c0: Fixed dependency cycle(s) with /axi@18000000/pinctrl@3f1c0/pwm_leds
Fix by moving the pinctrl configuration to pwm, which is the actual
consumer.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://lore.kernel.org/r/20260430051612.700050-1-rosenp@gmail.com
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
mlx5e_xfrm_add_state() handles acquire-flow temporary SAs by allocating
software state and skipping hardware offload setup.
That path jumps to the common success label before taking the eswitch mode
block. After tunnel-mode validation was moved earlier, the common success
label unconditionally calls mlx5_eswitch_unblock_mode(). For acquire SAs,
this decrements esw->offloads.num_block_mode without a matching increment.
Return directly after installing the acquire SA offload handle, so only the
paths that successfully called mlx5_eswitch_block_mode() call the matching
unblock.
Fixes: 22239eb258 ("net/mlx5e: Prevent tunnel reformat when tunnel mode not allowed")
Signed-off-by: Prathamesh Deshpande <prathameshdeshpande7@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260510225903.13184-1-prathameshdeshpande7@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Gal Pressman says:
====================
udp: gso: Fix __udp_gso_segment() after GSO_PARTIAL UDP length change
This series fixes two issues introduced by commit b10b446ce7 ("udp:
gso: Use single MSS length in UDP header for GSO_PARTIAL"), which
switched __udp_gso_segment() to write the single MSS length into the UDP
header for GSO_PARTIAL skbs.
Patch 1 (from Alice) fixes the UDP checksum adjustment in
__udp_gso_segment().
The patch adjusts the checksum by the correct delta, and since msslen
and newlen become equivalent before the loop, drops one of the two
variables to simplify the code.
Patch 2 handles the case where the last segment of a GSO_PARTIAL skb is
itself a GSO skb. This happens when the original packet size is an exact
multiple of MSS, so the post-loop segment is not a remainder skb but a
full GSO chunk and must also carry the single MSS length in its UDP
header.
====================
Link: https://patch.msgid.link/20260518062250.3019914-1-gal@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Following the cited commit, __udp_gso_segment() writes single MSS length
in the UDP header.
The cited patch doesn't account for the fact that the last segment could
be a GSO skb by itself. This could happen when the size of the packet is
a multiple of MSS, hence the first segment is also the last one (there
is no need for a remainder skb).
When the post-loop segment is a GSO skb, assign the single MSS length in
the UDP header.
Fixes: b10b446ce7 ("udp: gso: Use single MSS length in UDP header for GSO_PARTIAL")
Reported-by: Matthew Schwartz <matthew.schwartz@linux.dev>
Closes: https://lore.kernel.org/all/6c3fb15e-711d-4b8d-b152-e03d9b05293f@linux.dev/
Tested-by: Matthew Schwartz <matthew.schwartz@linux.dev>
Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
Signed-off-by: Gal Pressman <gal@nvidia.com>
Link: https://patch.msgid.link/20260518062250.3019914-3-gal@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The cited commit started using msslen for uh->len, but still uses newlen
to adjust uh->check. Although the checksum is ignored in most cases due
to the hardware offload, __udp_gso_segment attempts to maintain the
correct one. Fix uh->check and adjust it by the right value.
Additionally, after the fix, newlen becomes assigned and unused before
the loop. The code can be simplified a bit if mss adjustment is dropped,
so that newlen becomes equal to msslen before the loop, and msslen can
be also dropped, saving a few lines of code.
This brings us back to one variable, drops an unneeded arithmetic for
mss, and fixes the UDP checksum.
Fixes: b10b446ce7 ("udp: gso: Use single MSS length in UDP header for GSO_PARTIAL")
Signed-off-by: Alice Mikityanska <alice@isovalent.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: Gal Pressman <gal@nvidia.com>
Link: https://patch.msgid.link/20260518062250.3019914-2-gal@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In Makefile.perf, ALL_PROGRAMS includes SCRIPTS (perf-archive,
perf-iostat). However, unlike PROGRAMS and DLFILTERS, SCRIPTS was not
prefixed with $(OUTPUT).
During out-of-tree builds (or when O= is specified), Make checked for the
unprefixed target 'tools/perf/perf-archive'. Since the actual script was
installed into $(OUTPUT)perf-archive, Make concluded the target was
missing and continuously re-executed the script installation rule on every
single incremental build.
Prefix SCRIPTS with $(OUTPUT) and update the static pattern rule to ensure
Kbuild correctly tracks generated script prerequisites during incremental
builds.
Reviewed-by: Namhyung Kim <namhyung@kernel.org>
Assisted-by: Gemini:gemini-3.1-pro-preview
Signed-off-by: Ian Rogers <irogers@google.com>
Tested-by: James Clark <james.clark@linaro.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Alexandre Chartre <alexandre.chartre@oracle.com>
Cc: Alexandre Ghiti <alex@ghiti.fr>
Cc: Andrii Nakryiko <andrii@kernel.org>
Cc: Ankur Arora <ankur.a.arora@oracle.com>
Cc: Collin Funk <collin.funk1@gmail.com>
Cc: Costa Shulyupin <costa.shul@redhat.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Dapeng Mi <dapeng1.mi@linux.intel.com>
Cc: David Sterba <dsterba@suse.com>
Cc: Dmitrii Dolgov <9erthalion6@gmail.com>
Cc: Eduard Zingerman <eddyz87@gmail.com>
Cc: Howard Chu <howardchu95@gmail.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Cc: Leo Yan <leo.yan@arm.com>
Cc: Markus Mayer <mmayer@broadcom.com>
Cc: Martin KaFai Lau <martin.lau@linux.dev>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Terrell <terrelln@fb.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Paul Walmsley <pjw@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Quentin Monnet <qmo@kernel.org>
Cc: Ricky Ringler <ricky.ringler@proton.me>
Cc: Song Liu <song@kernel.org>
Cc: Swapnil Sapkal <swapnil.sapkal@amd.com>
Cc: Thomas Falcon <thomas.falcon@intel.com>
Cc: Tomas Glozar <tglozar@redhat.com>
Cc: Yonghong Song <yonghong.song@linux.dev>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Add a test to capture the comment in tools/perf/arch/x86/util/evlist.c.
Test that slots and topdown-retiring get appropriately sorted with
respect to instructions when they're all specified together.
When the PMU requires topdown event grouping (indicated by the pressence
of the slots event) metric events should be after slots, which should be
the group leader.
Add a related test that when the slots event isn't given it is injected
into the appropriate group.
Signed-off-by: Ian Rogers <irogers@google.com>
Tested-by: Zide Chen <zide.chen@intel.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Collin Funk <collin.funk1@gmail.com>
Cc: Dmitrii Dolgov <9erthalion6@gmail.com>
Cc: German Gomez <german.gomez@arm.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: James Clark <james.clark@linaro.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Add a test for uncore event sorting matching multiple PMUs.
Uncore PMUs may have a common prefix, like the PMUs
uncore_imc_free_running_0 and uncore_imc_free_running_1 have a prefix of
uncore_imc_free_running.
Parsing an event group like "{data_read,data_write}" for those PMUs
should result with two groups:
"{uncore_imc_free_running_0/data_read/,uncore_imc_free_running_0/data_write/},
{uncore_imc_free_running_1/data_read/,uncore_imc_free_running_1/data_write/}"
which means the evsels need resorting as when initially parsed the
evsels are ordered with mixed PMUs:
"{uncore_imc_free_running_0/data_read/,uncore_imc_free_running_1/data_read/,
uncore_imc_free_running_0/data_write/,uncore_imc_free_running_1/data_write/}".
Signed-off-by: Ian Rogers <irogers@google.com>
Tested-by: Zide Chen <zide.chen@intel.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Collin Funk <collin.funk1@gmail.com>
Cc: Dmitrii Dolgov <9erthalion6@gmail.com>
Cc: German Gomez <german.gomez@arm.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: James Clark <james.clark@linaro.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
In Makefile.config, CFLAGS, CXXFLAGS, LIBLLVM, and EXTLIBS were assigned
using recursive expansion or appended with raw $(shell $(LLVM_CONFIG) ...)
calls. Because these variables were expanded during dependency evaluation
across every single object file compilation rule, Kbuild continuously
re-executed llvm-config forks nearly 200 times during incremental builds.
Convert llvm-config shell queries to simply expanded variables (:=) to
ensure Make evaluates LLVM compiler flags and library paths exactly once
when Makefile.config is parsed, eliminating ~185 redundant sub-processes
during build startup.
Reviewed-by: Namhyung Kim <namhyung@kernel.org>
Assisted-by: Gemini:gemini-3.1-pro-preview
Signed-off-by: Ian Rogers <irogers@google.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Alexandre Chartre <alexandre.chartre@oracle.com>
Cc: Alexandre Ghiti <alex@ghiti.fr>
Cc: Andrii Nakryiko <andrii@kernel.org>
Cc: Ankur Arora <ankur.a.arora@oracle.com>
Cc: Collin Funk <collin.funk1@gmail.com>
Cc: Costa Shulyupin <costa.shul@redhat.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Dapeng Mi <dapeng1.mi@linux.intel.com>
Cc: David Sterba <dsterba@suse.com>
Cc: Dmitrii Dolgov <9erthalion6@gmail.com>
Cc: Eduard Zingerman <eddyz87@gmail.com>
Cc: Howard Chu <howardchu95@gmail.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: James Clark <james.clark@linaro.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Cc: Leo Yan <leo.yan@arm.com>
Cc: Markus Mayer <mmayer@broadcom.com>
Cc: Martin KaFai Lau <martin.lau@linux.dev>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Terrell <terrelln@fb.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Paul Walmsley <pjw@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Quentin Monnet <qmo@kernel.org>
Cc: Ricky Ringler <ricky.ringler@proton.me>
Cc: Song Liu <song@kernel.org>
Cc: Swapnil Sapkal <swapnil.sapkal@amd.com>
Cc: Thomas Falcon <thomas.falcon@intel.com>
Cc: Tomas Glozar <tglozar@redhat.com>
Cc: Yonghong Song <yonghong.song@linux.dev>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
In pmu-events/Build, ZENS, ARMS, and INTELS were assigned using recursive
assignment (=), and model_name/vendor_name were evaluated using shell
macros (echo ... | sed ...).
Because these variables were expanded inside the COPY_RULE dependency
evaluation loop across hundreds of PMU JSON files and inside every metric
generation recipe, Kbuild continuously re-executed 'ls', 'grep', and 'sed'
shell forks thousands of times during AST parsing and execution.
Convert ZENS, ARMS, and INTELS to simply expanded variables (:=) and
replace model_name/vendor_name with pure GNU Make string functions. This
guarantees Make executes directory probing shell forks exactly once when
the Build file is parsed and evaluates path macros purely in memory,
completely eliminating over 7,800 redundant sub-processes during build
startup.
Reviewed-by: Namhyung Kim <namhyung@kernel.org>
Assisted-by: Gemini:gemini-3.1-pro-preview
Signed-off-by: Ian Rogers <irogers@google.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Alexandre Chartre <alexandre.chartre@oracle.com>
Cc: Alexandre Ghiti <alex@ghiti.fr>
Cc: Andrii Nakryiko <andrii@kernel.org>
Cc: Ankur Arora <ankur.a.arora@oracle.com>
Cc: Collin Funk <collin.funk1@gmail.com>
Cc: Costa Shulyupin <costa.shul@redhat.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Dapeng Mi <dapeng1.mi@linux.intel.com>
Cc: David Sterba <dsterba@suse.com>
Cc: Dmitrii Dolgov <9erthalion6@gmail.com>
Cc: Eduard Zingerman <eddyz87@gmail.com>
Cc: Howard Chu <howardchu95@gmail.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: James Clark <james.clark@linaro.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Cc: Leo Yan <leo.yan@arm.com>
Cc: Markus Mayer <mmayer@broadcom.com>
Cc: Martin KaFai Lau <martin.lau@linux.dev>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Terrell <terrelln@fb.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Paul Walmsley <pjw@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Quentin Monnet <qmo@kernel.org>
Cc: Ricky Ringler <ricky.ringler@proton.me>
Cc: Song Liu <song@kernel.org>
Cc: Swapnil Sapkal <swapnil.sapkal@amd.com>
Cc: Thomas Falcon <thomas.falcon@intel.com>
Cc: Tomas Glozar <tglozar@redhat.com>
Cc: Yonghong Song <yonghong.song@linux.dev>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Booting with "nopcid" clears X86_FEATURE_PCID and keeps CR4.PCIDE from being
set to one. On AMD CPUs that support INVLPGB, broadcast TLB flushing remains
enabled.
There are two checks that decide whether the global ASID code runs,
mm_global_asid() and consider_global_asid(), that key off of the
X86_FEATURE_INVLPGB feature. Once an mm becomes active on more than three
CPUs, consider_global_asid() assigns it a global ASID, after which
flush_tlb_mm_range() takes the broadcast_tlb_flush() path using a non-zero
PCID. Issuing an INVLPGB with a non-zero PCID while CR4.PCIDE is not set
results in a #GP:
Oops: general protection fault, kernel NULL pointer dereference 0x1: 0000 [#1] SMP NOPTI
CPU: 158 UID: 0 PID: 3119 Comm: snap Not tainted 7.1.0-rc3 #1 PREEMPT(full)
Hardware name: ...
RIP: 0010:broadcast_tlb_flush
Code: ... 89 da 48 83 c8 07 <0f> 01 fe eb 08 cc cc cc ...
Call Trace:
<TASK>
flush_tlb_mm_range
ptep_clear_flush
wp_page_copy
? _raw_spin_unlock
__handle_mm_fault
handle_mm_fault
do_user_addr_fault
exc_page_fault
asm_exc_page_fault
All processors that support broadcast TLB invalidation also have PCID support,
so it is only the "nopcid" scenario that is of concern. In this situation just
disable the broadcast TLB support using the CPUID dependency support by making
X86_FEATURE_INVLPGB dependent on X86_FEATURE_PCID.
[ bp: Massage commit message. ]
Fixes: 4afeb0ed17 ("x86/mm: Enable broadcast TLB invalidation for multi-threaded processes")
Suggested-by: Dave Hansen <dave.hansen@intel.com>
Assisted-by: Claude:claude-opus-4.7
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Acked-by: Rik van Riel <riel@surriel.com>
Cc: <stable@kernel.org>
Link: https://patch.msgid.link/b915acfd63e8b2a094fdeb8dc608738072518764.1779296450.git.thomas.lendacky@amd.com
xe_vfio_pci_reset_done() sets deferred_reset and, when it manages to
acquire state_mutex itself, hands the cleanup off to
xe_vfio_pci_state_mutex_unlock().
That helper already clears deferred_reset and runs xe_vfio_pci_reset()
before dropping the mutex. Calling xe_vfio_pci_reset() again right
afterwards repeats the reset handling unnecessarily.
Fixes: 1f5556ec8b ("vfio/xe: Add device specific vfio_pci driver variant for Intel graphics")
Signed-off-by: GuoHan Zhao <zhaoguohan@kylinos.cn>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Acked-by: Michał Winiarski <michal.winiarski@intel.com>
Link: https://lore.kernel.org/r/20260427012128.117051-1-zhaoguohan@kylinos.cn
Signed-off-by: Alex Williamson <alex@shazbot.org>
The mailbox operation for the Hisi accelerator device now provides a
new read function that supports direct information retrieval by
specifying commands, thereby simplifying the related mailbox command
handling in the driver.
Signed-off-by: Weili Qian <qianweili@huawei.com>
Signed-off-by: Longfang Liu <liulongfang@huawei.com>
Link: https://lore.kernel.org/r/20260514092026.2018844-1-liulongfang@huawei.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Currently, jevents.py emits both the massive 2.8 MB big_c_string literal
and tens of thousands of compact_pmu_event struct arrays into a single
pmu-events.c compilation unit. Compiling this giant file takes ~2.2 seconds
on a single CPU core during Kbuild startup.
Refactor jevents.py to emit big_c_string into a dedicated
pmu-events-string.c compilation unit. This allows Kbuild to compile
pmu-events.o and pmu-events-string.o simultaneously in parallel across
two separate CPU cores, preserving 100% string deduplication and zero
dynamic ELF relocations while cutting C compilation latency in half.
Add pmu-events-string.c to tools/perf/.gitignore to ensure in-tree Kbuild
runs do not leave untracked generated files in the working directory.
To guarantee 100% backward compatibility with GNU Make 4.0+ (avoiding the
Make 4.3+ grouped target &: syntax which causes older Make versions like
4.2.1 to spawn multiple concurrent jevents.py processes during parallel
builds), implement a robust dependency chaining pattern:
$(PMU_EVENTS_C): $(JEVENTS_DEPS)
$(PMU_EVENTS_STRING_C): $(PMU_EVENTS_C)
@:
This ensures jevents.py is invoked exactly once. If jevents.py aborts
early, Make's .DELETE_ON_ERROR: purges pmu-events.c, guaranteeing that
subsequent Make invocations correctly re-execute the script and overwrite
pmu-events-string.c. In jevents.py, explicitly close output_file first
and output_string_file second at the tail of main() to guarantee that
pmu-events-string.c receives a filesystem timestamp greater than or equal
to pmu-events.c, completely avoiding redundant incremental rebuilds.
Reviewed-by: Namhyung Kim <namhyung@kernel.org>
Assisted-by: Gemini:gemini-3.1-pro-preview
Signed-off-by: Ian Rogers <irogers@google.com>
Tested-by: James Clark <james.clark@linaro.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Alexandre Chartre <alexandre.chartre@oracle.com>
Cc: Alexandre Ghiti <alex@ghiti.fr>
Cc: Andrii Nakryiko <andrii@kernel.org>
Cc: Ankur Arora <ankur.a.arora@oracle.com>
Cc: Collin Funk <collin.funk1@gmail.com>
Cc: Costa Shulyupin <costa.shul@redhat.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Dapeng Mi <dapeng1.mi@linux.intel.com>
Cc: David Sterba <dsterba@suse.com>
Cc: Dmitrii Dolgov <9erthalion6@gmail.com>
Cc: Eduard Zingerman <eddyz87@gmail.com>
Cc: Howard Chu <howardchu95@gmail.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Cc: Leo Yan <leo.yan@arm.com>
Cc: Markus Mayer <mmayer@broadcom.com>
Cc: Martin KaFai Lau <martin.lau@linux.dev>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Terrell <terrelln@fb.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Paul Walmsley <pjw@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Quentin Monnet <qmo@kernel.org>
Cc: Ricky Ringler <ricky.ringler@proton.me>
Cc: Song Liu <song@kernel.org>
Cc: Swapnil Sapkal <swapnil.sapkal@amd.com>
Cc: Thomas Falcon <thomas.falcon@intel.com>
Cc: Tomas Glozar <tglozar@redhat.com>
Cc: Yonghong Song <yonghong.song@linux.dev>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
By default, the perf tool compiles and statically links against its own
internal copy of libbpf (tools/lib/bpf/libbpf.a), setting LIBBPF_STATIC=1.
Despite this static linkage, Makefile.config unconditionally executed
$(call feature_check,libbpf), which forced a synchronous sub-make fork
during AST parsing to detect dynamic system libbpf libraries.
As noted in the internal Makefile comments, this check was executed purely
so that running `make VF=1` would display the detection status of system
libbpf. During standard builds without LIBBPF_DYNAMIC=1, the detection
result was entirely ignored.
Wrap the libbpf feature check inside LIBBPF_DYNAMIC=1 so Make avoids the
redundant sub-make fork overhead during standard static builds.
Reviewed-by: Namhyung Kim <namhyung@kernel.org>
Assisted-by: Gemini:gemini-3.1-pro-preview
Signed-off-by: Ian Rogers <irogers@google.com>
Tested-by: James Clark <james.clark@linaro.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Alexandre Chartre <alexandre.chartre@oracle.com>
Cc: Alexandre Ghiti <alex@ghiti.fr>
Cc: Andrii Nakryiko <andrii@kernel.org>
Cc: Ankur Arora <ankur.a.arora@oracle.com>
Cc: Collin Funk <collin.funk1@gmail.com>
Cc: Costa Shulyupin <costa.shul@redhat.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Dapeng Mi <dapeng1.mi@linux.intel.com>
Cc: David Sterba <dsterba@suse.com>
Cc: Dmitrii Dolgov <9erthalion6@gmail.com>
Cc: Eduard Zingerman <eddyz87@gmail.com>
Cc: Howard Chu <howardchu95@gmail.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Cc: Leo Yan <leo.yan@arm.com>
Cc: Markus Mayer <mmayer@broadcom.com>
Cc: Martin KaFai Lau <martin.lau@linux.dev>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Terrell <terrelln@fb.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Paul Walmsley <pjw@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Quentin Monnet <qmo@kernel.org>
Cc: Ricky Ringler <ricky.ringler@proton.me>
Cc: Song Liu <song@kernel.org>
Cc: Swapnil Sapkal <swapnil.sapkal@amd.com>
Cc: Thomas Falcon <thomas.falcon@intel.com>
Cc: Tomas Glozar <tglozar@redhat.com>
Cc: Yonghong Song <yonghong.song@linux.dev>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The prepare step is a large serialization point before parallel
sub-makes build the perf tool. The libsymbol headers are used in the
bench and util libraries. Move the libsymbol dependency out of the
prepare step and into the dependencies for those targets to avoid it
being a source of serialization in the prepare step.
Reviewed-by: Namhyung Kim <namhyung@kernel.org>
Assisted-by: Gemini:gemini-3.1-pro-preview
Signed-off-by: Ian Rogers <irogers@google.com>
Tested-by: James Clark <james.clark@linaro.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Alexandre Chartre <alexandre.chartre@oracle.com>
Cc: Alexandre Ghiti <alex@ghiti.fr>
Cc: Andrii Nakryiko <andrii@kernel.org>
Cc: Ankur Arora <ankur.a.arora@oracle.com>
Cc: Collin Funk <collin.funk1@gmail.com>
Cc: Costa Shulyupin <costa.shul@redhat.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Dapeng Mi <dapeng1.mi@linux.intel.com>
Cc: David Sterba <dsterba@suse.com>
Cc: Dmitrii Dolgov <9erthalion6@gmail.com>
Cc: Eduard Zingerman <eddyz87@gmail.com>
Cc: Howard Chu <howardchu95@gmail.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Cc: Leo Yan <leo.yan@arm.com>
Cc: Markus Mayer <mmayer@broadcom.com>
Cc: Martin KaFai Lau <martin.lau@linux.dev>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Terrell <terrelln@fb.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Paul Walmsley <pjw@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Quentin Monnet <qmo@kernel.org>
Cc: Ricky Ringler <ricky.ringler@proton.me>
Cc: Song Liu <song@kernel.org>
Cc: Swapnil Sapkal <swapnil.sapkal@amd.com>
Cc: Thomas Falcon <thomas.falcon@intel.com>
Cc: Tomas Glozar <tglozar@redhat.com>
Cc: Yonghong Song <yonghong.song@linux.dev>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Currently, BPF skeleton generation rules (bpf_skel.mak) are evaluated as
part of util/Build. However, because LIBPERF_UTIL_IN explicitly depends
on the top-level static libbpf archive, Make completely blocked the
execution of bpftool bootstrap and skeleton generation until libbpf
finished compiling midway through the build.
Since bpftool bootstrap compiles its own independent copy of libbpf.a, it
does not depend on the top-level libbpf target.
Decouple early skeleton tooling generation by attaching bpf-skel-prepare
to the umbrella prepare target, exporting CONFIG_PERF_BPF_SKEL to ensure
accurate feature propagation. This allows Make to compile bpftool and
dump vmlinux.h in the background at build startup, eliminating the initial
sub-make startup bottleneck before BPF object compilation while keeping
100% of tooling rules perfectly encapsulated in bpf_skel.mak. Provide an
empty fallback target to ensure builds succeed when BPF skeletons are
disabled.
Reviewed-by: Namhyung Kim <namhyung@kernel.org>
Assisted-by: Gemini:gemini-3.1-pro-preview
Signed-off-by: Ian Rogers <irogers@google.com>
Tested-by: James Clark <james.clark@linaro.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Alexandre Chartre <alexandre.chartre@oracle.com>
Cc: Alexandre Ghiti <alex@ghiti.fr>
Cc: Andrii Nakryiko <andrii@kernel.org>
Cc: Ankur Arora <ankur.a.arora@oracle.com>
Cc: Collin Funk <collin.funk1@gmail.com>
Cc: Costa Shulyupin <costa.shul@redhat.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Dapeng Mi <dapeng1.mi@linux.intel.com>
Cc: David Sterba <dsterba@suse.com>
Cc: Dmitrii Dolgov <9erthalion6@gmail.com>
Cc: Eduard Zingerman <eddyz87@gmail.com>
Cc: Howard Chu <howardchu95@gmail.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Cc: Leo Yan <leo.yan@arm.com>
Cc: Markus Mayer <mmayer@broadcom.com>
Cc: Martin KaFai Lau <martin.lau@linux.dev>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Terrell <terrelln@fb.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Paul Walmsley <pjw@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Quentin Monnet <qmo@kernel.org>
Cc: Ricky Ringler <ricky.ringler@proton.me>
Cc: Song Liu <song@kernel.org>
Cc: Swapnil Sapkal <swapnil.sapkal@amd.com>
Cc: Thomas Falcon <thomas.falcon@intel.com>
Cc: Tomas Glozar <tglozar@redhat.com>
Cc: Yonghong Song <yonghong.song@linux.dev>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Currently, bpftool and vmlinux.h are prerequisites of the top-level
prepare target in Makefile.perf. This unnecessarily blocks the massive
parallel C compilation of libraries (perf-util, perf-ui, pmu-events) during
the initial startup phase.
Move all bpftool and vmlinux.h generation rules down into
tools/perf/bpf_skel.mak to encapsulate BPF tooling completely within the
skeleton framework. Remove them entirely from prepare to unblock immediate
parallel build execution.
To prevent parallel sub-makes (perf-util and perf-bench) from racing to
build shared prerequisites concurrently, while maintaining strict directory
encapsulation without top-level inclusions, serialize bench after the util
static archive finishes using an order-only prerequisite:
$(LIBPERF_BENCH_IN): FORCE prepare | $(LIBPERF_UTIL)
Reviewed-by: Namhyung Kim <namhyung@kernel.org>
Assisted-by: Gemini:gemini-3.1-pro-preview
Signed-off-by: Ian Rogers <irogers@google.com>
Tested-by: James Clark <james.clark@linaro.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Alexandre Chartre <alexandre.chartre@oracle.com>
Cc: Alexandre Ghiti <alex@ghiti.fr>
Cc: Andrii Nakryiko <andrii@kernel.org>
Cc: Ankur Arora <ankur.a.arora@oracle.com>
Cc: Collin Funk <collin.funk1@gmail.com>
Cc: Costa Shulyupin <costa.shul@redhat.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Dapeng Mi <dapeng1.mi@linux.intel.com>
Cc: David Sterba <dsterba@suse.com>
Cc: Dmitrii Dolgov <9erthalion6@gmail.com>
Cc: Eduard Zingerman <eddyz87@gmail.com>
Cc: Howard Chu <howardchu95@gmail.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Cc: Leo Yan <leo.yan@arm.com>
Cc: Markus Mayer <mmayer@broadcom.com>
Cc: Martin KaFai Lau <martin.lau@linux.dev>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Terrell <terrelln@fb.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Paul Walmsley <pjw@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Quentin Monnet <qmo@kernel.org>
Cc: Ricky Ringler <ricky.ringler@proton.me>
Cc: Song Liu <song@kernel.org>
Cc: Swapnil Sapkal <swapnil.sapkal@amd.com>
Cc: Thomas Falcon <thomas.falcon@intel.com>
Cc: Tomas Glozar <tglozar@redhat.com>
Cc: Yonghong Song <yonghong.song@linux.dev>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Currently, the top-level Makefile.perf defines a massive global bpf-skel
umbrella target that pre-compiles all 12+ BPF skeletons (%.skel.h) upfront
before launching sub-makes. This forces unrelated sub-makes to serialize
behind bpftool and clang BPF target evaluations, causing parallel build
bottlenecks.
Furthermore, bench_uprobe.bpf.c lived inside util/bpf_skel/, breaking
conceptual directory encapsulation since it is consumed purely by
bench/uprobe.c.
Refactor the BPF skeletons to better achieve directory isolation:
1. Move tools/perf/util/bpf_skel/bench_uprobe.bpf.c directly into
tools/perf/bench/bpf_skel/.
2. Extract the skeleton generation infrastructure out of Makefile.perf into
a shared inclusion file tools/perf/bpf_skel.mak.
3. Include bpf_skel.mak locally inside tools/perf/util/Build and
tools/perf/bench/Build and bind precise local prerequisites.
4. Safely synchronize the shared bpftool bootstrap and vmlinux.h targets
via the conditional prepare: umbrella to avoid parallel sub-make races,
while evaluating the actual skeletons completely locally on demand. A
later patch will move these targets into bpf_skel.mak.
5. Export CLANG from the global Makefile to ensure accurate tool
propagation.
6. Clean up Makefile.perf by stripping the global bpf-skel umbrella target
and its SKELETONS list.
While removing code from Makefile.perf generally helps build
performance, the impact here is minimal. The main motivation for the
change is to better encapsulate things in the build and simplify
Makefile.perf that has around 50 lines removed.
Reviewed-by: Namhyung Kim <namhyung@kernel.org>
Assisted-by: Gemini:gemini-3.1-pro-preview
Signed-off-by: Ian Rogers <irogers@google.com>
Tested-by: James Clark <james.clark@linaro.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Alexandre Chartre <alexandre.chartre@oracle.com>
Cc: Alexandre Ghiti <alex@ghiti.fr>
Cc: Andrii Nakryiko <andrii@kernel.org>
Cc: Ankur Arora <ankur.a.arora@oracle.com>
Cc: Collin Funk <collin.funk1@gmail.com>
Cc: Costa Shulyupin <costa.shul@redhat.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Dapeng Mi <dapeng1.mi@linux.intel.com>
Cc: David Sterba <dsterba@suse.com>
Cc: Dmitrii Dolgov <9erthalion6@gmail.com>
Cc: Eduard Zingerman <eddyz87@gmail.com>
Cc: Howard Chu <howardchu95@gmail.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Cc: Leo Yan <leo.yan@arm.com>
Cc: Markus Mayer <mmayer@broadcom.com>
Cc: Martin KaFai Lau <martin.lau@linux.dev>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Terrell <terrelln@fb.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Paul Walmsley <pjw@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Quentin Monnet <qmo@kernel.org>
Cc: Ricky Ringler <ricky.ringler@proton.me>
Cc: Song Liu <song@kernel.org>
Cc: Swapnil Sapkal <swapnil.sapkal@amd.com>
Cc: Thomas Falcon <thomas.falcon@intel.com>
Cc: Tomas Glozar <tglozar@redhat.com>
Cc: Yonghong Song <yonghong.song@linux.dev>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Currently, the $(LIBPMU_EVENTS_IN) sub-make depends on the massive
"prepare" umbrella target. Because "prepare" depends on external
libraries (libapi, libperf, etc.) as well as dozens of generated
headers, make completely serializes the launch of the pmu-events
sub-make behind some of those unrelated prerequisites.
Since pmu-events is a large compilation unit, unblock its startup by
binding it directly to only $(LIBPERF) instead of prepare. This allows
background python generation scripts to overlap simultaneously with
the rest of the build.
Testing a parallel build (make -j28 clean all) shows improvements:
Before:
real 0m27.642s
user 2m32.356s
sys 0m26.683s
After:
real 0m22.254s
user 2m32.810s
sys 0m24.646s
This reclaims over 5 full seconds of build latency (~19.5% overall
reduction) by elevating average CPU concurrency from ~5.5 active cores
up to ~8 active cores.
Reviewed-by: Namhyung Kim <namhyung@kernel.org>
Assisted-by: Gemini:gemini-3.1-pro-preview
Signed-off-by: Ian Rogers <irogers@google.com>
Tested-by: James Clark <james.clark@linaro.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Alexandre Chartre <alexandre.chartre@oracle.com>
Cc: Alexandre Ghiti <alex@ghiti.fr>
Cc: Andrii Nakryiko <andrii@kernel.org>
Cc: Ankur Arora <ankur.a.arora@oracle.com>
Cc: Collin Funk <collin.funk1@gmail.com>
Cc: Costa Shulyupin <costa.shul@redhat.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Dapeng Mi <dapeng1.mi@linux.intel.com>
Cc: David Sterba <dsterba@suse.com>
Cc: Dmitrii Dolgov <9erthalion6@gmail.com>
Cc: Eduard Zingerman <eddyz87@gmail.com>
Cc: Howard Chu <howardchu95@gmail.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Cc: Leo Yan <leo.yan@arm.com>
Cc: Markus Mayer <mmayer@broadcom.com>
Cc: Martin KaFai Lau <martin.lau@linux.dev>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Terrell <terrelln@fb.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Paul Walmsley <pjw@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Quentin Monnet <qmo@kernel.org>
Cc: Ricky Ringler <ricky.ringler@proton.me>
Cc: Song Liu <song@kernel.org>
Cc: Swapnil Sapkal <swapnil.sapkal@amd.com>
Cc: Thomas Falcon <thomas.falcon@intel.com>
Cc: Tomas Glozar <tglozar@redhat.com>
Cc: Yonghong Song <yonghong.song@linux.dev>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Previously, builtin-trace.c directly included 15 embedded C files
(e.g. trace/beauty/mmap.c and fsconfig_arrays.c), which in turn depend
on dozens of generated beauty script arrays. To satisfy these embedded
inclusions, the global Makefile.perf would define all the generator
variables/rules and include them in the prepare umbrella target, choking
parallel build startup.
Furthermore, tools/perf/util/syscalltbl.c included its own generated mapper,
and util/env.c conditionally included arch_errno_names.c inline, splitting
consumers across directories and preventing clean Make encapsulation.
Refactor the framework to achieve better encapsulation:
1. Move util/syscalltbl.[ch] into trace/beauty/ to co-locate with all
generated code consumers.
2. Create fsconfig.c and flatten embedded beauty .c files to compile as
independent standalone objects via trace/beauty/Build, exporting their
formatting functions via beauty.h and env.h. Switch arch_errno_names.o
and syscalltbl.o assignments directly to perf-util-y and add an
unconditional top-level recursive kbuild hook (perf-util-y += trace/beauty/)
to compile them into libperf-util.a, resolving remote linkage for util/env.c,
util/bpf-trace-summary.c, and standalone python extensions.
3. Bridge private opaque references (struct trace) securely via accessors
trace__show_zeros() and trace__host(), avoiding header entanglements.
4. Consolidate all generator variables, script paths, and array generation
rules entirely out of Makefile.perf and place them directly inside the
exact local Build files where their output objects are compiled
(trace/beauty/Build and trace/beauty/tracepoints/Build), binding
prerequisites locally. Use directly inside
generator recipes to guarantee dynamic directory creation before script
redirection, and append across all rules to print
clean, standardized GEN ... file.c output during compilation.
5. Clean up clean target to recursively remove the generated directory
instead of relying on dozens of individual variables.
This unchokes the "prepare" target parallel barrier, allows make to evaluate
generation scripts purely locally where consumed, and flattens the tracepoint
formatting architecture.
Testing a parallel build (make -j28 all from scratch) shows improvements:
Before:
real 0m28.689s
user 2m38.490s
sys 0m30.148s
After:
real 0m27.642s
user 2m32.356s
sys 0m26.683s
So reclaiming ~9.6 seconds of raw CPU time and over 1 full second off
overall real-world build latency, by overlapping sub-make startup and
avoiding top-level double-parsing overhead.
Reviewed-by: Namhyung Kim <namhyung@kernel.org>
Assisted-by: Gemini:gemini-3.1-pro-preview
Signed-off-by: Ian Rogers <irogers@google.com>
Tested-by: James Clark <james.clark@linaro.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Alexandre Chartre <alexandre.chartre@oracle.com>
Cc: Alexandre Ghiti <alex@ghiti.fr>
Cc: Andrii Nakryiko <andrii@kernel.org>
Cc: Ankur Arora <ankur.a.arora@oracle.com>
Cc: Collin Funk <collin.funk1@gmail.com>
Cc: Costa Shulyupin <costa.shul@redhat.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Dapeng Mi <dapeng1.mi@linux.intel.com>
Cc: David Sterba <dsterba@suse.com>
Cc: Dmitrii Dolgov <9erthalion6@gmail.com>
Cc: Eduard Zingerman <eddyz87@gmail.com>
Cc: Howard Chu <howardchu95@gmail.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Cc: Leo Yan <leo.yan@arm.com>
Cc: Markus Mayer <mmayer@broadcom.com>
Cc: Martin KaFai Lau <martin.lau@linux.dev>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Terrell <terrelln@fb.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Paul Walmsley <pjw@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Quentin Monnet <qmo@kernel.org>
Cc: Ricky Ringler <ricky.ringler@proton.me>
Cc: Song Liu <song@kernel.org>
Cc: Swapnil Sapkal <swapnil.sapkal@amd.com>
Cc: Thomas Falcon <thomas.falcon@intel.com>
Cc: Tomas Glozar <tglozar@redhat.com>
Cc: Yonghong Song <yonghong.song@linux.dev>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
__cmd_contention() suffers from the same lost-wakeup race as the perf
sched stats paths: SIGCHLD can be consumed by the signal handler
before pause() is entered, hanging the process.
Apply the same fix: replace pause() with a loop checking the 'done'
flag and using waitpid(WNOHANG) for the workload case.
Suggested-by: Namhyung Kim <namhyung@kernel.org>
Assisted-by: Claude:claude-opus-4.6
Signed-off-by: Swapnil Sapkal <swapnil.sapkal@amd.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: James Clark <james.clark@linaro.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ravi Bangoria <ravi.bangoria@amd.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
perf_sched__schedstat_live() has the same lost-wakeup race as
perf_sched__schedstat_record(): a short-lived workload's SIGCHLD
can be consumed by the signal handler before pause() is entered,
hanging the process.
Apply the same fix: replace pause() with a loop checking the 'done'
flag and using waitpid(WNOHANG) for the workload case.
Suggested-by: Namhyung Kim <namhyung@kernel.org>
Assisted-by: Claude:claude-opus-4.6
Signed-off-by: Swapnil Sapkal <swapnil.sapkal@amd.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: James Clark <james.clark@linaro.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ravi Bangoria <ravi.bangoria@amd.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
If the profiled workload exits very quickly, SIGCHLD can be delivered
and consumed by the empty signal handler before the process enters
pause(), causing an indefinite hang.
Fix this with a simpler approach:
- The signal handler now sets a 'volatile sig_atomic_t done' flag.
Reset 'done' before registering signal handlers so that an early
signal during setup is not discarded by a later reset.
- Replace pause() with a loop that checks 'done' and uses
waitpid(WNOHANG) to detect child exit without blocking. This
handles both workload mode (child exits) and system-wide mode
(user sends SIGINT/SIGTERM). Using WNOHANG avoids the SA_RESTART
problem where a blocking waitpid() would auto-restart and ignore
the done flag if the child doesn't exit on signal.
Suggested-by: Namhyung Kim <namhyung@kernel.org>
Assisted-by: Claude:claude-opus-4.6
Signed-off-by: Swapnil Sapkal <swapnil.sapkal@amd.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: James Clark <james.clark@linaro.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ravi Bangoria <ravi.bangoria@amd.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
On modern Xeon platforms, such as Granite Rapids, Sierra Forest, and
Clearwater Forest, there are two flavors of requestable C6 states: C6
and C6P. C6 allows only core C6 (CC6), while C6P allows both CC6 and
package C6 (PC6). PC6 saves more power but also has a higher exit
latency, so many users disable it in BIOS.
When PC6 is disabled, C6P becomes identical to C6 — the CPU treats C6P
requests as C6 requests. Exposing both C6 and C6P to user space in this
situation is confusing: two states with the same name look different but
behave the same. It also adds unnecessary overhead to the cpuidle
subsystem, which is a fast path: the governor evaluates every registered
state on idle entry.
Drop C-states that are redundant when PC6 is disabled by marking them
with CPUIDLE_FLAG_UNUSABLE, which causes cpuidle to exclude them when
registering idle states.
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Link: https://patch.msgid.link/20260425072532.358365-5-dedekind1@gmail.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Introduce the skx_is_pc6_disabled() for checking if PC6 is disabled and
switch the following functions to use it:
- skx_idle_state_table_update()
- spr_idle_state_table_update()
At the same time, clean them up improving the commentary and moving it to
the function kernel-doc.
Purely a clean up, no functional changes intended.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Link: https://patch.msgid.link/20260425072532.358365-4-dedekind1@gmail.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Add two constants for the package C-state limit fields in
MSR_PKG_CST_CONFIG_CONTROL.
The SKX_ prefix stands for "Skylake Xeon" and makes it explicit that
the mask is CPU model-specific. The same values have applied to all
Xeon platforms starting from SKX.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Link: https://patch.msgid.link/20260425072532.358365-2-dedekind1@gmail.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
bt_accept_dequeue() unlinks a not-yet-accepted child from the parent
accept queue and release_sock()s it before returning, so the returned
sk has no caller reference and is unlocked.
l2cap_sock_cleanup_listen() walks these children on listening-socket
close. A concurrent HCI disconnect drives hci_rx_work ->
l2cap_conn_del() which runs l2cap_chan_del() + l2cap_sock_kill() and
frees the child sk and its l2cap_chan; cleanup_listen() then uses both:
BUG: KASAN: slab-use-after-free in l2cap_sock_kill
l2cap_sock_kill / l2cap_sock_cleanup_listen / __x64_sys_close
Freed by: l2cap_conn_del -> l2cap_sock_close_cb -> l2cap_sock_kill
This is distinct from the two fixes already in this area: commit
e83f5e24da ("Bluetooth: serialize accept_q access") serialises the
accept_q list/poll and takes temporary refs inside bt_accept_dequeue(),
and CVE-2025-39860 serialises the userspace close()/accept() race by
calling cleanup_listen() under lock_sock() in l2cap_sock_release().
Neither covers l2cap_conn_del() running from hci_rx_work, so this UAF
still reproduces on current bluetooth/master.
Take the reference at the source: bt_accept_dequeue() does sock_hold()
while sk is still locked, before release_sock(); callers sock_put().
cleanup_listen() pins the chan with l2cap_chan_hold_unless_zero() under
a brief child sk lock (serialising vs l2cap_sock_teardown_cb()), drops
it before l2cap_chan_lock(), and skips a duplicate l2cap_sock_kill() on
SOCK_DEAD. conn->lock is not taken here: cleanup_listen() runs under
the parent sk lock and that would invert
conn->lock -> chan->lock -> sk_lock (lockdep).
KASAN/SMP: an unprivileged listen/close vs HCI-disconnect race produced
12 use-after-free reports per run before this change; 0, and no lockdep
report, over 1600+ raced iterations after it on bluetooth/master.
Fixes: 15f02b9105 ("Bluetooth: L2CAP: Add initial code for Enhanced Credit Based Mode")
Cc: stable@vger.kernel.org
Reported-by: Siwei Zhang <oss@fourdim.xyz>
Reviewed-by: Siwei Zhang <oss@fourdim.xyz>
Signed-off-by: Safa Karakuş <safa.karakus@secunnix.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Vulnerabilities leading to Use-After-Free (UAF) and Null Pointer
Dereference (NPD) conditions were observed in the lifecycle management
of hci_uart.
The primary issue arises because the workqueues (init_ready and
write_work) are only flushed/cancelled if the HCI_UART_PROTO_READY
flag is set during TTY close. If a hangup occurs before setup completes,
hci_uart_tty_close() skips the teardown of these workqueues and
proceeds to free the `hu` struct. When the scheduled work executes
later, it blindly dereferences the freed `hu` struct.
Furthermore, several data races and UAFs were identified in the teardown
sequence:
1. Calling hci_uart_flush() from hci_uart_close() without effectively
disabling write_work causes a race condition where both can concurrently
double-free hu->tx_skb. This happens because protocol timers can
concurrently invoke hci_uart_tx_wakeup() and requeue write_work.
2. Calling hci_free_dev(hdev) before hu->proto->close(hu) causes a UAF
when vendor specific protocol close callbacks dereference hu->hdev.
3. In the initialization error paths, failing to take the proto_lock
write lock before clearing PROTO_READY leads to races with active
readers. Additionally, hci_uart_tty_receive() accesses hu->hdev
outside the read lock, leading to UAFs if the initialization error
path frees hdev concurrently.
Fix these synchronization and lifecycle issues by:
1. Re-ordering hci_uart_tty_close() to clear HCI_UART_PROTO_READY first,
followed immediately by a cancel_work_sync(&hu->write_work). Clearing
the flag locks out concurrent protocol timers from successfully invoking
hci_uart_tx_wakeup(), effectively rendering the cancellation permanent
and preventing the tx_skb double-free.
2. Note: Clearing PROTO_READY early causes hci_uart_close() to skip
hu->proto->flush(). This is perfectly safe in the tty_close path
because hu->proto->close() executes shortly after, which intrinsically
purges all protocol SKB queues and tears down the state.
3. Relocating hu->proto->close(hu) strictly prior to hci_free_dev(hdev)
across all close and error paths to prevent vendor-level UAFs.
4. Moving the hdev->stat.byte_rx increment in hci_uart_tty_receive()
inside the proto_lock read-side critical section to safely synchronize
with device unregistration.
5. Adding cancel_work_sync(&hu->write_work) to hci_uart_close() to safely
flush the workqueue before hci_uart_flush() is invoked via the HCI core.
6. Utilizing cancel_work_sync() instead of disable_work_sync() across
all paths to prevent permanently breaking user-space retry capabilities.
Fixes: 3b799254cf ("Bluetooth: hci_uart: Cancel init work before unregistering")
Cc: stable@vger.kernel.org
Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
MGMT_OP_ADD_EXT_ADV_DATA is registered as a variable-length command,
with MGMT_ADD_EXT_ADV_DATA_SIZE as the fixed header size. The handler
then uses cp->adv_data_len and cp->scan_rsp_len to validate and copy
cp->data, but it never checks that those bytes are part of the mgmt
command payload.
A short command can therefore make add_ext_adv_data() pass an
out-of-bounds pointer into tlv_data_is_valid(). If the bytes beyond
the command buffer are addressable, they can also be copied into the
advertising instance as scan response data, where the caller can read
them back via MGMT_OP_GET_ADV_INSTANCE. The trigger requires
CAP_NET_ADMIN in the initial user namespace; KASAN reports an 8-byte
slab-out-of-bounds read.
Reject commands whose length does not match the fixed header plus both
advertising data lengths before parsing cp->data.
Fixes: 1241057283 ("Bluetooth: Break add adv into two mgmt commands")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4-7
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
The setup_packet of control urb is not freed if usb_submit_urb fails or
the submitted urb is killed. Add free in these two paths.
Fixes: a1c49c434e ("Bluetooth: btusb: Add protocol support for MediaTek MT7668U USB devices")
Signed-off-by: Jiajia Liu <liujiajia@kylinos.cn>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
ISO data PDUs carry a packet-boundary flag indicating START, CONT, END
or SINGLE. The ISO_CONT branch of iso_recv() guards against a missing
ISO_START by checking conn->rx_len before touching conn->rx_skb, but
ISO_END does not.
If a peer sends an ISO_END as the first packet on a fresh ISO
connection, conn->rx_skb is still NULL and conn->rx_len is zero, so
skb_put(conn->rx_skb, ...) dereferences NULL and oopses. For BIS,
where receivers sync to a broadcaster without pairing, any broadcaster
on the air can trigger this.
Mirror the ISO_CONT check at the top of ISO_END so a stray end fragment
is logged and dropped instead of crashing the host.
Fixes: ccf74f2390 ("Bluetooth: Add BTPROTO_ISO socket type")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4-7
Signed-off-by: David Carlier <devnexen@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
btintel_pcie_get_mac_access() and btintel_pcie_release_mac_access()
were programming STOP_MAC_ACCESS_DIS and XTAL_CLK_REQ in addition to
the MAC_ACCESS_REQ handshake. These bits are not part of the host
MAC-access handshake on the supported parts; the driver was
programming them incorrectly. Drop the writes so the register update
contains only the bits the controller actually consumes.
Fixes: b9465e6670 ("Bluetooth: btintel_pcie: Read hardware exception data")
Signed-off-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This fixes not setting the bit for HCI_EVT_LE_ALL_REMOTE_FEATURES_COMPLETE
when extended features bit is set otherwise the controller may not
generate HCI_EVT_LE_ALL_REMOTE_FEATURES_COMPLETE causing
hci_le_read_all_remote_features_sync to timeout waiting for it.
Also remove dead code.
Fixes: a106e50be7 ("Bluetooth: HCI: Add support for LL Extended Feature Set")
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
bnep_add_connection() needs to keep holding the bnep_session_sem while
reading dev->name (just like bnep_get_connlist() does); otherwise the
bnep_session() thread can concurrently free the net_device, which can for
example be triggered by a concurrent bnep_del_connection().
(This UAF is fairly uninteresting from a security perspective;
calling bnep_add_connection() requires passing a capable(CAP_NET_ADMIN)
check. It also requires completely tearing down a netdev during a fairly
tight race window.)
Cc: stable@vger.kernel.org
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Dump the saved IRQ stack trace regardless of whether the event was
THREAD_CONTEXT or THREAD_URET.
In the uret case, the latency presumably had not yet crossed the
threshold at IRQ time (or else it would have dumped the stack at thread
wakeup time, unless we're racing with a change to the threshold), but it
may have at least contributed -- and this is possible with THREAD_CONTEXT
as well.
In any case, it helps with writing reliable rtla tests if we always get
a stack trace on a threshold event.
Cc: John Kacur <jkacur@redhat.com>
Cc: Tomas Glozar <tglozar@redhat.com>
Cc: Costa Shulyupin <costa.shul@redhat.com>
Cc: Wander Lairson Costa <wander@redhat.com>
Link: https://patch.msgid.link/20260511223143.1477332-1-crwood@redhat.com
Signed-off-by: Crystal Wood <crwood@redhat.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Certain drivers release resources (pinned pages, etc.) into system
memory during the prepare freeze PM op, making them swappable.
Currently, hibernate_preallocate_memory() is called before prepare
freeze, so those drivers have no opportunity to release resources
first. If a driver is holding a large amount of unswappable system
RAM, this can cause hibernate_preallocate_memory() to fail.
Move the call to hibernate_preallocate_memory() after prepare freeze.
According to the documentation for the prepare callback, devices should
be left in a usable state, so storage drivers should still be able to
service I/O requests. This allows drivers to release unswappable
resources prior to preallocation, so they can be swapped out through
hibernate_preallocate_memory()'s reclaim path.
Also remove shrink_shmem_memory() since hibernate_preallocate_memory()
will have reclaimed enough memory for the hibernation image.
Signed-off-by: Matthew Leach <matthew.leach@collabora.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
[ rjw: Subject and changelog tweaks ]
Link: https://patch.msgid.link/20260403-hibernation-fixes-v3-1-31bc9fa3ba2d@collabora.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
hist_field_name() returns "" everywhere except the fully-qualified
VAR_REF/EXPR case, where snprintf() truncation returns NULL early
and bypasses the bottom NULL->"" guard. Callers don't expect NULL:
strcat(expr, hist_field_name(field, 0)) at trace_events_hist.c:1758
and the strcmp() in the sort-key match loop at :4804 both deref it.
system and event_name are bounded by MAX_EVENT_NAME_LEN, but the
field name on a VAR_REF is kstrdup'd from a histogram variable
name parsed out of the trigger string and has no length cap, so
a long enough var name in a fully qualified reference can reach
the truncation path.
Keep the length check but leave field_name as "" on overflow.
Link: https://patch.msgid.link/20260508195747.25492-1-devnexen@gmail.com
Fixes: 5ec1d1e97d ("tracing: Rebuild full_name on each hist_field_name() call")
Signed-off-by: David Carlier <devnexen@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Given how rbd_lock_add_request() and rbd_img_exclusive_lock() are
written, lock_dwork may be (re)queued more than it's actually needed:
for example in case a new I/O request comes in while we are in the
middle of rbd_acquire_lock() on behalf of another I/O request. This is
expected and with rbd_release_lock() preemptively canceling lock_dwork
is benign under normal operation.
A more problematic example is maybe_kick_acquire():
if (have_requests || delayed_work_pending(&rbd_dev->lock_dwork)) {
dout("%s rbd_dev %p kicking lock_dwork\n", __func__, rbd_dev);
mod_delayed_work(rbd_dev->task_wq, &rbd_dev->lock_dwork, 0);
}
It's not unrealistic for lock_dwork to get canceled right after
delayed_work_pending() returns true and for mod_delayed_work() to
requeue it right there anyway. This is a classic TOCTOU race.
When it comes to unmapping the image, there is an implicit assumption
of no self-initiated exclusive lock activity past the point of return
from rbd_dev_image_unlock() which unlocks the lock if it happens to be
held. This unlock is assumed to be final and lock_dwork (as well as
all other exclusive lock tasks, really) isn't expected to get queued
again. However, lock_dwork is canceled only in cancel_tasks_sync()
(i.e. later in the unmap sequence) and on top of that the cancellation
can get in effect nullified by maybe_kick_acquire(). This may result
in rbd_acquire_lock() executing after rbd_dev_device_release() and
rbd_dev_image_release() run and free and/or reset a bunch of things.
One of the possible failure modes then is a violated
rbd_assert(rbd_image_format_valid(rbd_dev->image_format));
in rbd_dev_header_info() which is called via rbd_dev_refresh() from
rbd_post_acquire_action().
Redo exclusive lock task draining to provide saner semantics and try
to meet the assumptions around rbd_dev_image_unlock().
Cc: stable@vger.kernel.org
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
This SoC is used in low end LTE-to-WiFi routers, for example some D-Link
DWR 932 revisions, ZTE K10, ZLT S10 4G, but also models that are branded
and sold by ISPs themselves. They are widespread in Africa, China,
Russia and Eastern Europe.
This SoC is a relative of the zx296702 and zx296718 that had some
upstream support until commit 89d4f98ae9 ("ARM: remove zte zx
platform").
-----BEGIN PGP SIGNATURE-----
iQJPBAABCAA5FiEEQxb0tqoFWyeVMl1sPRO8yFRPGiIFAmoE5oYbFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMiwyAAoJED0TvMhUTxoiccEQAJDZWGRlilY5Ak6J80zX
ytrg0Go5zTN17IK6If6Ouk5j9+zDwlxrKn3vpRPUO9n7rT/1lw7CtfVusXufDip4
q4vkNWIkf23S48VjA/De+89IBwRI1vbSeyoePOCgi+MsM5IcxfcQqTjnmoe7tUDd
6OsyiLL8vZ/ZgnfoBfDdx6FguXvT+vwY4flPvGnG53etBmc0PNPF2h1JEkFelqwI
fDk/zg0SF96gUec5j/NOPycgqNQw2c3x6g6QgWmpWcRZvL0V9KRlgURJoSz9sl/4
5FnQNJwAsSUVwh56Mgw+HeyPy3bv+RZjkKArLs3ilCpZCHVYTqqQA6Nt0XEDuhjX
K3ajKxEejRm8lCCa1Mv55MbLN9mq9GPM6+uF5KrRClAhSGhjcE/tykZwN2KCyTip
oltp6qdE2IspLMy0DOj1rYZ0zbZ0DoZaPR9AAwjS2o8ig4uNZq8Vnd79kWGVVtco
S9ko4dCicmcgp4WdRK21/LVqil3Tnrav1unscv3RZem/pbQo0NFy+tNkbeLIInaK
9hiZjEMo67bnPPtjLB0pO5zYVVf+OKfSteppKp07jqYPKIAejeTNweCNggSQPKGc
8fsqBeCqtRzxxfiVX7OeF1UVvWMuq8NJP4It3reMvkckFlb9GrFhK+uE4q4x1cCZ
oDAQ6B7EyOxEy9DT8GDuIhtJ
=64Pq
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmoOFB0ACgkQmmx57+YA
GNndYRAAmaW2Mh5dOw2s+XmEQgcyoQJz8ULuOjUxl4totOrR+dEeGHNP/4hNbfX1
GNpinW351APW4cONjPSa52J+9OfwnfRjpVLOZcgs9hLqm2MVwDCBB7eI81etqs5o
/xEbKZi3m+5L2Iif74fn+c9qrDKEqKI8lpvzdxc9/OMAyPCoqqXSnGnC6yp8hXe5
X1ynjjrBDN+y99H7w0VbXoM2PBnWDwYCwyl5wHv1k207p1w7PFKcpQFloAWrnLr3
t4MpGcTrc3ewe+jflGzfEnVTwV77I+wZ0vxnSJRZu2hpgwkfN/nyjGSrTZtu+9VY
uEIfkZqlUY0R629DDZTOnVE2IRp6+hZ7dBGifcwO1hcw5JnslFVYPmAXtfs8FIRw
yU5ZZkYXbQ36RFonf7oTcgyFYICvGBTfde8k2N6ZXeW4wxzrnyKM6LlAVljnfg9R
dMl+MxfN6bm9AHHtK85hcbQttX/XwA81v/bYLpAAAkh42auljQNHuy01dt5+dV3G
QZaN7zUdb2IoL79KpeMm6fn7F8iEfthx0tNEZQDmhGa10ou3PgmJri9LZJQwyXqF
7V668dU+K+hB28zBQVMKvOJmYBI9OxmQdNCSx/ehKwIS08yU3rhbIZ7XU50dhtjD
1m2V636kziAxg7Our516ckCE/BaFLolXF0ZpPZiEN4bkw9pgouw=
=+qtN
-----END PGP SIGNATURE-----
Merge tag 'zx29-plat-for-7.2' of https://gitlab.com/stefandoesinger/zx297520-kernel into soc/arm
ARM: zte: Add zx297520v3 platform support
This SoC is used in low end LTE-to-WiFi routers, for example some D-Link
DWR 932 revisions, ZTE K10, ZLT S10 4G, but also models that are branded
and sold by ISPs themselves. They are widespread in Africa, China,
Russia and Eastern Europe.
This SoC is a relative of the zx296702 and zx296718 that had some
upstream support until commit 89d4f98ae9 ("ARM: remove zte zx
platform").
* tag 'zx29-plat-for-7.2' of https://gitlab.com/stefandoesinger/zx297520-kernel:
ARM: zte: Add zx297520v3 platform support
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
A number of fixes to the dynamic epp feature which was new
to kernel 7.1, including making it opt in only.
-----BEGIN PGP SIGNATURE-----
iQJHBAABCgAxFiEECwtuSU6dXvs5GA2aLRkspiR3AnYFAmoF0zkTHHN1cGVybTFA
a2VybmVsLm9yZwAKCRAtGSymJHcCdtBKEACyCL9xIVkFeall/cac9FzX7BbRYN6T
fW+2CLOep12rgtmBeAfC0yZ6pD173SVfhp71KzsrG0u00VgjGiO1+3BhE6dSFYOx
aPNSi/iCT2CAR9oMRSQDngeE9H/Ou7KafPVAEIiBSHVLKTnX5rmxuAko9Qp6VfGM
rE4L8BW6GwlDs9JDfs0QLafTHlM6VCOjWx5SxTN8eqY9wkfas/ahpb4V3OVny3v+
KiKU1720HQsynkiWWZK+IGOOubmo9o/mwdFQRVhnuxv3D0rrRe+PRR9DGgio+t3b
lSt3VCP4NuvDMelNHr+T4QoGIWCpGP5LQbLUN+LVGjFOUM2Zo/GXm2prUejatnWw
StmUVleRVzDfseXOfl30B6ImX4rC4f3d74lQ4pI/c7vDTRgSHJhLfYzNRuc324T5
XsSrWnqTK4vN/RWQED89DDqTnI4vWTaY5Z4h5kmbGzZa4dQ88d8ydHRxiq9u3Bcl
mpqEvTgoYJCpT2Xv91OjcQ4vcRjmtpsB93FOyY6WBHwoadfBjXv4UAcuOpCxDt9N
qlGeBrYZvv822aaTsRJBvEJj9bwpDrLcoJNLpeQN6EL/LY1YwxIPiGQHOIrlf0iJ
9ChLfR0gutkUBwW7djwubza8CSoNs4N5KsU4rRGjzaL3T2yy2tZB639HRw1ErRoL
YWzf3jYNLYG2mw==
=TNUP
-----END PGP SIGNATURE-----
Merge tag 'amd-pstate-v7.1-2026-05-14' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/superm1/linux into pm-cpufreq-fixes
Merge amd-pstate fixes for 7.1 (05/14/2026) from Mario Limonciello:
"A number of fixes to the dynamic epp feature which was new
to kernel 7.1, including making it opt in only."
* tag 'amd-pstate-v7.1-2026-05-14' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/superm1/linux:
cpufreq/amd-pstate: Drop Kconfig option for dynamic EPP
cpufreq/amd-pstate-ut: Drop policy reference before driver switch
cpufreq/amd-pstate: Use "epp_default_dc" as default when dynamic_epp is disabled
cpufreq/amd-pstate: Reorder notifier unregistration and floor perf reset
cpufreq/amd-pstate: Allow writes to dynamic_epp when state isn't modified
cpufreq/amd-pstate: Return -ENOMEM on failure to allocate profile_name
cpufreq/amd-pstate: Grab "amd_pstate_driver_lock" when toggling dynamic_epp
Commit 36df6e3dbd ("cgroup: make css_rstat_updated nmi safe") used
this_cpu_cmpxchg() for the lockless insertion, and therefore required
both ARCH_HAVE_NMI_SAFE_CMPXCHG and ARCH_HAS_NMI_SAFE_THIS_CPU_OPS in
the NMI guard: on archs without the latter, this_cpu_cmpxchg() falls
back to "local_irq_save() + plain cmpxchg", and local_irq_save()
cannot mask NMIs.
Commit 3309b63a22 ("cgroup: rstat: use LOCK CMPXCHG in
css_rstat_updated") later replaced this_cpu_cmpxchg() with plain
try_cmpxchg() to fix cross-CPU lockless-list corruption, but left the
NMI guard untouched. After that switch, css_rstat_updated() no longer
performs any this_cpu_*() RMW operations and only relies on the arch
having NMI-safe cmpxchg, so ARCH_HAS_NMI_SAFE_THIS_CPU_OPS is no
longer required in the guard.
Relax the guard accordingly so that archs which have HAVE_NMI and
ARCH_HAVE_NMI_SAFE_CMPXCHG but not ARCH_HAS_NMI_SAFE_THIS_CPU_OPS
(e.g. sparc, powerpc on PPC64/BOOK3S) can benefit from the existing
CONFIG_MEMCG_NMI_SAFETY_REQUIRES_ATOMIC path. Without this, the css
is never queued in NMI on those archs, and the atomics staged by
account_{slab,kmem}_nmi_safe() are not drained by flush_nmi_stats().
Fixes: 3309b63a22 ("cgroup: rstat: use LOCK CMPXCHG in css_rstat_updated")
Signed-off-by: Cunlong Li <shenxiaogll@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Prevent out-of-bounds memory reads when parsing corrupted or maliciously crafted
perf.data files by introducing robust bounds validation to raw data accessors.
- Add a helper out_of_bounds() to check if field offsets and sizes exceed the
sample's raw_size boundary, preventing heap read overflows.
- In perf_sample__rawptr(), properly resolve newer relative dynamic tracepoint
fields (__rel_loc) by checking the boundaries before and after reading the
dynamic field descriptor.
- Byte-swap dynamic field offsets and sizes dynamically when endianness varies,
ensuring cross-endian parsing is robust.
Signed-off-by: Ian Rogers <irogers@google.com>
Acked-by: Namhyung Kim <namhyung@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Alexandre Ghiti <alex@ghiti.fr>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Andrew Jones <ajones@ventanamicro.com>
Cc: Anup Patel <anup@brainfault.org>
Cc: Athira Rajeev <atrajeev@linux.ibm.com>
Cc: Blake Jones <blakejones@google.com>
Cc: Chen Ni <nichen@iscas.ac.cn>
Cc: Chun-Tse Shao <ctshao@google.com>
Cc: Dapeng Mi <dapeng1.mi@linux.intel.com>
Cc: Derek Foreman <derek.foreman@collabora.com>
Cc: Dmitriy Vyukov <dvyukov@google.com>
Cc: Dr. David Alan Gilbert <linux@treblig.org>
Cc: Howard Chu <howardchu95@gmail.com>
Cc: Hrishikesh Suresh <hrishikesh123s@gmail.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: James Clark <james.clark@linaro.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Krzysztof Łopatowski <krzysztof.m.lopatowski@gmail.com>
Cc: Leo Yan <leo.yan@arm.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Paul Walmsley <pjw@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Quan Zhou <zhouquan@iscas.ac.cn>
Cc: Ravi Bangoria <ravi.bangoria@amd.com>
Cc: Swapnil Sapkal <swapnil.sapkal@amd.com>
Cc: Thomas Falcon <thomas.falcon@intel.com>
Cc: Tianyou Li <tianyou.li@intel.com>
Cc: Yujie Liu <yujie.liu@intel.com>
Cc: tanze <tanze@kylinos.cn>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Prevent out-of-bounds writes/reads in CPU state tracking arrays by enforcing
strict MAX_CPUS bounds checks in timechart's tracepoint handlers.
Ensure that cpu_id retrieved from idle/frequency and sched tracepoints is less
than MAX_CPUS before indexing into cpus_cstate_state, cpus_cstate_start_times,
and similar tracking arrays. Also, fix an off-by-one error in the CPU iteration
loop inside end_sample_processing() by changing the loop condition from
'cpu <= tchart->numcpus' to 'cpu < tchart->numcpus'.
Signed-off-by: Ian Rogers <irogers@google.com>
Acked-by: Namhyung Kim <namhyung@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Alexandre Ghiti <alex@ghiti.fr>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Andrew Jones <ajones@ventanamicro.com>
Cc: Anup Patel <anup@brainfault.org>
Cc: Athira Rajeev <atrajeev@linux.ibm.com>
Cc: Blake Jones <blakejones@google.com>
Cc: Chen Ni <nichen@iscas.ac.cn>
Cc: Chun-Tse Shao <ctshao@google.com>
Cc: Dapeng Mi <dapeng1.mi@linux.intel.com>
Cc: Derek Foreman <derek.foreman@collabora.com>
Cc: Dmitriy Vyukov <dvyukov@google.com>
Cc: Dr. David Alan Gilbert <linux@treblig.org>
Cc: Howard Chu <howardchu95@gmail.com>
Cc: Hrishikesh Suresh <hrishikesh123s@gmail.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: James Clark <james.clark@linaro.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Krzysztof Łopatowski <krzysztof.m.lopatowski@gmail.com>
Cc: Leo Yan <leo.yan@arm.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Paul Walmsley <pjw@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Quan Zhou <zhouquan@iscas.ac.cn>
Cc: Ravi Bangoria <ravi.bangoria@amd.com>
Cc: Swapnil Sapkal <swapnil.sapkal@amd.com>
Cc: Thomas Falcon <thomas.falcon@intel.com>
Cc: Tianyou Li <tianyou.li@intel.com>
Cc: Yujie Liu <yujie.liu@intel.com>
Cc: tanze <tanze@kylinos.cn>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
