The ethnl_pse_send_ntf() stub function has incorrect parameter type when
CONFIG_ETHTOOL_NETLINK is disabled. The function should take a net_device
pointer instead of phy_device pointer to match the actual implementation.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202506200355.TqFiYUbN-lkp@intel.com/
Fixes: fc0e6db309 ("net: pse-pd: Add support for reporting events")
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20250620091641.2098028-1-kory.maincent@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Instead of crashing the kernel, a warning and graceful return is better.
[1] https://lore.kernel.org/all/aEnVuzK7VhGSizWj@pc636/
Uladzislau Rezki (Sony) (1):
rcu: Return early if callback is not specified
kernel/rcu/tree.c | 4 ++++
1 file changed, 4 insertions(+)
-----BEGIN PGP SIGNATURE-----
iQJKBAABCgA0FiEEcoCIrlGe4gjE06JJqA4nf2o45hAFAmhVuzAWHGpvZWxhZ25l
bGZAbnZpZGlhLmNvbQAKCRCoDid/ajjmEEIkD/96Thn+TWnz4hOu9F39YIbtsqC3
4K+T2CFHmu4gBdUmXSadSSSShjDZgwwD9iLLWw/tmCyOS39Mkoh22x8bxWAy0KM1
A36hR3sgyl+OE4m+u+o8kJxFMHMrsLXt8L/wKIT9jf/VbqkI4VMpgwfTCjz8ySFc
FuujXT0QwkS2+1BtP9n19OJdyJ3vUQy6vNsk3RbEUpmBdMvADpYskWwJqTFd7hMc
b1PYtsIn+0cB4qQfGcC2qtLRQAYdegg+No3VnrmFPYsfMmnG0kKl8+E/L7ts8hGJ
1nYs3Sqhql8Q6y68KOUp0PD6qVWJHL22jNKCzieNB8vV2Y7PkVr0VKmvDSNAGCsC
pUsPLUjQIVMpu/k6ZM8iiaQN0vZ8C7yRUFHJqeREy/t1rpnq39x4ObhPkAzj1dCl
IYMv6M03IzMzUQa1sZMJ5eCZWmtIbd2/1hDE02fK8EE/MBiyCPQgpAKZ/bGzJtOZ
HgYzAhATX4tEdjj8m5Uk6F517VGp3hUs/3nn6TrGUW64SdqLp6WWd2nMBpLz1JrA
BAXVliYhoI94X9Zlc/ecd+CefN2Bu/DgbYa6uO7i7/c1w/4FIG/oDVqdUoobwoDI
WoQ/O/hUCh/ltO/UMmxwDbvWdmRH4iQ2Tpt8TXvLuo2El1tQda1VErexqArylOvw
FG9sXft2miCQjOx9Ng==
=PVd7
-----END PGP SIGNATURE-----
Merge tag 'rcu/fixes-for-6.16-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rcu/linux
Pull RCU fix from Joel Fernandes:
"We recently got a report of a crash [1] with misuse of call_rcu().
Instead of crashing the kernel, a warning and graceful return is
better:
- rcu: Return early if callback is not specified (Uladzislau Rezki)"
Link: https://lore.kernel.org/all/aEnVuzK7VhGSizWj@pc636/ [1]
* tag 'rcu/fixes-for-6.16-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rcu/linux:
rcu: Return early if callback is not specified
- Fix some file descriptor leaks that stand out with recent changes to
'perf list'.
- Fix prctl include to fix building 'perf bench futex' hash with musl libc.
- Restrict 'perf test' uniquifying entry to machines with 'uncore_imc' PMUs.
- Document new output fields (op, cache, mem, dtlb, snoop) used with
'perf mem'.
- Synchronize kernel header copies.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQR2GiIUctdOfX2qHhGyPKLppCJ+JwUCaFWAEwAKCRCyPKLppCJ+
J0/LAP46WdlK1T49um790QowJR+HqRQEngur6ZIb8ya0FpCc4AEAnv8KdGdeoF21
H403o3fbCaMGN5ZQ4loe3IEO9gh6EAY=
=9GzE
-----END PGP SIGNATURE-----
Merge tag 'perf-tools-fixes-for-v6.16-1-2025-06-20' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools
Pull perf tools fixes from Arnaldo Carvalho de Melo:
- Fix some file descriptor leaks that stand out with recent changes to
'perf list'
- Fix prctl include to fix building 'perf bench futex' hash with musl
libc
- Restrict 'perf test' uniquifying entry to machines with 'uncore_imc'
PMUs
- Document new output fields (op, cache, mem, dtlb, snoop) used with
'perf mem'
- Synchronize kernel header copies
* tag 'perf-tools-fixes-for-v6.16-1-2025-06-20' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools:
tools headers x86 cpufeatures: Sync with the kernel sources
perf bench futex: Fix prctl include in musl libc
perf test: Directory file descriptor leak
perf evsel: Missed close() when probing hybrid core PMUs
tools headers: Synchronize linux/bits.h with the kernel sources
tools arch amd ibs: Sync ibs.h with the kernel sources
tools arch x86: Sync the msr-index.h copy with the kernel sources
tools headers: Syncronize linux/build_bug.h with the kernel sources
tools headers: Update the copy of x86's mem{cpy,set}_64.S used in 'perf bench'
tools headers UAPI: Sync linux/kvm.h with the kernel sources
tools headers UAPI: Sync the drm/drm.h with the kernel sources
perf beauty: Update copy of linux/socket.h with the kernel sources
tools headers UAPI: Sync kvm header with the kernel sources
tools headers x86 svm: Sync svm headers with the kernel sources
tools headers UAPI: Sync KVM's vmx.h header with the kernel sources
tools kvm headers arm64: Update KVM header from the kernel sources
tools headers UAPI: Sync linux/prctl.h with the kernel sources to pick FUTEX knob
perf mem: Document new output fields (op, cache, mem, dtlb, snoop)
tools headers: Update the fs headers with the kernel sources
perf test: Restrict uniquifying test to machines with 'uncore_imc'
Jakub Kicinski says:
====================
eth: finish migration to the new RXFH callbacks
Finish drivers conversions to callbacks added by
commit 9bb00786fc ("net: ethtool: add dedicated callbacks for
getting and setting rxfh fields"). Remove the conditional calling
in the core, rxnfc callbacks are no longer used for RXFH.
====================
Link: https://patch.msgid.link/20250618203823.1336156-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
All drivers have been converted. Stop using the rxnfc fallbacks
for Rx Flow Hashing configuration.
Joe pointed out in earlier review that in ethtool_set_rxfh()
we need both .get_rxnfc and .get_rxfh_fields, because we need
both the ring count and flow hashing (because we call
ethtool_check_flow_types()). IOW the existing check added
for transitioning drivers was buggy.
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20250618203823.1336156-11-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Migrate to new callbacks added by commit 9bb00786fc ("net: ethtool:
add dedicated callbacks for getting and setting rxfh fields").
Zeroing data on SET is not necessary, the argument is not copied
back to user space. The driver has no other RXNFC functionality
so the SET callback can be now removed.
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20250618203823.1336156-9-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Migrate to new callbacks added by commit 9bb00786fc ("net: ethtool:
add dedicated callbacks for getting and setting rxfh fields").
Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
Link: https://patch.msgid.link/20250618203823.1336156-7-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Migrate to new callbacks added by commit 9bb00786fc ("net: ethtool:
add dedicated callbacks for getting and setting rxfh fields").
The driver has no other RXNFC functionality so the SET callback can
be now removed.
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20250618203823.1336156-5-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Migrate to new callbacks added by commit 9bb00786fc ("net: ethtool:
add dedicated callbacks for getting and setting rxfh fields").
This driver's RXFH config is read only / fixed so the conversion
is purely factoring out the handling into a helper. One thing of
note that this is one of the two drivers which pays attention to
rss_context.
Reviewed-by: Edward Cree <ecree.xilinx@gmail.com>
Link: https://patch.msgid.link/20250618203823.1336156-4-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Migrate to new callbacks added by commit 9bb00786fc ("net: ethtool:
add dedicated callbacks for getting and setting rxfh fields").
This driver's RXFH config is read only / fixed so the conversion
is purely factoring out the handling into a helper.
Reviewed-by: Edward Cree <ecree.xilinx@gmail.com>
Link: https://patch.msgid.link/20250618203823.1336156-3-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Migrate to new callbacks added by commit 9bb00786fc ("net: ethtool:
add dedicated callbacks for getting and setting rxfh fields").
This driver's RXFH config is read only / fixed so the conversion
is purely factoring out the handling into a helper.
Reviewed-by: Edward Cree <ecree.xilinx@gmail.com>
Link: https://patch.msgid.link/20250618203823.1336156-2-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Use netmem_dma_*() helpers and declare netmem_tx to support netmem TX.
By this change, all bnxt devices will support the netmem TX.
Unreadable skbs are not going to be handled by the TX push logic.
So, it checks whether a skb is readable or not before the TX push logic.
netmem TX can be tested with ncdevmem.c
Acked-by: Mina Almasry <almasrymina@google.com>
Acked-by: Stanislav Fomichev <sdf@fomichev.me>
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Reviewed-by: Michael Chan <michael.chan@broadcom.com>
Link: https://patch.msgid.link/20250619144058.147051-1-ap420073@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The rcar_canfd_f_*() inline functions to obtain channel-specific CAN-FD
register offsets really describe a memory layout. Hence replace them by
a C structure, to simplify the code, and reduce kernel size.
This also gets rid of warnings about unused rcar_canfd_f_*() inline
functions, which are reported by recent versions of clang.
Suggested-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Reported-by: Jakub Kicinski <kuba@kernel.org>
Closes: https://lore.kernel.org/20250618183827.5bebca8f@kernel.org
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Link: https://patch.msgid.link/292b75b3bc8dd95f805f0223f606737071c8cf86.1750327217.git.geert+renesas@glider.be
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Simon Horman says:
====================
rds: Minor updates for spelling and endian
This short series addressses some cosmetic issues in rds.
1. Some spelling errors, as flagged by spellcheck
2. Some endianness annotation errors, which are not bugs,
flagged by Sparse
====================
Link: https://patch.msgid.link/20250619-rds-minor-v1-0-86d2ee3a98b9@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Correct spelling as flagged by codespell.
With these changes in place codespell only flags false positives
in net/rds.
Signed-off-by: Simon Horman <horms@kernel.org>
Reviewed-by: Allison Henderson <allison.henderson@oracle.com>
Link: https://patch.msgid.link/20250619-rds-minor-v1-2-86d2ee3a98b9@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Correct the endianness annotation of port assignments:
A host byte order value (RDS_TCP_PORT) is correctly converted to
network byte order (big endian) using htons. But it is then cast back to
host byte order before assigning to a variable that expects a big endian
value. Address this by dropping the cast.
This is not a bug because, while the endian annotation is changed by
this patch, the assigned value is unchanged.
Also correct the endianness of address assignment.
A host byte order value (INADDR_ANY) is incorrectly assigned as-is to
a variable that expects a big endian value. Address this by converting
the value to network byte order (big endian).
This is not a bug because INADDR_ANY is 0, which is isomorphic
with regards to endian conversions. IOW, while the endian annotation
is changed by this patch, the assigned value is unchanged.
Incorrect endian annotations appear to date back to IPv4-only code added
by commit 70041088e3 ("RDS: Add TCP transport to RDS").
Flagged by Sparse.
Signed-off-by: Simon Horman <horms@kernel.org>
Reviewed-by: Allison Henderson <allison.henderson@oracle.com>
Link: https://patch.msgid.link/20250619-rds-minor-v1-1-86d2ee3a98b9@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
I'm retiring and have already had my name removed from MAINTAINERS.
A couple of folks kindly suggested I should have an entry here.
Signed-off-by: Shannon Nelson <sln@onemain.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20250619211607.1244217-1-sln@onemain.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Joshua Washington says:
====================
gve: XDP TX and redirect support for DQ RDA
A previous patch series[1] introduced the ability to process XDP buffers
to the DQ RDA queue format. This is a follow-up patch series to
introduce XDP_TX and XDP_REDIRECT support and expose XDP support to the
kernel.
Link: https://git.kernel.org/netdev/net-next/c/e2ac75a8a967 [1]
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch adds support for XDP_TX and XDP_REDIRECT for the DQ RDA
queue format. To appropriately support transmission of XDP frames, a
new pending packet type GVE_TX_PENDING_PACKET_DQO_XDP_FRAME is
introduced for completion handling, as there was a previous assumption
that completed packets would be SKBs.
XDP_TX handling completes the basic XDP actions, so the feature is
recorded accordingly. This patch also enables the ndo_xdp_xmit callback
allowing DQ to handle XDP_REDIRECT packets originating from another
interface.
The XDP spinlock is moved to common TX ring fields so that it can be
used in both GQ and DQ. Originally, it was in a section which was
mutually exclusive for GQ and DQ.
In summary, 3 XDP features are exposed for the DQ RDA queue format:
1) NETDEV_XDP_ACT_BASIC
2) NETDEV_XDP_ACT_NDO_XMIT
3) NETDEV_XDP_ACT_REDIRECT
Note that XDP and header-data split are mutually exclusive for the time
being due to lack of multi-buffer XDP support.
This patch does not add support for the DQ QPL format. That is to come
in a future patch series.
Reviewed-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: Praveen Kaligineedi <pkaligineedi@google.com>
Signed-off-by: Joshua Washington <joshwash@google.com>
Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch performs various minor DQO TX datapath refactors in
preparation for adding XDP_TX and XDP_REDIRECT support. The following
refactors are performed:
1) gve_tx_fill_pkt_desc_dqo() relies on a SKB pointer to
get whether checksum offloading should be enabled. This won't work
for the XDP case, which does not have a SKB. This patch updates the
method to use a boolean representing whether checksum offloading
should be enabled directly.
2) gve_maybe_stop_dqo() contains some synchronization between the true
TX head and the cached value, a synchronization which is common for
XDP queues and normal netdev queues. However, that method is reserved
for netdev TX queues. To avoid duplicate code, this logic is factored
out into a new method, gve_has_tx_slots_available().
3) gve_tx_update_tail() is added to update the TX tail, a functionality
that will be common between normal TX and XDP TX codepaths.
Reviewed-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: Joshua Washington <joshwash@google.com>
Signed-off-by: Praveen Kaligineedi <pkaligineedi@google.com>
Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In preparation for XDP DQ support, the gve_xdp_xmit callback needs to
be generalized for all queue formats. This patch renames the GQ-specific
function to gve_xdp_xmit_gqi, and introduces a new gve_xdp_xmit callback
which branches on queue format.
Reviewed-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: Joshua Washington <joshwash@google.com>
Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Similar to zboot architectures, implement support for embedding SBAT data
for x86. Put '.sbat' section in between '.data' and '.text' as the former
also covers '.bss' and '.pgtable' and thus must be the last one in the
file.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/20250603091951.57775-1-vkuznets@redhat.com
rvu_mbox_init function makes use of error path for
freeing memory which are local to the function in
both success and failure conditions. This is unusual hence
fix it by returning zero on success. With new cn20k code this
is freeing valid memory in success case also.
Fixes: e53ee4acb2 ("octeontx2-af: CN20k basic mbox operations and structures")
Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
adding the new mtd_master class, because it entirely fails the
partitioning if a specific Kconfig option is set. We need to think how
to handle that differently, so let's revert it as we need to get back to
the pen and paper situation again.
Otherwise the definition of some Winbond SPI NAND chips are receiving
some fixes (geometry and maximum frequency, mostly).
And finally a small memory leak gets also fixed.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEE9HuaYnbmDhq/XIDIJWrqGEe9VoQFAmhVfg0ACgkQJWrqGEe9
VoTa8wf7BaY8T+mpA6zbgou4LBNFiqcB+NkL8N4uFOaVsGQYQfb5SX6m1CKitD8y
oIbkwYZI7c2R3ZuQ8vj6PgKwbG7HJrmSfO5dbWoamNJ6cE2Y1rQFJUCyE98zrO/g
MsZBy2PjBM3q5YRwuA0YzzHWQec4bXpeQlxUhk+VYGW/2BJdROUzmLebPz7cuKKx
m+VVLdVEByu41JaLE9j3+ntfFnoY3Fp5DooheGCCEAdHEv+drfcbLv2TEiy9wyCv
LLhau6MPaBDgL0+VIZd91Lgys7stFYtbPBSlItRsdZ91mRIVt8AtJAA0k0t8lQGo
srb8eSEbTeIVFkJjGC43utY6mIic1A==
=5vwJ
-----END PGP SIGNATURE-----
Merge tag 'mtd/fixes-for-6.16-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux
Pull mtd fixes from Miquel Raynal:
"The main fix that really needs to get in is the revert of the patch
adding the new mtd_master class, because it entirely fails the
partitioning if a specific Kconfig option is set. We need to think how
to handle that differently, so let's revert it as we need to get back
to the pen and paper situation again.
Otherwise the definition of some Winbond SPI NAND chips are receiving
some fixes (geometry and maximum frequency, mostly).
And finally a small memory leak gets also fixed"
* tag 'mtd/fixes-for-6.16-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux:
mtd: spinand: fix memory leak of ECC engine conf
mtd: spinand: winbond: Prevent unsupported frequencies on dual/quad I/O variants
mtd: spinand: winbond: Increase maximum frequency on an octal operation
mtd: spinand: winbond: Fix W35N number of planes/LUN
Revert "mtd: core: always create master device"
Two small and obvious driver fixes.
Signed-off-by: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
-----BEGIN PGP SIGNATURE-----
iJwEABMIAEQWIQTnYEDbdso9F2cI+arnQslM7pishQUCaFVmPCYcamFtZXMuYm90
dG9tbGV5QGhhbnNlbnBhcnRuZXJzaGlwLmNvbQAKCRDnQslM7pishVihAP0f8k3/
yBL63Mu4H4PemV1Xx70lerRL9lFY/NqrcnZQQQEAmUTHB9Cdb1N3NiYOf0OmNYzd
BSUIL6zI5lW1aPb8xWY=
=2iYQ
-----END PGP SIGNATURE-----
Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"Two small and obvious driver fixes"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: elx: efct: Fix memory leak in efct_hw_parse_filter()
scsi: target: Fix NULL pointer dereference in core_scsi3_decode_spec_i_port()
From 077814f57f8acce13f91dc34bbd2b7e4911fbf25 Mon Sep 17 00:00:00 2001
From: Tejun Heo <tj@kernel.org>
Date: Fri, 13 Jun 2025 15:06:47 -1000
- Add CONFIG_GROUP_SCHED_BANDWIDTH which is selected by both
CONFIG_CFS_BANDWIDTH and EXT_GROUP_SCHED.
- Put bandwidth control interface files for both cgroup v1 and v2 under
CONFIG_GROUP_SCHED_BANDWIDTH.
- Update tg_bandwidth() to fetch configuration parameters from fair if
CONFIG_CFS_BANDWIDTH, SCX otherwise.
- Update tg_set_bandwidth() to update the parameters for both fair and SCX.
- Add bandwidth control parameters to struct scx_cgroup_init_args.
- Add sched_ext_ops.cgroup_set_bandwidth() which is invoked on bandwidth
control parameter updates.
- Update scx_qmap and maximal selftest to test the new feature.
Signed-off-by: Tejun Heo <tj@kernel.org>
More sched_ext fields will be added to struct task_group. In preparation,
factor out sched_ext fields into struct scx_task_group to reduce clutter in
the common header. No functional changes.
Signed-off-by: Tejun Heo <tj@kernel.org>
Pull sched_ext/for-6.16-fixes to receive:
c50784e99f ("sched_ext: Make scx_group_set_weight() always update tg->scx.weight")
33796b9187 ("sched_ext, sched/core: Don't call scx_group_set_weight() prematurely from sched_create_group()")
which are needed to implement CPU bandwidth control interface support.
Signed-off-by: Tejun Heo <tj@kernel.org>
Pull tip/sched/core to receive the following commits:
d403a3689a ("sched/fair: Move max_cfs_quota_period decl and default_cfs_period() def from fair.c to sched.h")
de4c80c696 ("sched/core: Relocate tg_get_cfs_*() and cpu_cfs_*_read_*()")
43e33f53e2 ("sched/core: Reorganize cgroup bandwidth control interface file reads")
5bc34be478 ("sched/core: Reorganize cgroup bandwidth control interface file writes")
These will be used to implement CPU bandwidth interface support in
sched_ext.
Signed-off-by: Tejun Heo <tj@kernel.org>
The '#reset-cells' property is permitted for some of the MT8188
clock controllers, but not listed as a valid property.
Fixes: 9a5cd59640 ("dt-bindings: clock: mediatek: Add SMI LARBs reset for MT8188")
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Julien Massot <julien.massot@collabora.com>
Link: https://lore.kernel.org/r/20250516-dtb-check-mt8188-v2-1-fb60bef1b8e1@collabora.com
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
This is an end-to-end test for the PERF_RECORD_BPF_METADATA support.
It adds a new "bpf_metadata_perf_version" variable to perf's BPF programs,
so that when they are loaded, there will be at least one BPF program with
some metadata to parse. The test invokes "perf record" in a way that loads
one of those BPF programs, and then sifts through the output to find its
BPF metadata.
Signed-off-by: Blake Jones <blakejones@google.com>
Link: https://lore.kernel.org/r/20250612194939.162730-6-blakejones@google.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
This collects metadata for any BPF programs that were loaded during a
"perf record" run, and emits it at the end of the run.
Signed-off-by: Blake Jones <blakejones@google.com>
Link: https://lore.kernel.org/r/20250612194939.162730-4-blakejones@google.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Look for .rodata maps, find ones with 'bpf_metadata_' variables, extract
their values as strings, and create a new PERF_RECORD_BPF_METADATA
synthetic event using that data. The code gets invoked from the existing
routine perf_event__synthesize_one_bpf_prog().
For example, a BPF program with the following variables:
const char bpf_metadata_version[] SEC(".rodata") = "3.14159";
int bpf_metadata_value[] SEC(".rodata") = 42;
would generate a PERF_RECORD_BPF_METADATA record with:
.prog_name = <BPF program name, e.g. "bpf_prog_a1b2c3_foo">
.nr_entries = 2
.entries[0].key = "version"
.entries[0].value = "3.14159"
.entries[1].key = "value"
.entries[1].value = "42"
Each of the BPF programs and subprograms that share those variables would
get a distinct PERF_RECORD_BPF_METADATA record, with the ".prog_name"
showing the name of each program or subprogram. The prog_name is
deliberately the same as the ".name" field in the corresponding
PERF_RECORD_KSYMBOL record.
This code only gets invoked if support for displaying BTF char arrays
as strings is detected.
Signed-off-by: Blake Jones <blakejones@google.com>
Link: https://lore.kernel.org/r/20250612194939.162730-3-blakejones@google.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
This creates a config option that detects libbpf's ability to display
character arrays as strings, which was just added to the BPF tree
(https://git.kernel.org/bpf/bpf-next/c/87c9c79a02b4).
To test this change, I built perf (from later in this patch set) with:
- static libbpf (default, using source from kernel tree)
- dynamic libbpf (LIBBPF_DYNAMIC=1 LIBBPF_INCLUDE=/usr/local/include)
For both the static and dynamic versions, I used headers with and without
the ".emit_strings" option.
I verified that of the four resulting binaries, the two with
".emit_strings" would successfully record BPF_METADATA events, and the two
without wouldn't. All four binaries would successfully display
BPF_METADATA events, because the relevant bit of libbpf code is only used
during "perf record".
Signed-off-by: Blake Jones <blakejones@google.com>
Link: https://lore.kernel.org/r/20250612194939.162730-2-blakejones@google.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Fix build warnings with W=1 that started appearing after
commit a934a57a42 ("scripts/misc-check: check missing #include
<linux/export.h> when W=1").
While at it, also sort the include lists alphabetically.
Link: https://lore.kernel.org/r/20250614221301.100803-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Add a tracing function that, for a guest memory range, displays
the start and end addresses plus the per-page attributes being set.
Signed-off-by: Liam Merwick <liam.merwick@oracle.com>
Reviewed-by: Pankaj Gupta <pankaj.gupta@amd.com>
Link: https://lore.kernel.org/r/20250609091121.2497429-3-liam.merwick@oracle.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Let userspace "disable" IPI virtualization for AVIC via the enable_ipiv
module param, by never setting IsRunning. SVM doesn't provide a way to
disable IPI virtualization in hardware, but by ensuring CPUs never see
IsRunning=1, every IPI in the guest (except for self-IPIs) will generate a
VM-Exit.
To avoid setting the real IsRunning bit, while still allowing KVM to use
each vCPU's entry to update GA log entries, simply maintain a shadow of
the entry, without propagating IsRunning updates to the real table when
IPI virtualization is disabled.
Providing a way to effectively disable IPI virtualization will allow KVM
to safely enable AVIC on hardware that is susceptible to erratum #1235,
which causes hardware to sometimes fail to detect that the IsRunning bit
has been cleared by software.
Note, the table _must_ be fully populated, as broadcast IPIs skip invalid
entries, i.e. won't generate VM-Exit if every entry is invalid, and so
simply pointing the VMCB at a common dummy table won't work.
Alternatively, KVM could allocate a shadow of the entire table, but that'd
be a waste of 4KiB since the per-vCPU entry doesn't actually consume an
additional 8 bytes of memory (vCPU structures are large enough that they
are backed by order-N pages).
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
[sean: keep "entry" variables, reuse enable_ipiv, split from erratum]
Link: https://lore.kernel.org/r/20250611224604.313496-19-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Move enable_ipiv to common x86 so that it can be reused by SVM to control
IPI virtualization when AVIC is enabled. SVM doesn't actually provide a
way to truly disable IPI virtualization, but KVM can get close enough by
skipping the necessary table programming.
Link: https://lore.kernel.org/r/20250611224604.313496-18-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Drop the vCPU's pointer to its AVIC Physical ID entry, and simply index
the table directly. Caching a pointer address is completely unnecessary
for performance, and while the field technically caches the result of the
pointer calculation, it's all too easy to misinterpret the name and think
that the field somehow caches the _data_ in the table.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Tested-by: Sairaj Kodilkar <sarunkod@amd.com>
Reviewed-by: Naveen N Rao (AMD) <naveen@kernel.org>
Link: https://lore.kernel.org/r/20250611224604.313496-17-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Allocate and track AVIC's logical and physical tables as u32 and u64
pointers respectively, as managing the pages as "struct page" pointers
adds an almost absurd amount of boilerplate and complexity. E.g. with
page_address() out of the way, svm->avic_physical_id_cache becomes
completely superfluous, and will be removed in a future cleanup.
No functional change intended.
Tested-by: Sairaj Kodilkar <sarunkod@amd.com>
Acked-by: Naveen N Rao (AMD) <naveen@kernel.org>
Link: https://lore.kernel.org/r/20250611224604.313496-16-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Drop avic_get_physical_id_entry()'s compatibility check on the incoming
ID, as its sole caller, avic_init_backing_page(), performs the exact same
check. Drop avic_get_physical_id_entry() entirely as the only remaining
functionality is getting the address of the Physical ID table, and
accessing the array without an immediate bounds check is kludgy.
Opportunistically add a compile-time assertion to ensure the vcpu_id can't
result in a bounds overflow, e.g. if KVM (really) messed up a maximum
physical ID #define, as well as run-time assertions so that a NULL pointer
dereference is morphed into a safer WARN().
No functional change intended.
Tested-by: Sairaj Kodilkar <sarunkod@amd.com>
Reviewed-by: Naveen N Rao (AMD) <naveen@kernel.org>
Link: https://lore.kernel.org/r/20250611224604.313496-15-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Inhibit AVIC with a new "ID too big" flag if userspace creates a vCPU with
an ID that is too big, but otherwise allow vCPU creation to succeed.
Rejecting KVM_CREATE_VCPU with EINVAL violates KVM's ABI as KVM advertises
that the max vCPU ID is 4095, but disallows creating vCPUs with IDs bigger
than 254 (AVIC) or 511 (x2AVIC).
Alternatively, KVM could advertise an accurate value depending on which
AVIC mode is in use, but that wouldn't really solve the underlying problem,
e.g. would be a breaking change if KVM were to ever try and enable AVIC or
x2AVIC by default.
Cc: Maxim Levitsky <mlevitsk@redhat.com>
Tested-by: Sairaj Kodilkar <sarunkod@amd.com>
Link: https://lore.kernel.org/r/20250611224604.313496-14-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Drop vcpu_svm's avic_backing_page pointer and instead grab the physical
address of KVM's vAPIC page directly from the source. Getting a physical
address from a kernel virtual address is not an expensive operation, and
getting the physical address from a struct page is *more* expensive for
CONFIG_SPARSEMEM=y kernels. Regardless, none of the paths that consume
the address are hot paths, i.e. shaving cycles is not a priority.
Eliminating the "cache" means KVM doesn't have to worry about the cache
being invalid, which will simplify a future fix when dealing with vCPU IDs
that are too big.
WARN if KVM attempts to allocate a vCPU's AVIC backing page without an
in-kernel local APIC. avic_init_vcpu() bails early if the APIC is not
in-kernel, and KVM disallows enabling an in-kernel APIC after vCPUs have
been created, i.e. it should be impossible to reach
avic_init_backing_page() without the vAPIC being allocated.
Tested-by: Sairaj Kodilkar <sarunkod@amd.com>
Reviewed-by: Naveen N Rao (AMD) <naveen@kernel.org>
Link: https://lore.kernel.org/r/20250611224604.313496-13-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
