Unloading the mt7915e module with a MT7916 triggers multiples WARN in
__netif_napi_del_locked() and in page_pool_disable_direct_recycling()
because the driver does not disable the napi before destroying it.
This is troublesome since on MT7916 it is required to unload the module
and reinsert it with a different enable_6ghz parameter to change the
frequency. The system generally becomes unstable after reinserting the
module.
Fix it by disabling napi before deleting it. Also, do not delete napi
on WED queues since napi is neither used nor initialized on them.
Fixes: 17f1de56df ("mt76: add common code shared between multiple chipsets")
Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
Link: https://patch.msgid.link/20260708144615.24092-1-nicolas.cavallari@green-communications.fr
Signed-off-by: Felix Fietkau <nbd@nbd.name>
PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7615_rx_check() and
mt7615_queue_rx_skb() dispatch it to mt7615_mac_tx_free() on every bus.
mt7615_mac_tx_free() cleans the DMA tx queues with
mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the
mmio queue ops implement that callback; on the mt7663 USB and SDIO
buses it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX
worker. Same defect as the mt7921 and mt7925 patches in this series.
Drop the event on non-mmio buses via mt76_is_mmio(), as in
commit 5683e1488a ("wifi: mt76: connac: do not check WED status for
non-mmio devices").
Fixes: eb99cc95c3 ("mt76: mt7615: introduce mt7663u support")
Cc: stable@vger.kernel.org
Signed-off-by: Devin Wittmayer <lucid_duck@justthetip.ca>
Link: https://patch.msgid.link/20260627191336.20223-4-lucid_duck@justthetip.ca
Signed-off-by: Felix Fietkau <nbd@nbd.name>
PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7925_rx_check() and
mt7925_queue_rx_skb() dispatch it to mt7925_mac_tx_free() on every bus.
mt7925_mac_tx_free() cleans the DMA tx queues with
mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the
mmio queue ops implement that callback; on USB it is NULL, so a
TXRX_NOTIFY there calls a NULL pointer in the RX worker:
BUG: kernel NULL pointer dereference, address: 0000000000000000
RIP: 0010:0x0
Call Trace:
mt7925_mac_tx_free+0x58/0x350 [mt7925_common]
mt7925_rx_check+0xe2/0x130 [mt7925_common]
mt76u_rx_worker+0x1b9/0x620 [mt76_usb]
Drop the event on non-mmio buses via mt76_is_mmio(), as in
commit 5683e1488a ("wifi: mt76: connac: do not check WED status for
non-mmio devices").
Fixes: c948b5da6b ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips")
Cc: stable@vger.kernel.org
Signed-off-by: Devin Wittmayer <lucid_duck@justthetip.ca>
Link: https://patch.msgid.link/20260627191336.20223-3-lucid_duck@justthetip.ca
Signed-off-by: Felix Fietkau <nbd@nbd.name>
PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7921_rx_check() and
mt7921_queue_rx_skb() dispatch it to mt7921_mac_tx_free() on every bus.
mt7921_mac_tx_free() cleans the DMA tx queues with
mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the
mmio queue ops implement that callback; on USB and SDIO it is NULL, so
a TXRX_NOTIFY there calls a NULL pointer in the RX worker:
BUG: kernel NULL pointer dereference, address: 0000000000000000
RIP: 0010:0x0
Call Trace:
mt7921_mac_tx_free+0x64/0x310 [mt7921_common]
mt7921_rx_check+0x5f/0xf0 [mt7921_common]
mt76u_rx_worker+0x1b9/0x620 [mt76_usb]
Drop the event on non-mmio buses via mt76_is_mmio(), as in
commit 5683e1488a ("wifi: mt76: connac: do not check WED status for
non-mmio devices").
Fixes: 48fab5bbef ("mt76: mt7921: introduce mt7921s support")
Cc: stable@vger.kernel.org
Signed-off-by: Devin Wittmayer <lucid_duck@justthetip.ca>
Link: https://patch.msgid.link/20260627191336.20223-2-lucid_duck@justthetip.ca
Signed-off-by: Felix Fietkau <nbd@nbd.name>
The interrupt properties for fio_ioexp (pca9555 on i2c14) were incorrectly
configured to gpio1 with ASPEED_GPIO(B, 6).
Update the interrupt-parent to gpio0 and the interrupt pin to
ASPEED_GPIO(C, 6) according to the hardware specification.
Signed-off-by: Potin Lai <potin.lai.pt@gmail.com>
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Since the original email account is no longer in
use, I have updated it to my current email address.
Signed-off-by: Hongbo Li <hongbohbli@tencent.com>
Acked-by: Chao Yu <chao@kernel.org>
Acked-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
dev->stats fields can be updated concurrently from multiple CPUs
without synchronization.
Use DEV_STATS_INC() for stats increments and DEV_STATS_READ()
when reading dev->stats in ppp_get_stats64() and ppp_get_stats()
to avoid data races.
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Qingfang Deng <qingfang.deng@linux.dev>
Link: https://patch.msgid.link/20260715055541.1147542-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In cifs_close_deferred_file(), cifs_close_all_deferred_files(), and
cifs_close_deferred_file_under_dentry(), when a pending deferred close
is cancelled via cancel_delayed_work(), the subsequent kmalloc_obj() to
add the file to the local processing list may fail under memory pressure.
The loop breaks immediately, but the cancelled work is no longer pending
(it would have called _cifsFileInfo_put()), and the cfile is never added
to file_head for processing. The cifsFileInfo reference and the open
server handle both leak.
Fix by saving the cfile that failed allocation in a local variable,
breaking as before, and calling _cifsFileInfo_put() on it after
releasing the lock. Any files later in the iteration are unaffected
since their deferred work is still pending and will fire normally.
Fixes: e3fc065682 ("cifs: Deferred close performance improvements")
Signed-off-by: Frank Sorenson <sorenson@redhat.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Windows Server's directory enumeration metadata lags behind the actual
file size after a write+close or rename. A concurrent readdir() in the
window between close() returning to userspace and stat() being called
overwrites the correct cached i_size with the stale server value, causing
stat() to return the wrong size.
Once _cifsFileInfo_put() removes the last writable handle from
openFileList, is_size_safe_to_change() permits readdir to overwrite
i_size. smb2_close_getattr() then stamps cifs_i->time = jiffies, making
the corrupt cached value appear fresh to the next stat().
The existing check (see Fixes:) only blocked stale size updates while
an active RW lease was held, not after the last writable handle closes.
Add cifsInodeInfo->time_last_write, written via smp_store_release() at
writable close and on setattr/truncate. is_size_safe_to_change() checks
is_inode_writable() first (acquiring open_file_lock), then rejects a
readdir size update if time_last_write falls within acregmax jiffies.
The spinlock release in _cifsFileInfo_put() forms a store-release barrier
that pairs with the spin_lock() (load-acquire) in is_inode_writable(),
ensuring the subsequent smp_load_acquire() on time_last_write observes
any update from a concurrent close(). When a size update is rejected and
the server value differs from the cached one, cifs_i->time is cleared to
force a fresh QUERY_INFO on the next stat().
readdir is also blocked from changing i_size while writable handles are
open or an RW lease is held, even on direct-IO mounts.
For deferred close (closetimeo > 0), time_last_write is refreshed at the
actual server close in smb2_deferred_work_close() and in the
cifs_close_deferred_file*() drain paths invoked by lease/oplock breaks
and tcon teardown, anchoring the protection window to the real close time
rather than the earlier userspace close.
time_last_write == 0 skips the time_before() check to avoid false
positives near boot on 32-bit systems where jiffies starts close to
INITIAL_JIFFIES.
Does not reproduce against Samba or with actimeo=0.
Fixes: e4b61f3b1c ("cifs: prevent updating file size from server if we have a read/write lease")
Signed-off-by: Frank Sorenson <sorenson@redhat.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
intel_mac_finish() is registered as the phylink mac_finish()
callback for the Elkhart Lake SGMII ports. phylink calls it at
the end of every major link reconfiguration, including the
initial one during probe.
The callback selects the PMC ModPHY LCPLL programming for the
requested MAC-side interface and then power-cycles the SerDes.
On Elkhart Lake that ModPHY is also used by the on-die AHCI
SATA PHY. Reapplying the programming during the initial
boot-time link-up disturbs the shared analog block while it is
still driving SATA, so the SATA link fails to train:
ata1: SATA link down (SStatus 1 SControl 300)
The disk carrying the root filesystem is never detected and the
system hangs at rootwait. Ethernet itself comes up normally,
which makes the failure look unrelated to the network driver.
Before mac_finish() runs, the legacy SerDes power-up path has
already programmed SERDES_GCR0 for the current interface. The
1G and 2.5G ModPHY tables selected by mac_finish() correspond
to the SerDes lane rate, so read that rate back from SERDES_GCR0
and skip the PMC reprogramming and SerDes power-cycle when it
already matches the selected interface.
This keeps the disruptive reprogramming out of the boot path
when the SerDes is configured correctly, while preserving the
previous behavior when a real SGMII/1000BASE-X to 2500BASE-X
rate change is needed. If the register read fails, reconfigure
as before.
Fixes: a42f6b3f1c ("net: stmmac: configure SerDes according to the interface mode")
Cc: stable@vger.kernel.org
Signed-off-by: Markus Breitenberger <bre@keba.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/20260713171619.192452-1-bre@breiti.cc
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Remove extra variable in `set/get_property`-functions that is only
supplied directly to other functions. The value is not used for anything
else.
Moreover, wrap these lines. Otherwise `checkpatch` warns about too long
lines.
Signed-off-by: Waqar Hameed <waqar.hameed@axis.com>
Link: https://patch.msgid.link/6b4367512dfad62e865de8b6be52eefd5385fa26.1782746851.git.waqar.hameed@axis.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
To pick up the changes in:
103ff3a50e ("KVM: s390: Add capability to support 2G hugepages")
229132c309 ("LoongArch: KVM: Add DMSINTC device support")
2619da73bb ("KVM: x86: Use __DECLARE_FLEX_ARRAY() for UAPI structures with VLAs")
4aebd7d5c7 ("KVM: s390: Add KVM capability for ESA mode guests")
4f256d5770 ("KVM: x86: nSVM: Save/restore gPAT with KVM_{GET,SET}_NESTED_STATE")
822790ab01 ("KVM: x86: Define KVM_X86_QUIRK_NESTED_SVM_SHARED_PAT")
8800dbf661 ("KVM: arm64: Allow userspace to create protected VMs when pKVM is enabled")
bf8f3cec93 ("KVM: s390: vsie: Refactor handle_stfle")
c547c51ff4 ("KVM: arm64: gic-v5: Add ARM_VGIC_V5 device to KVM headers")
d7507a94a0 ("KVM: SVM: Treat exit_code as an unsigned 64-bit value through all of KVM")
This addresses these perf build warnings:
Warning: Kernel ABI header differences:
diff -u tools/include/uapi/linux/kvm.h include/uapi/linux/kvm.h
diff -u tools/arch/x86/include/uapi/asm/kvm.h arch/x86/include/uapi/asm/kvm.h
diff -u tools/arch/x86/include/uapi/asm/svm.h arch/x86/include/uapi/asm/svm.h
diff -u tools/arch/s390/include/uapi/asm/kvm.h arch/s390/include/uapi/asm/kvm.h
Please see tools/include/uapi/README for further details.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
To pick up the changes in:
45e57cfb7b ("fs: Clarify FS_CASEFOLD_FL semantics in UAPI header")
That don't result in changes to the string tables generated from this header.
This addresses this perf build warning:
Warning: Kernel ABI header differences:
diff -u tools/perf/trace/beauty/include/uapi/linux/fs.h include/uapi/linux/fs.h
Please see tools/include/uapi/README for further details.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
To pick up the changes in:
4987a5763f ("net: block MSG_NO_SHARED_FRAGS in sendmsg()")
That don't result in changes to the string tables generated from this header.
This addresses this perf build warning:
Warning: Kernel ABI header differences:
diff -u tools/perf/trace/beauty/include/linux/socket.h include/linux/socket.h
Please see tools/include/uapi/README for further details.
Cc: Jann Horn <jannh@google.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
To pick up the changes in:
a1b6cf8e5e ("drm: uapi: Use SPDX in DRM core uAPI headers")
dc2d30e7db ("drm/doc: document DRM_IOCTL_SYNCOBJ_EVENTFD")
That don't result in changes to the string tables generated from this header.
This addresses this perf build warning:
Warning: Kernel ABI header differences:
diff -u tools/perf/trace/beauty/include/uapi/drm/drm.h include/uapi/drm/drm.h
Please see tools/include/uapi/README for further details.
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: Simon Ser <contact@emersion.fr>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
To pick up the changes in:
5ce9cc5a23 ("coco/tdx-host: Don't expose P-SEAMLDR information on CPUs with erratum")
7658b9343a ("KVM: SVM: add GMET bit definitions")
de0bfdc713 ("KVM: x86: Advertise AVX512 Bit Matrix Multiply (BMM) to userspace")
That just rebuilds perf, silencing this build warning.
This addresses this perf build warning:
Warning: Kernel ABI header differences:
diff -u tools/arch/x86/include/asm/cpufeatures.h arch/x86/include/asm/cpufeatures.h
Please see tools/include/uapi/README for further details.
Cc: Chao Gao <chao.gao@intel.com>
Cc: Nikunj A Dadhania <nikunj@amd.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
To pick up the changes in:
b56ca146a2 ("vmalloc: add __GFP_SKIP_KASAN support")
6a288a4ddb ("mm/page_alloc: fix initialization of tags of the huge zero folio with init_on_free")
That just rebuilds perf, silencing this build warning.
This addresses this perf build warning:
Warning: Kernel ABI header differences:
diff -u tools/include/linux/gfp_types.h include/linux/gfp_types.h
Please see tools/include/uapi/README for further details.
Cc: David Hildenbrand (Arm) <david@kernel.org>
Cc: Muhammad Usama Anjum <usama.anjum@arm.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
To pick up the changes in:
b588019e85 ("rtnetlink: add RTEXT_FILTER_NAME_ONLY support")
That just rebuilds perf, silencing this build warning.
This addresses this perf build warning:
Warning: Kernel ABI header differences:
diff -u tools/include/uapi/linux/rtnetlink.h include/uapi/linux/rtnetlink.h
Please see tools/include/uapi/README for further details.
Cc: Eric Dumazet <edumazet@google.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
To pick up the changes in:
de9e2b3d88 ("uapi: Provide DIV_ROUND_CLOSEST()")
That just rebuilds perf, silencing this build warning.
This addresses this perf build warning:
Warning: Kernel ABI header differences:
diff -u tools/include/uapi/linux/const.h include/uapi/linux/const.h
Please see tools/include/uapi/README for further details.
Cc: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Add two optional current-limit knobs surfaced through
POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT, selected by which input source
is currently online:
- DC (DOK / TA-IN): a "dc-current-limit-gpios" array drives the
GPIOs of an external resistor mux connected to the MAX8903 IDC pin
(DC Current-Limit Set Input, pin 11). The IDC pin programs the
step-down DC input current limit from 0.5 A to 2 A via R_IDC when
the DCM mode pin is logic-high. The DT property
"dc-current-limit-mapping" describes the (current_ua, gpio_value)
pairs the board can program; the driver picks the largest entry
whose limit is <= the requested limit. A 0 uA entry, used to
stop drawing DC current, is selectable by issuing a 0 uA request
(the selection uses a -1 "not found" sentinel rather than
tracking best_limit > 0, so the all-zero entry can win).
- USB (UOK / USB-IN): a single "usb-current-limit-gpio" drives the
MAX8903 IUSB pin (USB Current-Limit Set Input, pin 7). The IUSB
pin is silicon-fixed per the MAX8903 datasheet Pin Description:
logic-low selects 100 mA, logic-high selects 500 mA. The two
values are encoded as MAX8903_USB_CURRENT_LIMIT_{LOW,HIGH}_UA
#defines with the datasheet quote in a header comment. The
requested limit picks HIGH if it can absorb 500 mA, else LOW,
else returns -EINVAL rather than silently programming a higher
current that would violate the system power budget. Mirroring
the DC-priority policy in the get path: when ta_in is asserted
the part draws from DC regardless of USB state, so the set path
only routes to USB when DC is not online.
The dispatch in max8903_set_property() to the DC vs USB path needs to
match the active source flag set by the corresponding *_ok GPIO IRQ
handler; both update sites take a new struct mutex source_lock so the
check and the resulting hardware write cannot be torn by a concurrent
IRQ flipping the source-online flag mid-decision. The DOK/UOK IRQ
handlers hold source_lock across the full read-modify-evaluate block
(line sampling, ta_in/usb_in update, dcm/cen GPIO writes, psy type
update) so the cen enable calculation reads a stable other-source
flag rather than racing with the peer IRQ. The IRQs are requested
with IRQF_ONESHOT (threaded), so a sleepable lock is the right
primitive in both contexts. max8903_get_property() also takes
source_lock briefly to snapshot the source flags and current-limit
values so userspace never observes a torn pair of
(source-online flag, current-limit ua).
dc-current-limit-mapping gpio_value entries are validated at parse
against the GPIO array width so a malformed DT value is rejected
instead of being silently truncated by gpiod_set_array_value() and
selecting the wrong mux level. ndescs is also bounded to
< BITS_PER_TYPE(u32) to keep BIT(ndescs) well-defined on 32-bit.
The mapping is additionally required to contain a gpio_value=0
entry: devm_gpiod_get_array_optional() asks for GPIOD_OUT_LOW, so
the hardware mux starts at gpio_value 0, and the driver seeds
dc_current_limit_ua from the matching map entry. A DT lacking the
all-zero entry is rejected with -EINVAL because otherwise the
reported INPUT_CURRENT_LIMIT could disagree with the mux state
until a set_property write picks a real value.
Negative INPUT_CURRENT_LIMIT requests are rejected at the
set_property entry: val->intval is signed, the set_*_current_limit()
helpers take a u32, and a negative cast would silently widen to a
huge unsigned value, bypass the upper-bound guard and program the
maximum permitted current.
Signed-off-by: Herman van Hazendonk <github.com@herrie.org>
Link: https://patch.msgid.link/20260605-submit-power-max8903-dc-limit-v2-2-0c5396e98f14@herrie.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Add three optional properties to the MAX8903 charger binding to
describe board-level GPIO control of the DC and USB input current
limits:
DC input (TA / DOK pin):
- dc-current-limit-gpios (1..4 GPIOs): mux control lines feeding
the MAX8903 IDC resistor mux;
- dc-current-limit-mapping (uint32-matrix of {microamps,
gpio_bit_pattern} pairs): the available current levels and the
GPIO bit pattern that selects each level.
USB input (USB / UOK pin):
- usb-current-limit-gpios: a single GPIO driving the IUSB pin.
The IUSB pin is silicon-fixed by the MAX8903 datasheet (Pin
Description): low selects 100 mA, high selects 500 mA. Only
the GPIO mapping is board-specific; the current values are
not exposed in DT.
A dependentRequired block ties dc-current-limit-gpios and
dc-current-limit-mapping together so an incomplete DT cannot pass
validation with only one half of the pair.
These let userspace clamp the input draw via the standard
POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT power_supply attribute. The HP
TouchPad uses both: two TLMM lines select between 0.5 A, 1.0 A,
1.5 A and 2.0 A DC input current limits behind the MAX8903B
charger, and a third TLMM line picks the IUSB 100 mA / 500 mA
limit.
These are purely additive; existing platforms remain unaffected.
Signed-off-by: Herman van Hazendonk <github.com@herrie.org>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20260605-submit-power-max8903-dc-limit-v2-1-0c5396e98f14@herrie.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
In 713eeb2279 ("perf build: Move BPF skeleton generation out of
Makefile.perf") the bpf_skel used with 'perf bench uprobe' was moved
from tools/perf/util/bpf_skel/ to tools/perf/bench/bpf_skel.
Copy tools/perf/util/bpf_skel/.gitignore to that new directory so that
files generated during build get ignored by git.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Ian Rogers <irogers@google.com>
Cc: James Clark <james.clark@linaro.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Fixes: 713eeb2279 ("perf build: Move BPF skeleton generation out of Makefile.perf")
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Kumar Kartikeya Dwivedi says:
====================
Fix unique field logic in BTF
Fix constraint of certain fields that have to be unique when nested
structs are present, BPF_REFCOUNT which should be marked as unique.
See commit logs for details. While at it, fix improper offset check.
Changelog:
----------
v1 -> v2
v1: https://lore.kernel.org/bpf/20260719142401.2420111-1-memxor@gmail.com
* Add fix for BPF_REFCOUNT not being unique. (Sashiko)
* Roll improper offset warning check into series. (Sashiko)
====================
Link: https://patch.msgid.link/20260719153634.2908692-1-memxor@gmail.com
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Add a raw BTF test with two bpf_refcount fields. The duplicate must be
rejected during BTF loading instead of reaching the duplicate-field
invariant in btf_parse_fields().
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://patch.msgid.link/20260719153634.2908692-6-memxor@gmail.com
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Add a raw BTF test with a spin lock directly in a struct and another in a
nested struct. The duplicate must now be rejected during BTF loading.
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://patch.msgid.link/20260719153634.2908692-5-memxor@gmail.com
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
BPF_REFCOUNT is not marked as a unique field, while it should be. Fix
this oversight.
Fixes: d54730b50b ("bpf: Introduce opaque bpf_refcount struct and add btf_record plumbing")
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://patch.msgid.link/20260719153634.2908692-4-memxor@gmail.com
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
btf_find_struct_field() initializes a fresh seen mask for every recursive
descent. Unique special fields in different levels of the same aggregate
therefore do not see one another. The duplicate fields can reach
btf_parse_fields(), where they trigger an invariant WARN_ON_ONCE(). A
crafted user BTF can consequently trigger the warning before map creation
checks capabilities.
Initialize the seen mask once in btf_find_field() and pass the same pointer
through struct, datasec, and nested-struct walks. This gives the entire field
traversal one shared uniqueness state.
Fixes: 64e8ee8148 ("bpf: look into the types of the fields of a struct type recursively.")
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://patch.msgid.link/20260719153634.2908692-3-memxor@gmail.com
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Sashiko pointed out correctly that the case statement for
BPF_RES_SPIN_LOCK incorrectly checks offset for BPF_SPIN_LOCK.
Fix it by checking res_spin_lock_off instead.
Fixes: 0de2046137 ("bpf: Implement verifier support for rqspinlock")
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://patch.msgid.link/20260719153634.2908692-2-memxor@gmail.com
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Convert ltc3589.txt to yaml format.
Additional changes:
- Add interrupts to match driver code
- Require lltc,fb-voltage-divider property ^(sw1|sw2|sw3|bb-out|ldo1|ldo2)$
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20260714160147.1641379-1-Frank.Li@oss.nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
pKVM does support memory encryption, expose that to the rest of
the kernel through cc_platform_has()
At the moment, all devices inside the guest are emulated which
requires its memory to be shared back to the host (decrypted), so
set force_dma_unencrypted() to always return true.
Although, typically pKVM guests rely on restricted-dma-pools to
bounce traffic, with this change, it is possible to solely rely on
the default SWIOTLB for that (assuming the appropriate size is set
from the command line)
Signed-off-by: Mostafa Saleh <smostafa@google.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Tested-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
At the moment, arch_mm_preinit() checks if the system has limited
addressing or is running under CCA to enable SWIOTLB, only after to
be forced to true anyway if it was false due to
CONFIG_DMA_BOUNCE_UNALIGNED_KMALLOC being unconditionally true for
arm64.
Simplify this logic, by making it clear that SWIOTLB is always used
but its size depends on the address layout of the system.
Signed-off-by: Mostafa Saleh <smostafa@google.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
Tested-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
tcp_v4_send_ack() and tcp_v6_send_response() construct standalone TCP
responses with TCP-AO options. The option length carries the actual MAC
length, but the TCP header length includes the option rounded up to a
four-byte boundary.
tcp_ao_hash_hdr() writes the MAC only. Thus, when the MAC length is not
four-byte aligned, the one to three bytes after the MAC are left
uninitialized and may be transmitted. For the normal TCP-AO hashing
mode, those bytes also have to be initialized before computing the MAC.
Initialize only the alignment padding in the TCP-AO branches, before
hashing the header. Use TCPOPT_NOP, as in the normal TCP-AO output path.
This avoids adding work to non-AO TCP responses while preserving a valid
authenticated header.
Fixes: decde2586b ("net/tcp: Add TCP-AO sign to twsk")
Fixes: da7dfaa6d6 ("net/tcp: Consistently align TCP-AO option in the header")
Cc: stable@vger.kernel.org
Reported-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
Reported-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn>
Reported-by: Ao Wang <wangao@seu.edu.cn>
Reported-by: Xuewei Feng <fengxw06@126.com>
Reported-by: Qi Li <qli01@tsinghua.edu.cn>
Reported-by: Ke Xu <xuke@tsinghua.edu.cn>
Suggested-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260713105631.8616-1-zhaoyz24@mails.tsinghua.edu.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
cmd->dumpit callback can return a negative errno, causing an infinite
loop due to the while(len) condition. As the loop never terminates,
genl_mutex is never released, and other tasks waiting on it starve in D
state.
Check dumpit's return value, propagate it and jump to err_out on error.
Reported-by: syzbot+85d0bec020d805014a3a@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=85d0bec020d805014a3a
Fixes: d0796d1ef6 ("tipc: convert legacy nl bearer dump to nl compat")
Signed-off-by: Helen Koike <koike@igalia.com>
Reviewed-by: Tung Nguyen <tung.quang.nguyen@est.tech
Reviewed-by: Tung Nguyen <tung.quang.nguyen@est.tech>
Link: https://patch.msgid.link/20260713204940.647668-1-koike@igalia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
nh_res_bucket_migrate() passes an uninitialized netlink_ext_ack to
call_nexthop_res_bucket_notifiers(). When
nh_notifier_res_bucket_info_init() fails (e.g. the kzalloc returns
-ENOMEM), the error is propagated back before any notifier sets
extack._msg, and the error path formats the stale pointer with
pr_err_ratelimited("%s\n", extack._msg). With CONFIG_INIT_STACK_NONE
this dereferences uninitialized stack memory:
Oops: general protection fault, probably for non-canonical address ...
KASAN: maybe wild-memory-access in range [...]
RIP: 0010:string (lib/vsprintf.c:730)
vsnprintf (lib/vsprintf.c:2945)
_printk (kernel/printk/printk.c:2504)
nh_res_bucket_migrate (net/ipv4/nexthop.c:1816)
nh_res_table_upkeep (net/ipv4/nexthop.c:1866)
rtm_new_nexthop (net/ipv4/nexthop.c:3323)
rtnetlink_rcv_msg (net/core/rtnetlink.c:7076)
netlink_sendmsg (net/netlink/af_netlink.c:1900)
Kernel panic - not syncing: Fatal exception
Zero-initialize extack so _msg is NULL on error paths that never set it.
Fixes: 7c37c7e004 ("nexthop: Implement notifiers for resilient nexthop groups")
Reported-by: AutonomousCodeSecurity@microsoft.com
Signed-off-by: Xiang Mei (Microsoft) <xmei5@asu.edu>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260713221551.3344650-1-xmei5@asu.edu
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The RSI attestation token init and continue calls must be issued from
the same CPU. arm_cca_report_new() currently snapshots the CPU number
and uses smp_call_function_single() to issue those calls on that CPU.
With CONFIG_DEBUG_PREEMPT=y, the smp_processor_id() call used for the
snapshot triggers a debug splat [0] because it runs in preemptible
context. The snapshot does not pin the task to that CPU; it is only used
to choose the target CPU for smp_call_function_single(), which can fail
if that CPU is no longer available.
Use migrate_disable() and issue the token init and continue operations
directly, without the smp_call_function_single() callbacks. This keeps
the token request sequence on the same CPU while preserving a sleepable
context for the GFP_KERNEL allocations needed after the init call.
[0]
BUG: using smp_processor_id() in preemptible [00000000] code: cca-workload-at/264
caller is debug_smp_processor_id+0x20/0x30
CPU: 0 UID: 0 PID: 264 Comm: cca-workload-at Not tainted 7.1.0-rc1-00044-g55542ab273f2 #80 PREEMPT(lazy)
Hardware name: linux,dummy-virt (DT)
Call trace:
[...]
check_preemption_disabled+0xd8/0xf8
debug_smp_processor_id+0x20/0x30
arm_cca_report_new+0x48/0x278
tsm_report_read+0x154/0x1f8
tsm_report_outblob_read+0x20/0x38
configfs_bin_read_iter+0x118/0x208
vfs_read+0x220/0x318
[...]
Fixes: 7999edc484 ("virt: arm-cca-guest: TSM_REPORT support for realms")
Signed-off-by: Kohei Enju <enju.kohei@fujitsu.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Tested-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
gtp1u_send_echo_resp() ignores skb_pull_data()'s return value. Its
caller gtp1u_udp_encap_recv() only guarantees 16 bytes (udphdr +
gtp1_header), but the pull requests 20 (gtp1_header_long + udphdr). For
a 16-19 byte echo request the pull fails and returns NULL without
advancing skb->data; execution continues, and the following skb_push()
plus the IP header pushed by iptunnel_xmit() move skb->data below
skb->head, tripping skb_under_panic().
Fix it by dropping the packet when skb_pull_data() fails.
skbuff: skb_under_panic: ...
kernel BUG at net/core/skbuff.c:214!
Call Trace:
skb_push (net/core/skbuff.c:2648)
iptunnel_xmit (net/ipv4/ip_tunnel_core.c:82)
gtp_encap_recv (drivers/net/gtp.c:701 drivers/net/gtp.c:808 drivers/net/gtp.c:920)
udp_queue_rcv_one_skb (net/ipv4/udp.c:2388)
...
Kernel panic - not syncing: Fatal exception in interrupt
Fixes: 9af41cc334 ("gtp: Implement GTP echo response")
Reported-by: AutonomousCodeSecurity@microsoft.com
Signed-off-by: Xiang Mei (Microsoft) <xmei5@asu.edu>
Link: https://patch.msgid.link/20260710230724.942574-1-xmei5@asu.edu
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Matthieu Baerts says:
====================
selftests: net: add missing kconfig and settings
When trying to execute the same selftests targets as the ones executed
on NIPA, but using containers with minimal tools, I got some issues
with a few tests.
Most of these issues are due to missing kernel config, but also too
short timeout:
- For the kconfig, these issues were not visible on NIPA, because some
targets are executed in the same runner, using the same kernel: the
config files of the different targets are merged. On my side, I
followed the recommended way, and only used the config file on top of
a 'make defconfig', revealing some missing kconfig's.
- For the timeout, that was not visible on NIPA either because the
Netdev machines are very powerful and the timeout is doubled when
using a debug kernel config (ovpn case), or because there are some
custom values on the test branches only (drv-net).
While at it, add an extra patch to display an error message in case of
failure with some netconsole scripts.
====================
Link: https://patch.msgid.link/20260710-net-sft-fix-containers-v1-0-a2915c294ef5@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In these netconsole tests, bash is used with errexit (set -e). It means
that if the busywait timeout, the tests finish without printing an error
message.
It is fine to ignore these errors, because the following validate_xxx
helpers will check the content of the output file, and exit with an
appropriated error message, e.g. FAIL: File was not generated.
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Reviewed-by: Breno Leitao <leitao@debian.org>
Link: https://patch.msgid.link/20260710-net-sft-fix-containers-v1-7-a2915c294ef5@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This psp.py selftest was failing on my side when only using the
drivers/net config file on top of the default one -- the recommended way
to execute selftest targets.
It looks like some kernel config are needed to execute the new tc
commands.
Note that this was not visible on NIPA, because these tests are executed
with the drivers/net/hw ones, combining the two config files, and the hw
one contains the missing ones.
Fixes: 3f74d5bb80 ("selftests/net: Add env for container based tests")
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Reviewed-by: Wei Wang <weibunny@fb.com>
Link: https://patch.msgid.link/20260710-net-sft-fix-containers-v1-6-a2915c294ef5@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The default timeout is 45 seconds, that's too low for the xdp.py test.
Indeed, this test can take up to 3 minutes with some debug kernel config
on NIPA. Set a timeout to 6 minutes, just to be on the safe side.
Note that the Fixes tag here points to the introduction of the xdp.py
test because I don't know when this test started to take more than 45
seconds. That's OK because a timeout of 6 minutes is not exaggerated.
Fixes: 1cbcb1b28b ("selftests: drv-net: Test XDP_PASS/DROP support")
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260710-net-sft-fix-containers-v1-5-a2915c294ef5@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The default timeout is 45 seconds, that's too low for a few ovpn tests.
Indeed, these tests can take up to 50 seconds with some debug kernel
config on NIPA. Set a timeout to 90 seconds, just to be on the safe
side.
Note that the Fixes tag here points to the introduction of the ovpn
tests because I don't know when they started to take more than 45
seconds. That's OK because a timeout of 1.5 minutes is not exaggerated.
Fixes: 959bc330a4 ("testing/selftests: add test tool and scripts for ovpn module")
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Acked-by: Antonio Quartulli <antonio@openvpn.net>
Link: https://patch.msgid.link/20260710-net-sft-fix-containers-v1-4-a2915c294ef5@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
They are required to run the selftests:
- Tests are executed in v4 and v6.
- Virtual Ethernet are used between the different netns.
This has not been seen on NIPA before, because the 'ovpn' tests are
executed with the 'tcp_ao' ones, merging their config files. These two
kernel config are present in tools/testing/selftests/net/tcp_ao/config.
This issue is visible when only the ovpn config is used on top of the
default one. This is the recommended way to execute selftest targets.
Fixes: 959bc330a4 ("testing/selftests: add test tool and scripts for ovpn module")
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Acked-by: Antonio Quartulli <antonio@openvpn.net>
Link: https://patch.msgid.link/20260710-net-sft-fix-containers-v1-3-a2915c294ef5@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The kselftests doc mentions that a config file should be present "if a
test needs specific kernel config options enabled". This selftest
requires some kernel config, but no config file was provided.
We could say that a sub-target could use the parent's config file, but
the kselftests doc doesn't mention anything about that. Plus the
net/openvswitch target is the only net target without a config file.
Here is a new config file, which is a trimmed version of the net one,
with hopefully the minimal required kconfig on top of 'make defconfig'.
The Fixes tag points to the introduction of the net/openvswitch target,
just to help validating this target on stable kernels.
Fixes: 25f16c873f ("selftests: add openvswitch selftest suite")
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Reviewed-by: Eelco Chaudron <echaudro@redhat.com>
Link: https://patch.msgid.link/20260710-net-sft-fix-containers-v1-2-a2915c294ef5@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This is required to use unshare(CLONE_NEWUSER).
This has not been seen on NIPA before, because the 'af_unix' tests are
executed with the 'net' ones, merging their config files. USER_NS is
present in tools/testing/selftests/net/config.
This issue is visible when only the af_unix config is used on top of the
default one. This is the recommended way to execute selftest targets.
Fixes: ac011361bd ("af_unix: Add test for sock_diag and UDIAG_SHOW_UID.")
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260710-net-sft-fix-containers-v1-1-a2915c294ef5@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Will notes that the ARM64_WORKAROUND_REPEAT_TLBI name is potentially
misleading, and that it would be nice to rename that and add some
documentation. See:
https://lore.kernel.org/linux-arm-kernel/ajKn_Pt50CmOUrsP@willie-the-truck/
To that end, I've renamed the Kconfig symbol and hwcap from:
[CONFIG_]ARM64_WORKAROUND_REPEAT_TLBI
... to:
[CONFIG_]ARM64_WORKAROUND_REPEAT_TLBI_SYNC
... and I've added some rationale alongside the Kconfig. As the Kconfig
symbol isn't user selectable, the usual 'help' section won't appear in
menuconfig, so I've added this as a comment.
The rename was scripted with:
git grep -l REPEAT_TLBI | while read F; do
sed -i '{ s/WORKAROUND_REPEAT_TLBI\>/WORKAROUND_REPEAT_TLBI_SYNC/g }' $F;
done
Bikeshedding-wise, I considered a few names, including:
* ARM64_WORKAROUND_REPEAT_TLBI_SYNC
* ARM64_WORKAROUND_TLBI_REPEAT_SYNC
* ARM64_WORKAROUND_BROADCAST_TLBI_REPEAT_SYNC
... and I settled on ARM64_WORKAROUND_REPEAT_TLBI_SYNC to try keep
things simple, and to avoid unnecessary churn caused by moving
definitions to retain alphabetical order. I'm happy to defer to Will and
Catalin's preference.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
