| Age | Commit message (Collapse) | Author |
|---|
|
mac_finish()
ethqos->phy_mode is read by serdes_powerup() and
qcom_ethqos_set_sgmii_loopback() to configure the SerDes and its
wrapper for the correct interface. It is set once at probe from the DT
phy-mode property and never updated.
phylink resolves the actual runtime interface and passes it to the
mac_finish() callback. On platforms that only ever operate at one speed
these two values are always the same, but when the interface changes
at runtime - for example switching between SGMII and 2500BASE-X - the
stored value becomes stale. The next serdes_powerup() call, on
a subsequent link cycle, then reinitializes the SerDes to the wrong mode.
Update ethqos->phy_mode from the interface argument in
ethqos_mac_finish_serdes() so that it always reflects the last
resolved interface.
With that, we now update the phy_mode to the runtime-resolved interface,
so any subsequent resume with a 1G SGMII link skips the loopback setup
and the DMA reset hangs. To remedy this, extend the guard to include
PHY_INTERFACE_MODE_SGMII.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Reviewed-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
Link: https://patch.msgid.link/20261014-qcom-sa8255p-emac-v16-4-0266c2ead980@oss.qualcomm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Call phy_set_mode_ext() before phy_power_on() in
qcom_ethqos_serdes_powerup(). This is harmless for existing users but on
SCMI systems this is required for the PHY driver to select the right
performance level - which translates to the link speed. This is done
ahead of adding support for the firmware-managed EMAC on Qualcomm sa8255p.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Reviewed-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
Link: https://patch.msgid.link/20261014-qcom-sa8255p-emac-v16-3-0266c2ead980@oss.qualcomm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
dwmac4_core_init() derives the TIC counter value from the rate of the CSR
clock. If no such clock is available (for instance because clocks are
managed by firmware and not described in DT), the rate is 0 and
(0 / 1000000) - 1 underflows to 0xffffffff, which is then written
to the register and can break the LPI timers that count in microseconds.
Leave the register at its reset value when the CSR clock rate is
unknown. The RX watchdog conversion helpers already cope with a missing
clock by falling back to clk_ref_rate or returning 0, so nothing else
needs to change.
This is first hit with the Qualcomm sa8255p ethernet, whose DT has no
clocks.
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/all/179052656185.2160803.1751830002645522416@kernel.org/
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Link: https://patch.msgid.link/20261014-qcom-sa8255p-emac-v16-1-0266c2ead980@oss.qualcomm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
si3474 prints the error of a failed controller registration as a hex
number, such as 0xfffffff4 for -ENOMEM. Use dev_err_probe(), as
pd692x0 and tps23881 already do. It prints the error by name, and if
the registration ever returns -EPROBE_DEFER, it does not log that as
an error.
Only the log message changes.
Signed-off-by: Carlo Szelinsky <github@szelinsky.de>
Link: https://patch.msgid.link/20261020171134.852878-3-github@szelinsky.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
If devm_add_action_or_reset() fails, it has already unregistered the
ancillary I2C client, and the error message then reads that client's
device. It can only fail with -ENOMEM, which is already reported, so
drop the message.
Found by code inspection. Not reproduced.
Fixes: a2317231df4b ("net: pse-pd: Add Si3474 PSE controller driver")
Reviewed-by: Kory Maincent <kory.maincent@bootlin.com>
Signed-off-by: Carlo Szelinsky <github@szelinsky.de>
Link: https://patch.msgid.link/20261020171134.852878-2-github@szelinsky.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next
drm-misc-next for v7.5:
UAPI Changes:
- Add Apple Interchange fourcc.
- Expose amdxdna busy time via DRM fdinfo.
Cross-subsystem Changes:
- Improve DT bindings for display/ste,mcde
- Add kunit test for dma_fence_dedup_array() to dma-buf/test.
Core Changes:
- Documentation updates to drm/scheduler, gpu/buddy.
- Fail kmapping a bo without pages.
Driver Changes:
- Bugfixes and improvements to panel/Raystar RFF500F-AWH-DNN,
accel/ivpu, vc4, accel/amdxdna, panthor, nouveau, panfrost,
panthor, accel/qaic, accel/rocket, bridge/lontium-lt8713sx,
appletbdrm.
- Add support for BOE Novatek NT51021, Retroid Pocket 6,
Raydium RM69220 DDIC panels, Sharp LQ138P1JX61 eDP,
BOE NV140FHD-N43, AUO B140HAN04.0, AUO 0x0db3,
panels.
- Add support for Mali-G68 to panfrost.
- Add Chrontel CH7218A to bridge/simple.
- Support ARGB8888 for virtio primary planes.
- Improve panfrost gpu reset handling and initialization.
- Add HDMI 2.0 support to rockchip/dw-hdmi-qp and improve HPD handling.
- Advertise HDMI 1.2 capabilities in sun4i, bridge/adv7511, it66121 & inno-hdmi.
- Advertise HDMI 1.3 capabilities in bridge/ite-6263.
- Advertise HDMI 1.4 capabilities in bridge/lt9611 & rockchip/rk3066_hdmi
- Switch many drivers to drm_atomic_helper_create_state in preparation
for readout.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patch.msgid.link/75e7de61-048c-4fdd-9ad2-6b47b29a4863@linux.intel.com
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux
Pull chrome platform firmware loader updates from Tzung-Bi Shih:
"New:
- Rename drivers/firmware/google/ -> drivers/firmware/coreboot/ and
corresponding Kconfig names
- Separate firmware_attributes_class from drivers/platform/x86/ to
drivers/firmware/ so that it is available for non-x86 platforms
- Add CFR (coreboot form representation) driver to expose the
attributes via sysfs
Improvements:
- Use named initializers for acpi_device_id"
* tag 'chrome-platform-firmware-v7.4' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux:
firmware: coreboot: Add CFR firmware attributes driver
firmware: Move firmware attributes class helper
firmware: coreboot: Use named initializers for acpi_device_id
firmware: Rename google firmware directory to coreboot
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux
Pull chrome platform updates from Tzung-Bi Shih:
"Improvements:
- Poll for role swap completion in cros_ec_typec
Fixes:
- Fix wrong returned data and length for deferred response in
transport protocol
- Check boundary for EC-returned data length in cros_ec_typec
- Fix a regression for older ChromeOS devices after applying
db65a06d10b3 ("ACPI: EC: Convert the driver to a platform one")
Cleanups:
- Fix typos"
* tag 'chrome-platform-v7.4' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux:
platform/chrome: cros_ec_typec: Poll for role swap completion
platform/chrome: cros_usbpd_notify: Only use drvdata when parent is GOOG0004
platform/chrome: cros_ec_typec: Validate SVID and mode counts in discovery data
platform/chrome: cros_ec_rpmsg: Fix repeated word 'from' in comment
platform/chrome: Fix typos in comments
platform/chrome: cros_ec_proto: Simplify cros_ec_wait_until_complete()
platform/chrome: cros_ec_proto: Fix deferred response
platform/chrome: cros_ec: Sync host command header with EC
|
|
Since xe_vma_ops_alloc() was reduced to a loop around
xe_pt_job_ops_alloc(), the compiler inlines it into all of its
callers, including xe_vm_bind_ioctl(). ALLOW_ERROR_INJECTION() only
keeps an out-of-line copy of the function alive for the kprobe, so
fail_function injection on xe_vma_ops_alloc is armed on a copy that is
never called and the bind IOCTL succeeds.
This is seen with the nodebug kernel config used in CI, where
igt@xe_fault_injection@vm-bind-fail-xe_vma_ops_alloc fails with:
Failed assertion: simple_vm_bind(fd, vm) != 0
Mark xe_vma_ops_alloc() noinline so callers go through the injectable
function.
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/9432
Fixes: 0e33330f1238 ("drm/xe: Add struct xe_pt_job_ops")
Cc: Matthew Brost <matthew.brost@intel.com>
Assisted-by: LLM
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20261007222426.1350374-1-shuicheng.lin@intel.com
Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
|
|
vxlan_vnifilter_process() parses the message with vni_filter_policy,
whose VXLAN_VNIFILTER_ENTRY is a bare NLA_NESTED with no nested policy
attached. The entry attributes are therefore validated only later, one
entry at a time, by the nla_parse_nested() inside
vxlan_process_vni_filter(). Entries are parsed as they are dispatched:
in a message whose first entry is valid and whose second is not, the
first entry is applied and its RTM_NEWTUNNEL notification sent before
the second is rejected.
Link the nest to vni_filter_entry_policy with NLA_POLICY_NESTED() so
every entry is checked against the entry policy up front, before any
entry is acted on. A message whose entry the policy rejects -- a
malformed attribute, or, with the next patch, an out-of-range endpoint
-- is now refused as a unit and installs nothing. Faults the policy does
not cover, such as a device or handler error raised on a later entry,
are unchanged: entries are still dispatched and applied one at a time.
This reorders two faults. The nest is validated before the device is
looked up and before the vnifilter flag is checked, so a request
rejected by the entry policy, aimed at a missing or non-vnifilter
device, now returns that policy error where it previously returned
-ENODEV or -EOPNOTSUPP. The request was invalid either way; only the
errno an operator sees changes.
The nla_parse_nested() in vxlan_process_vni_filter() stays: it is what
fills the per-entry attribute table the handler reads. It can no longer
fail on a message that has reached it.
Suggested-by: Jakub Kicinski <kuba@kernel.org>
Link: https://lore.kernel.org/netdev/20260921150904.65a704eb@kernel.org/
Signed-off-by: Ali Firas <alishmery18@gmail.com>
Link: https://patch.msgid.link/20261014123814.388557-2-alishmery18@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip
Pull xen updates from Juergen Gross:
"This time only small fixes and cleanups all over Xen related drivers.
Nothing really stands out here"
* tag 'for-linus-7.4-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
xen-blkfront: Fix IO race during unplug
xen-pciback: Fix pcistub_device ref leak in pcistub_get_gsi_from_sbdf()
xen/pcifront: check that an AER callback exists before calling it
xen/gntdev: Fix gntdev_dmabuf ref leak in dmabuf_exp_wait_released()
x86/PVH: don't truncate initrd address/size
xen/privcmd: Only claim ioreqs matching an ioeventfd
xen/scsifront: check for a NULL shadow entry on a backend response
xen: fix typos in comments
xen/gntdev: prevent private mappings from becoming writable
xen: remove unused hvm_vcpu.h header
xen-blkfront: unbind irq before tearing down ring and shadow requests
xen/blkback: Prevent missed completion when draining I/O
xen/pcifront: Fix PCI device reference leak in AER handling
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
Pull s390 updates from Heiko Carstens:
- Add support for sclp-vt220 terminal resize events e.g. for QEMU
- Warn if kernel command line contains non-printable EBCDIC characters
- Improve show_code() disassembly output by using reliable markers for
the instruction address and faulting instruction
- Rework exception handling to require only a single exception table
entry per faulting instruction: convert all inline assemblies from
EX_TABLE to the new EX_TABLE_INSN macros. The previous exception
handling was error prone since it usually required two EX_TABLE
entries: one pointing at the instruction, and one pointing behind it
- Disallow kprobes on instructions with exception table entries to
avoid exception handlers decoding a breakpoint instead of the
original instruction
- Preemptible percpu ops changes:
- Simplify percpu_entry() and percpu_exit() by encoding the percpu
base, offset, and pointer registers into the lowcore marker,
allowing percpu_exit() to update the percpu pointer on CPU
migration without comparing the interrupted instruction
- Convert this_cpu_cmpxchg(), this_cpu_xchg(), and
this_cpu_cmpxchg128() to preemptible percpu ops; provide
this_cpu_try_cmpxchg()
- Emulate virtual timer in appldata via delayed work and remove the
s390 specific vtimer infrastructure
- Add lock contention tracepoints to rwlock slowpath
- Fix incorrect return address in signal frame setup
- Fix cpum_cf CPU hotplug handling
- Convert various __get_free_pages() / get_zeroed_page() users to
kmalloc() / kzalloc()
- PCI:
- Improve RPCIT instruction tracing
- Fix double-free, use-after-free, and resource leaks in zPCI MSI
and IRQ setup / cleanup paths
- Crypto and zcrypt:
- Improve reply message and length verification checks for CCA,
EP11, and ICA messages to prevent out-of-bounds reads
- Add missing array_index_nospec() for domain index uses in zcrypt
to prevent speculative execution bypass
- Fix out-of-bounds read in cca_query_crypto_facility()
- Various other small fixes and improvements
* tag 's390-7.4-1' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: (102 commits)
s390/signal: Cleanup coding style
s390/signal: Fix incorrect return address in signal frame
s390/probes: Fix wrong mnemonic comment for clgib
s390/probes: Add missing fixup for bctgr and bic
s390/probes: Fix wrong opcode for cgrb fixup
s390: Select ARCH_MEMORY_ORDER_TSO
s390/mm: Cleanup pXXp_flush_lazy() routines
s390/pci: Add function handle to RPCIT insn trace
s390/pci: Use 32-bit fh outside of inline asm
s390/pci: Adjust alignment in insn trace
s390/sclp: Remove redundant memset after memblock_alloc_low()
s390/entry: Save lowcore on invalid kernel stack
s390/entry: Last breaking event vs invalid kernel stack
s390/percpu: ImplemenHeiko Carstenst this_cpu_try_cmpxchg()
s390/percpu: Drop unused output register from arch_this_cpu_to_op()
s390/percpu: Drop unused output register from arch_this_cpu_add()
s390/percpu: Use asm_inline for arch_this_cpu_add()
s390/extable: Remove EX_TABLE macros and fallback extable search
s390/bpf: Simplify exception table entry handling
s390/sclp: Convert inline assembly to EX_TABLE_INSN
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k
Pull m68k updates from Geert Uytterhoeven:
- Add and enable support for the SVEthLANa Ethernet interface on the
Atari SuperVidel FPGA expansion card
- Enable support for the IDE interface on the Amiga CS-Lab Warp
expension card
- defconfig updates
- Miscellaneous fixes and improvements
* tag 'm68k-for-v7.4-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k:
m68k: defconfig: Enable ATARI_SVETHLANA and ETHOC
m68k: defconfig: Update defconfigs for v7.3-rc1
zorro: Use assign_bit() where applicable
m68k: apollo: Fix interrupt setup
m68k: defconfig: Enable PATA_CSWARP
m68k: Add support for SVEthLANa
m68k: Add include guard to asm/serial.h
m68k: Use generic BASE_BAUD in asm/serial.h
|
|
system_wq is deprecated and triggers a runtime warning:
[ 0.857414] workqueue: work func ...WorkItemPointerKy0_E3runB7_ enqueued on deprecated workqueue. Use system_{percpu|dfl}_wq instead.
Replace system() with system_percpu() and system_dfl(), to match the
previous behavior of the deprecated system() and convert doc examples
and tests to system_dfl().
system_unbound_wq is deprecated in the same way, in favor of
system_dfl_wq. Since system_unbound() has no users, just remove it as
well.
Fixes: 64d8eae3f895 ("workqueue: Add warnings and fallback if system_{unbound}_wq is used")
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Boqun Feng <boqun@kernel.org>
Reviewed-by: Dongliang Mu <dzm91@hust.edu.cn>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Acked-by: Marco Crivellari <marco.crivellari@suse.com>
Acked-by: Tejun Heo <tj@kernel.org>
Link: https://patch.msgid.link/20261014-rust-workqueue-system-fix-v2-1-c018b8f870f9@google.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
npcm7xx_pwm_config_set() writes the channel's CMR register and then
does a read-modify-write of the CR register that holds the enable and
invert bits of all four channels of a PWM module. It is called from the
hwmon pwm write path and from npcm7xx_pwm_cz_set_cur_state(), the
set_cur_state callback of the thermal cooling devices the driver
registers for channels with "cooling-levels".
The per-module pwm_lock serializing these updates was dropped on the
assumption that the hwmon core serializes all attribute accesses. That
only covers the hwmon attributes: the cooling devices are registered
directly with the thermal core, which only holds the lock of the
cooling device being updated. So a thermal zone update or a write to a
cooling device's cur_state can run concurrently with a pwm write, or
with the cooling device of another channel of the same module, and one
CR update overwrites the other:
CPU0 (pwmN write) CPU1 (cooling dev, same module)
tmp = ioread32(CR)
tmp = ioread32(CR)
tmp |= ch1 enable
iowrite32(tmp, CR)
tmp |= ch0 enable
iowrite32(tmp, CR) /* ch1 enable bit lost */
leaving a fan stopped or running at a duty cycle that no longer matches
its enable state.
The bug was found by code inspection and has not been reproduced.
Fix by restoring a per-module mutex around the register updates; a
driver lock is used instead of hwmon_lock() because the cooling devices
are registered before the hwmon device exists.
Fixes: abfb05085177 ("hwmon: (corsair-psu) Rely on subsystem locking")
Assisted-by: LLM
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
The registers of the chip are banked: each access selects the bank, which
is cached in data->bank_sel, and then reads or writes the register.
bank_lock used to make the two steps atomic. It has been removed because
the hwmon core serialises the sensor callbacks, but the watchdog callbacks
use the same access functions and are not called by the hwmon core.
So a sensor can now be read while the watchdog is being pinged. If one of
them selects its bank between the two steps of the other, the second step
hits a register of the wrong bank: the watchdog is not fed, or its
commands are written to some sensor or fan control register.
Take the lock of the hwmon device in the watchdog callbacks. The watchdog
is registered after the hwmon device, and devres unregisters it first.
Fixes: 9ad270bf4dcc ("hwmon: (nct7904) Rely on subsystem locking")
Assisted-by: LLM
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
The registers of the chip are paged: fts_read_byte() and fts_write_byte()
select the page and then access the register. access_lock used to make
the two steps atomic. It has been removed because the hwmon core
serialises the sensor callbacks, but the watchdog code uses the same two
functions and is not called by the hwmon core.
So the sensors can now be read, or an alarm be cleared, while the watchdog
is being started or stopped. If one of them selects its page between the
two steps of the other, the second step hits a register of the wrong page.
Take the lock of the hwmon device in the watchdog callbacks, and for the
accesses of fts_watchdog_init(), which runs when the hwmon device has
already been registered. These are moved to a function of their own, so
that the lock is not held while the watchdog is being registered. devres
unregisters the watchdog before the hwmon device.
Fixes: fa035d98dbae ("hwmon: (ftsteutates) Rely on subsystem locking")
Assisted-by: LLM
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
ibmveth_rx_mss_helper() and ibmveth_rx_csum_helper() trust the IP and
TCP headers of received frames, which come from another partition on
the virtual LAN.
The worst case is an IPv4 frame with ihl 0 and iph->check 0xffff: the
checksum helper calls ip_fast_csum(iph, 0), and the ppc64 version
loops ihl - 1 times on an unsigned count, reading up to 16 GiB in
softirq: a long stall, or an oops once the read leaves mapped memory.
Both helpers also read and write header fields past the end of a short
frame. The large send helper takes the segment size from the TCP
checksum field and gso_segs from a TCP header length it never checks,
and treats an IPv4 TCP fragment as a large send, which can zero two of
its bytes; the checksum helper can write a checksum into a later
fragment's payload.
The ihl problem dates from the first commit in Fixes:, the large send
helper from the second, and the checksum helper from the third.
Before using a header, check that it fits the frame, that the IPv4 ihl
is at least 5, and that an IPv4 TCP frame is not a fragment. In the
large send helper, also require a TCP doff of at least 5, TCP payload
within the IP length, and an IP length equal to the frame length:
Ethernet padding or other bytes past the IP length would otherwise
stay in a bridged or switched frame, which the stack does not trim,
and be segmented but not counted in gso_segs. Compute gso_segs from
the IP length, and keep the segment size at or above TCP_MIN_GSO_SIZE,
as virtio_net_hdr_to_skb() does since commit c27c449d455a ("virtio-net:
Ensure that TCP packets don't overflow gso_segs"), and below
GSO_BY_FRAGS, which virtio rejects. With the headers checked and
gso_segs computed, the skb is not marked SKB_GSO_DODGY, which would
also keep it from hardware TSO on the egress device.
A frame that fails a check is passed up unchanged, without the GSO
fields or CHECKSUM_UNNECESSARY, so nothing downstream trusts its
segment count or checksum. The skb is linear, so the checks use
skb_headlen(); pskb_may_pull() could reallocate the head under the
helpers' header pointers.
Add KUnit cases for both helpers: valid IPv4 and IPv6 large sends, the
segment size clamp, and refused frames. With any one of the ihl, doff,
IP length, TCP payload, fragment or clamp checks, or the checksum
helper's IPv4 options, IPv6 header or TCP header length checks,
removed, a case fails; without the checksum helper's ihl check,
ip_fast_csum() oopses on qemu.
Found by the Sashiko review of the previous version of this series and
confirmed by code inspection and the KUnit cases above. Tested with
KUnit on qemu pseries (ppc64le) and on a POWER10 LPAR with iperf3 large
sends over IPv4 and IPv6 at MTU 1500 and 9000, threaded NAPI and busy
polling, with no new drops or InCsumErrors. No kernel selftests cover
ibmveth.
Fixes: 9c7e8bc584f5 ("ibmveth: Add support for Large Receive Offload")
Fixes: 7b5967389f5a ("ibmveth: set correct gso_size and gso_type")
Fixes: 66aa0678efc2 ("ibmveth: Support to enable LSO/CSO for Trunk VEA.")
Signed-off-by: Mingming Cao <mmc@linux.ibm.com>
Link: https://patch.msgid.link/20261013182926.30417-10-mmc@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
napi_disable() returns once ibmveth_poll() has called
napi_complete_done(), but the poll is not finished: it then re-enables
the interrupt and calls ibmveth_rxq_pending_buffer(), which reads the
RX queue. ibmveth_close() can free that queue in the meantime, and the
late enable can leave the interrupt unmasked after close() masked it.
The request_irq() failure path in ibmveth_open() frees the same memory
after napi_disable() too.
Call synchronize_net() after napi_disable() on both paths. Every
caller of ibmveth_poll() runs it with bottom halves or interrupts
disabled, so this waits for the poll to return.
Found in review of the ibmveth multi-queue RX series and confirmed by
code inspection; also raised by the Sashiko review of the first version
of this series. The race was not reproduced. Tested on a POWER10 LPAR
under an incoming ping flood with 30 rapid link down/up cycles and 30
rapid MTU cycles (1500 <-> 9000); ran cleanly with no warnings or
faults. No kernel selftests cover ibmveth.
Fixes: bea3348eef27 ("[NET]: Make NAPI polling independent of struct net_device objects.")
Signed-off-by: Mingming Cao <mmc@linux.ibm.com>
Link: https://patch.msgid.link/20261013182926.30417-9-mmc@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
ibmveth_close() frees the TX buffers after netif_tx_stop_all_queues(),
which does not wait for an ibmveth_start_xmit() already running on
another CPU. That transmit can copy into a freed buffer and hand PHYP
a stale DMA address.
MTU, csum/TSO and buffer pool changes call ibmveth_close() directly
while traffic flows. ifdown and the reset work go through dev_close(),
which waits for running transmits only when the qdisc has an enqueue
function, so with noqueue they race the same way.
Use netif_tx_disable(), which waits for running transmits.
Found in review of the ibmveth multi-queue RX series and confirmed by
code inspection; the race was not reproduced. Tested on a POWER10 LPAR
with MTU changes during a ping flood, with no warnings. No kernel
selftests cover ibmveth.
Fixes: d6832ca48d8a ("ibmveth: Copy tx skbs into a premapped buffer")
Signed-off-by: Mingming Cao <mmc@linux.ibm.com>
Link: https://patch.msgid.link/20261013182926.30417-8-mmc@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
When ibmveth_set_channels() cannot allocate a TX buffer for a new
queue, it falls back to the old queue count, and the successful
netif_set_real_num_tx_queues() call then overwrites rc. ethtool -L
reports success while the queue count is unchanged.
Return the allocation error when the fallback succeeds.
Found in review of the ibmveth multi-queue RX series and confirmed by
code inspection. Tested on a POWER10 LPAR with the TX buffer allocation
forced to fail by a test-only module parameter (not part of this patch):
ethtool -L tx 8 now fails with -ENOMEM and the device keeps its four
queues and passes traffic. No kernel selftests cover ibmveth.
Fixes: 10c2aba89cc0 ("ibmveth: Ethtool set queue support")
Signed-off-by: Mingming Cao <mmc@linux.ibm.com>
Link: https://patch.msgid.link/20261013182926.30417-7-mmc@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
If register_netdev() fails in ibmveth_probe(), for example with -EINTR
when the binding task is killed, probe frees the netdev but leaves the
pool%d kobjects embedded in it registered in sysfs. Reading
/sys/devices/vio/<unit>/pool0/num is then a use-after-free, and the
next probe cannot add pool0.
Put the kobjects before freeing the netdev, as ibmveth_remove() does,
on this path and on the netif_set_real_num_tx_queues() one.
The kobjects also have no release(). With CONFIG_DEBUG_KOBJECT_RELEASE,
kobject_put() defers their cleanup, including removing the sysfs files,
to a work item, so free_netdev() can free them first, here and in
remove(). Add a release() that signals a per-pool completion, and wait
for it in both places before free_netdev(). Without that config,
release() runs from kobject_put() and the wait returns at once.
Found in review of the ibmveth multi-queue RX series and confirmed by
code inspection; the release() part was raised by the Sashiko review of
the first version. Tested on a POWER10 LPAR with register_netdev()
forced to fail with -EINTR by a test-only module parameter (not part of
this patch): no pool%d directories remain and the device binds again. No
kernel selftests cover ibmveth.
Fixes: 860f242eb534 ("[PATCH] ibmveth change buffer pools dynamically")
Signed-off-by: Mingming Cao <mmc@linux.ibm.com>
Link: https://patch.msgid.link/20261013182926.30417-6-mmc@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
ibmveth_poll() mishandles a bad RX correlator from PHYP in two ways.
If harvest fails or ibmveth_rxq_get_buffer() returns NULL, poll
breaks out without advancing the ring and restarts on the same slot
forever. For an out-of-range correlator it also fires a WARN_ON() and
schedules a reset each pass, but the reset is queued on that CPU and
never runs, and the CPU stalls RCU, so RTNL holders hang too. This
dates from the first commit in Fixes:, which turned the BUG_ON()s
here into WARN_ON() plus a reset.
The range check also accepts a correlator naming an inactive buffer
pool (pools 2 and 3 by default), whose skbuff array is NULL, so the
lookup dereferences NULL in softirq. Pools became inactive with the
second commit in Fixes:.
Validate the correlator in one helper that also rejects a pool with
no skbuff array. On a bad slot, advance the ring, count the drop in
rx_dropped and still schedule the reset, which rebuilds the pools.
The slot has moved, so stay in the budget loop and count it in
frames_processed. Breaking out would complete NAPI, re-arm, and
napi_schedule() with budget left. When the final check finds more
work, queue the NAPI and return instead of going back to
restart_poll: after napi_complete_done() the NAPI is no longer this
call's, and with threaded NAPI and busy polling the kthread can
already be polling it on another CPU. frames_processed is below
budget there, so busy_poll_stop() does not queue it a second time.
Mask the interrupt before queueing, as ibmveth_interrupt() does;
masking after napi_schedule() could land after that kthread has
finished and unmasked, leaving RX masked with nothing scheduled.
Drop a frame whose offset + length does not fit the pool buffer:
copybreak would read past the RX buffer and skb_put() would BUG().
Also drop one shorter than an Ethernet header, which eth_type_trans()
would read past. Read the correlator once per slot and use that value
for the lookup, the bound and the harvest.
The base driver never checked frame bounds, and they have not been
seen in the field, so they have no Fixes: tag of their own. The tags
below are for the correlator hang.
The correlator comes from PHYP, and with the ring advancing a burst
of bad slots would WARN once per slot (and panic with
panic_on_warn), so use a ratelimited netdev_err() instead. Also free
the rx_copybreak skb if harvest fails there.
Add a KUnit case for harvest advancing on errors and extend the
existing cases to an inactive pool. Run against the unfixed driver,
with the calls changed back to its signatures, the first fails and
the others oops.
Found in review of the ibmveth multi-queue RX series (the frame bound by
the Sashiko review of v2 of this series) and confirmed by code
inspection and the KUnit cases above. Hitting either correlator bug
needs PHYP to return a bad correlator, so neither was reproduced on
hardware. Tested with KUnit on qemu pseries (ppc64le), and on a POWER10
LPAR with a ping flood and MTU changes under traffic. No kernel
selftests cover ibmveth.
Fixes: 2c91e2319ed9 ("net: ibmveth: Reset the adapter when unexpected states are detected")
Fixes: 860f242eb534 ("[PATCH] ibmveth change buffer pools dynamically")
Signed-off-by: Mingming Cao <mmc@linux.ibm.com>
Link: https://patch.msgid.link/20261013182926.30417-5-mmc@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
ibmveth_remove() cancels the reset work before unregister_netdev(),
but NAPI keeps running until unregister closes the device and can
queue the reset again, on an interrupt enable failure, a bad
free_map entry or a bad RX slot. The reset can then run on the
adapter after free_netdev(), or reopen the device during unregister.
Use disable_work_sync(), which waits for a running reset and keeps
the work from being queued again. A bad RX slot also makes poll
spin, which can stall unregister; a later patch in this series
fixes that.
Found in review of the ibmveth multi-queue RX series and confirmed by
code inspection; it was not reproduced. Tested on a POWER10 LPAR with
unbind and bind cycles under traffic. No kernel selftests cover ibmveth.
Fixes: 2c91e2319ed9 ("net: ibmveth: Reset the adapter when unexpected states are detected")
Signed-off-by: Mingming Cao <mmc@linux.ibm.com>
Link: https://patch.msgid.link/20261013182926.30417-4-mmc@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
ibmveth_change_mtu(), veth_pool_store(), ibmveth_set_csum_offload()
and ibmveth_set_tso() call close() and open() directly. If open() fails,
NAPI is left disabled while IFF_UP stays set, so the next close()
(ifdown, unregister or another reconfiguration) calls napi_disable()
again and waits forever with RTNL held. Networking and shutdown
hang; only a reboot recovers. ethtool -L in that state also wakes
queues that have no TX buffer and dereferences NULL in
ibmveth_start_xmit().
Any open() failure on those paths triggers it, for example an
allocation failure on an MTU change to jumbo frames.
Track a successful open in adapter->opened. close() returns early
when it is clear, and set_channels() checks it instead of IFF_UP.
The open() error-path leaks were fixed separately in net by
commit af0524bf4ce1 ("ibmveth: h_free logical LAN on open-fail after
register") and commit 84bec0bf0352 ("ibmveth: fix TX LTB and filter
unwind on open-fail"), which are now in net-next too, so a failed
open() no longer leaves TX buffers or the logical LAN registration
behind for the early return to skip.
Found in review of the ibmveth multi-queue RX series and confirmed by
code inspection. Tested on a POWER10 LPAR with ibmveth_open() forced to
fail by a test-only module parameter (not part of this patch): 'ip link
set dev eth1 mtu 9000' fails, then 'ip link set dev eth1 down' returns
at once and 'ip link set dev eth1 up' recovers the interface. No kernel
selftests cover ibmveth.
Fixes: 860f242eb534 ("[PATCH] ibmveth change buffer pools dynamically")
Signed-off-by: Mingming Cao <mmc@linux.ibm.com>
Link: https://patch.msgid.link/20261013182926.30417-3-mmc@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
ibmveth_poll_controller() runs RX replenish outside NAPI and without
a lock, racing NAPI's replenish on another CPU. Both can fill the
same slot, so an skb and its DMA mapping leak and PHYP can write
into an unmapped buffer. netpoll calls it from netconsole and from
netpoll-enabled bonds.
ibmveth_open() also enables NAPI before the RX resources exist.
ibmveth_change_mtu(), veth_pool_store(), ibmveth_set_csum_offload()
and ibmveth_set_tso() call close() and open() directly, so while
open() is still setting up, netpoll and the direct ibmveth_interrupt()
calls can replenish NULL pools and read freed memory.
Remove the callback, as Eric Dumazet did for many drivers after
commit ac3d9dd034e5 ("netpoll: make ndo_poll_controller() optional"),
including ibmvnic in commit 0c3b9d1b37df ("ibmvnic: remove
ndo_poll_controller"). netpoll then polls NAPI itself with budget 0.
napi->poll_owner serializes that with NAPI, but not with a NAPI poll
that was already running when netpoll was set up, so skip RX
replenish at budget 0, which netpoll uses for TX only. TX completes
synchronously, so ibmveth_poll() has nothing else to do for netpoll.
Enable NAPI just before request_irq(), once everything
ibmveth_poll() touches exists.
Found in review of the ibmveth multi-queue RX series and confirmed by
code inspection of poll_one_napi() and the direct close()/open()
callers; neither race was reproduced. Tested on a POWER10 LPAR with
netconsole over ibmveth: a ping flood (678,470 packets, no loss) during
a printk flood, and MTU changes and buffer pool toggles under traffic,
with no warnings. No kernel selftests cover ibmveth.
Fixes: 6b4223748895 ("[PATCH] ibmveth: Add netpoll function")
Fixes: bea3348eef27 ("[NET]: Make NAPI polling independent of struct net_device objects.")
Signed-off-by: Mingming Cao <mmc@linux.ibm.com>
Link: https://patch.msgid.link/20261013182926.30417-2-mmc@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull scheduler updates from Ingo Molnar:
"Kconfig updates:
- Simplify PREEMPT_DYNAMIC (Mark Rutland)
Fair scheduler updates:
- Remove redundant RUN_TO_PARITY check (Elif Topuz)
- Declare augmented callbacks per field, fix
rb_add_augmented_cached() descent (Yiwei Lin, Peter Zijlstra)
- Restart fair hrtick after same-task repicks (Shubhang Kaushik)
- Improve the scheduling latency of short slice tasks (Vincent
Guittot)
Deadline/RT scheduler updates:
- Check start_dl_timer expiry with ktime_before() (Liang Hao)
- irq_work: CPU-hotplug improvements on PREEMPT_RT (Sebastian Andrzej
Siewior)
Energy-aware scheduling updates:
- Implement the steal_governor, introduce preferred CPUs and
steal-driven vCPU backoff (Shrikanth Hegde)
Multi-processor load-balancing updates:
- Enable preferred SMT siblings on NVIDIA Olympus (Andrea Righi)
- Randomize equally shallow idle CPU picks (Christian Loehle)
- Remove redundant core_sched_seq (Hui Su)
Cache-aware scheduling updates:
- Avoid publishing partial LLC utilization (Jemmy Wong)
NUMA-balancing updates:
- Reset NUMA fault locality after scan period update (Eric Kim)
Proxy execution updates:
- Ongoing work to implement sleeping owner handling for proxy
execution (John Stultz, Vasily Gorbik)
- Preparatory steps to make sched_ext compatible with proxy execution
(Andrea Righi)
Scheduler infrastructure updates & fixes:
- Remove the RCU wait from PSI trigger destruction (Shakeel Butt)
- Avoid modifying wait-entry on failed priority registration
(Hui Su)
- Use the new static key API for sched_feat (Hongyan Xia)
- Convert paravirt_steal to new static key APIs (Hongyan Xia)
- cputime: Don't account idle time twice after dyntick-idle
(Stian Halseth)
Scheduler debugging updates:
- Set TIF_NEED_RESCHED before calling __trace_set_need_resched()
(Sechang Lim)
- Fix context analysis errors in non-preferred CPU push (Shrikanth
Hegde)
Misc cleanups and fixes by Christian Loehle, Shubhang Kaushik,
Thomas Huth and Vladimir Zapolskiy"
* tag 'sched-core-2026-10-18' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (64 commits)
sched: Replace nr_iowait_cpu() with a bool accessor
Revert "sched/fair: Remove dead code on enqueue_task_fair()"
sched/cache: Avoid publishing partial LLC utilization
sched/cputime: Don't account idle time twice after dyntick-idle
sched/psi: Remove the RCU wait from trigger destruction
sched/eevdf: Remove redundant RUN_TO_PARITY check
sched/wait: Avoid modifying entry on failed priority registration
rbtree_test: Use rb_add_augmented_cached() for the cached augmented test
rbtree: Update augmented data on the way down in rb_add_augmented_cached()
rbtree: Declare augmented callbacks per field with RB_AUG()
rbtree_test: Use rb_add() and rb_add_cached() for the basic tests
smpboot: Don't park the thread if work is pending
irq_work: Flush lazy work CPU down on PREEMPT_RT
irq_work: Update a comment regarding CPU hotplug invocation
sched/topology: Add asymmetric SMT packing override
sched/fair: Honor asymmetric SMT priority in idle selection
sched: Set TIF_NEED_RESCHED before calling __trace_set_need_resched()
sched/core: Fix context analysis errors in non-preferred CPU push
virt/steal_governor: Enable the driver
virt/steal_governor: Implement steal_governor policy loop
...
|
|
The "threshold" ethtool statistic reports a single TX DMA threshold for
the whole device. However, since commit d62a107a4f15 ("net: stmmac:
prepare dma interrupt treatment for multiple queues"), a single TX DMA
threshold per device doesn't make sense anymore, as each individual queue
that underflows gets its threshold increased, so the queues are out of
sync.
To make the reporting accurate, remove it and report the threshold of
each TX queue instead, as "qN_tx_threshold".
Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
Link: https://patch.msgid.link/20261013114503.57487-3-ovidiu.panait.rb@renesas.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Commit 3a6c12a0c6c3 ("net: stmmac: bump tc when get underflow error from
DMA descriptor") made dwmac4 raise the DMA threshold of the queues that
report TX underflows. This is done by incrementing a module global
parameter 'tc' by 64 on each underflow.
This leads to inconsistent TX DMA thresholds between queues and causes
issues on platforms with multiple stmmac controllers, as 'tc' is shared
by all of them. Once 'tc' goes over 256 the bumping stops, and queues
that did not underflow before are left at the initial threshold.
On the Renesas RZ/V2H platform, which has two dwmac4 controllers, we
observed sporadic iperf3 TCP TX failures:
iperf3 -c <server> -t5 --bind-dev end1
...
[ 5] 0.00-5.00 sec 1.00 MBytes 1.68 Mbits/sec 87 sender
[ 5] 0.00-5.00 sec 768 KBytes 1.26 Mbits/sec receiver
This happens because the TX queues of end1 were underflowing on a large
fraction of the packets, but the DMA TX threshold was never raised from
the default of 64 bytes. The threshold was not raised because end0
had underflowed first and had already pushed 'tc' past 256. Which
controller is affected depends on which one underflows first.
To fix this, make the TX DMA threshold per queue instead of global.
Each time an underflow happens on a queue, its TX DMA threshold gets
incremented, without affecting other queues or controllers. With this
change, 'tc' is only used as the initial value, and the RX threshold
is no longer bumped together with the TX one, as TX underflows have
nothing to do with the RX side.
Fixes: 3a6c12a0c6c3 ("net: stmmac: bump tc when get underflow error from DMA descriptor")
Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/20261013114503.57487-2-ovidiu.panait.rb@renesas.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 TDX updates from Dave Hansen:
"There are two high-level things going on here.
First, TDX host systems currently consume ~0.4% of physical memory for
their own memory metadata. This is all-or-nothing; you either pay the
0.4% or can not use TDX. A new TDX module feature (Dynamic PAMT)
allows this metadata to be allocated for 2MB of host memory at a time.
This, of course, saves precious DRAM when TDX utilization is low on a
host.
Second, the TDX ABI has fixed-size "quotes" that are passed around
during attestation operations. These 128k buffers are far too small
for post-quantum cryptography where the quotes grow substantially. The
TDX module now has the ability to enumerate the sizes of the quote
buffers. Plumb the new size enumeration into the kernel"
* tag 'x86_tdx_for_7.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
virt: tdx-guest: Make the Quote buffer size dynamic
x86/tdx: Add a helper to query maximum Quote size
virt: tdx-guest: Add a helper for the Quote buffer size
virt: tdx-guest: Calculate the Quote buffer size safely
virt: tdx-guest: Give the Quote buffer an explicit type
x86/tdx: Take the Quote buffer as a generic pointer
x86/tdx: Restrict attestation exports to the tdx-guest driver
virt: tdx-guest: Remove unused and confusing function argument
x86/virt/tdx: Formalize SEAMCALL leaf version encoding support
Documentation/x86: Add documentation for TDX's Dynamic PAMT
x86/virt/tdx: Enable Dynamic PAMT
KVM/TDX: Get/put PAMT pages when (un)mapping private memory
x86/virt/tdx: Add APIs to support Dynamic PAMT ops from KVM's fault path
KVM/TDX: Allocate PAMT memory for TD and vCPU control structures
x86/virt/tdx: Handle multiple callers in tdx_pamt_get/put()
x86/virt/tdx: Allocate refcounts for Dynamic PAMT memory
x86/virt/tdx: Add __tdx_pamt_get/put() helpers
x86/virt/tdx: Allocate page bitmap for Dynamic PAMT
x86/virt/tdx: Simplify PAMT layout calculation
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 SEV updates from Borislav Petkov:
- Report in sysfs which SEV confidential computing features are enabled
in the environment so that related components like a SVSM can query
them and do appropriate configuration
- Add support for a new AMD SEV instruction called RMPOPT which can be
used to reduce the performance overhead of doing confidential guests'
page ownership verification and the like. Work by Ashish Kalra
* tag 'x86_sev_for_v7.4_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/sev: Report MSR_AMD64_SEV in sysfs
x86/sev: Do RMP optimizations on SNP guest shutdown
x86/sev: Perform RMP optimizations asynchronously
x86/sev: Initialize RMPOPT configuration MSRs
x86/sev: Disable CPU hotplug while SNP is active
x86/cpufeatures: Add X86_FEATURE_RMPOPT feature flag
|
|
qcom_pcie_ecam_host_init() unconditionally initializes the DesignWare
internal MSI controller and sets use_imsi_rx, irrespective of whether an
external MSI controller is described for the host bridge. When an 'msi-map'
DT property is present, MSI interrupts are handled by the mapped external
MSI controller. Initializing the internal iMSI-RX domain in this case is
unnecessary.
Set use_imsi_rx based on the presence of 'msi-map' in DT and initialize the
DesignWare MSI host only when iMSI-RX is required.
Signed-off-by: Ayiluri Naga Rashmi <ayiluri.rashmi@oss.qualcomm.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260917-skipmsi_forlpi-v1-1-14a4932a4311@oss.qualcomm.com
|
|
Add test ensuring that network device stats are updated appropriately
when a previously pushed packet fails to send during a subsequent push.
Signed-off-by: James Lee <james@codeconstruct.com.au>
Link: https://patch.msgid.link/20261014-dev-mctp-usb-lib-test-v3-7-ee5bc3ea1db1@codeconstruct.com.au
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Add tests for the transmit path, where MCTP packets are handed to
outgoing USB transfer data. Testing a spanning transfer that is expected
to succeed, the failure paths when sends fail, and large sequential
sends.
Signed-off-by: James Lee <james@codeconstruct.com.au>
Link: https://patch.msgid.link/20261014-dev-mctp-usb-lib-test-v3-6-ee5bc3ea1db1@codeconstruct.com.au
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The if statement testing rx's allocation is unneeded.
Signed-off-by: James Lee <james@codeconstruct.com.au>
Link: https://patch.msgid.link/20261014-dev-mctp-usb-lib-test-v3-5-ee5bc3ea1db1@codeconstruct.com.au
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Add rx tests without spanning, covering cases where a packet is shorter
than allowed without spanning, isn't completed within one submission.
Fully cover rx functions except for memory allocation failures and
trivial functions.
Signed-off-by: James Lee <james@codeconstruct.com.au>
Link: https://patch.msgid.link/20261014-dev-mctp-usb-lib-test-v3-4-ee5bc3ea1db1@codeconstruct.com.au
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Add tests where the length field of the USB transport header is below
the minimum value, and where the DMTF ID is invalid.
Signed-off-by: James Lee <james@codeconstruct.com.au>
Link: https://patch.msgid.link/20261014-dev-mctp-usb-lib-test-v3-3-ee5bc3ea1db1@codeconstruct.com.au
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Add test covering every possible split of a packet's headers between
transfers and remove parameterized tests that are now covered.
Signed-off-by: James Lee <james@codeconstruct.com.au>
Link: https://patch.msgid.link/20261014-dev-mctp-usb-lib-test-v3-2-ee5bc3ea1db1@codeconstruct.com.au
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Add parameterized tests to cover worst case scenarios for packet
splitting and length.
Signed-off-by: James Lee <james@codeconstruct.com.au>
Link: https://patch.msgid.link/20261014-dev-mctp-usb-lib-test-v3-1-ee5bc3ea1db1@codeconstruct.com.au
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
When the first port has a non-Ethernet type, team_setup_by_port()
copies port_dev->type to the team device while netdev_priv() of the
team device still holds a struct team. Several L2 stacks identify their
devices by dev->type alone and then access type specific data that the
team driver never sets up:
- CAN protocols rely on the CAN mid-layer private data (ml_priv)
- IEEE 802.15.4 code dereferences ieee802154_ptr and the mlme ops in
ml_priv
- the 6LoWPAN netdev notifier writes through lowpan_dev(dev) on
NETDEV_DOWN and reads it on NETDEV_UP/NETDEV_CHANGE
Enslaving such a device (e.g. vxcan, wpan0, lowpan0) therefore leads to
NULL pointer dereferences or to writes into struct team.
This is the same problem that syzbot reported for the bonding driver
with a vxcan device enslaved to a bond master, which crashed in
can_rx_unregister() and was fixed by commit 8ba68464e478 ("bonding:
refuse to enslave CAN devices"). The team driver has the same gap.
Reject ARPHRD_CAN, ARPHRD_IEEE802154, ARPHRD_IEEE802154_MONITOR and
ARPHRD_6LOWPAN devices in team_port_add().
Link: https://lore.kernel.org/all/b58d98e0-8fe3-4e4e-b8a5-c1c7e647ccca@hartkopp.net/
Link: https://syzkaller.appspot.com/bug?extid=8ed98cbd0161632bce95 # bonding splat
Fixes: 1d76efe1577b ("team: add support for non-ethernet devices")
Signed-off-by: Jiale Yao <yaojiale02@163.com>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20261019155407.61487-1-socketcan@hartkopp.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
MFGD register queries can exhaust EMAD retries and leave Mellanox
Spectrum switches stuck during boot or shutdown when running OpenWrt
built with GCC 15.
An example failure is shown below with the second line wrapped:
EMAD retries (5/5) (tid=9b544fc100001f35)
EMAD reg access failed (tid=9b544fc100001f35,reg_id=90f0(mfgd),
type=query,status=0(operation performed))
On an SN2100, the failure occurs during driver teardown on reboot.
On an SN3420, it occurs while probing mlxsw_spectrum during boot.
The register query API transmits the supplied payload to the device
before replacing it with the response. Both MFGD callers pass an
uninitialized stack buffer, so the request contains arbitrary register
field values and reserved bits. This makes the request depend on stack
contents and compiler code generation.
Initialize both MFGD query buffers in the firmware fatal event
configuration and reporter test paths. The initialization has been
confirmed to eliminate the boot and shutdown hangs on both switches.
The subsequent read-modify-write still preserves the other fields
returned by the device.
Also initialize the FORE fan fault query and the MOGCR mirroring policer
base query, which pass entirely uninitialized payloads. Restore the MTMP
query initialization in the temperature history reset path, where only
the slot and sensor index fields are set before querying the register.
This follows commit 5b0907407e7f ("mlxsw: core: Zero payload buffers for
couple of registers"), which initialized other query payloads after a
firmware field length bug caused firmware to consume uninitialized data.
Tested with firmware 2020.1148 and with 2016.3900 from linux-firmware.
Fixes: 7d83ee111008 ("mlxsw: core: Introduce fw_fatal health reporter")
Fixes: 2c6a33cd334b ("mlxsw: core: Extend hwmon interface with fan fault attribute")
Fixes: 4039504e6a0c ("mlxsw: spectrum_span: Allow setting policer on a SPAN agent")
Fixes: b890ad418e1f ("mlxsw: core_hwmon: Extend internal structures to support multi hwmon objects")
Cc: stable@vger.kernel.org
Signed-off-by: Til Kaiser <mail@tk154.de>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20261014173117.26305-1-mail@tk154.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Switch from <module>-objs to <module>-y to eliminate ifdefs and simplify
conditional object list construction. Drop the obsolete trailing
comment.
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Reviewed-by: Alvin Šipraga <alvin.sipraga@analog.com>
Link: https://patch.msgid.link/20261019-realtek_mkf-v1-1-3246a77d5782@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The Acer Nitro AN16-41 supports the Predator Sense v4 platform profile,
hwmon sensors and fan control, but currently needs the predator_v4
module parameter to expose them. Add a DMI quirk for it, reusing the
Nitro AN515-58 quirk entry since the feature set is the same.
Tested on BIOS V1.03: all five platform profiles are offered by the
firmware and switching them changes the fan curve, both fan speeds and
the temperature sensors read correctly, and pwm1/pwm2 work in custom,
maximum and automatic mode.
Assisted-by: LLM
Signed-off-by: Dennis Nilsson <kontakt@dennisnilsson.se>
Link: https://patch.msgid.link/20261017-acer-nitro-an16-41-v1-2-c2e7a0ee7303@dennisnilsson.se
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
On some Nitro models using the Predator Sense v4 interface, such as the
Nitro AN16-41, the mode key raises WMID_GAMING_TURBO_KEY_EVENT with
key_num 0x4 instead of 0x5. The driver routes key_num 0x4 to
acer_toggle_turbo(), which returns immediately on machines without
ACER_CAP_TURBO_LED because WMID_gaming_get_u64() rejects the missing
capability, so the key press is silently dropped.
Only toggle turbo for key_num 0x4 when the turbo LED capability is
present, and cycle the platform profile otherwise. Machines with the
turbo quirk keep their current behaviour, and on every other machine
key_num 0x4 was previously a no-op.
Tested on an Acer Nitro AN16-41 (BIOS V1.03), where the mode key sends
the event payload 07 04 01 00 and now cycles the platform profile.
Assisted-by: LLM
Signed-off-by: Dennis Nilsson <kontakt@dennisnilsson.se>
Link: https://patch.msgid.link/20261017-acer-nitro-an16-41-v1-1-c2e7a0ee7303@dennisnilsson.se
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Currently, hp_wmi_hwmon_is_visible() checks whether fan RPM queries
succeed before exposing fan1_input and fan2_input, but pwm1_enable
remains visible always, even when fan support is unavailable. On some
devices, such as certain Omnibook models, the firmware does not provide
functional WMI fan methods. Exposing pwm1_enable on these devices can
mislead userspace and cause fan mode changes to fail.
Additionally, some firmware implementations provide stub methods
that return an all-zero buffer instead of an error. In this case,
hp_wmi_get_active_fan_speed() and hp_wmi_get_fan_speed() can report 0
RPM even when the fan is physically spinning.
Use the result of fan count query (fetched from firmware once in
hp_wmi_setup_fan_settings(), and cached in hwmon private data) to
determine whether fan related attributes should be exposed.
The fan count query can have the following outcomes:
* Negative: The WMI query failed. Other fan-related queries are also
expected to fail, so disable fan support.
* Zero (stub firmware): The methods return zero-filled responses without
providing functional fan support, so disable fan support.
* Zero (genuine firmware): No fans are exposed through WMI, so disable
fan support.
* Positive (1 or 2): Firmware reports one or more fans, so allow fan
support. Per-channel RPM queries continue to determine which
individual fan input attributes are exposed.
When fan support is unavailable, hide the fan and PWM attributes and
skip applying the initial fan settings.
Tested on: HP OmniBook 5 Laptop 16-ag1xxx (board: 8DF4)
Tested-by: Lorenzo Collevecchio <lorenzocollevecchio17@gmail.com>
Reported-by: Lorenzo Collevecchio <lorenzocollevecchio17@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=222138
Signed-off-by: Krishna Chomal <krishna.chomal108@gmail.com>
Link: https://patch.msgid.link/20261017132421.279522-1-krishna.chomal108@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
mlx5 couples HW-GRO with tcp-data-split. If a user sets rx-gro-hw on ->
tcp-data-split on -> rx-gro-hw off, the driver will leave HW-GRO on.
mlx5e_ethtool_set_tcp_data_split() calls netdev_update_features() when
tcp-data-split goes from enabled to disabled in case HW-GRO needs to be
released. mlx5e_fix_features() reads the new HDS config from
dev->cfg_pending, so HW-GRO is released before all ring parameters are
validated.
If the subsequent call to mlx5e_ethtool_set_ringparam() fails, the
ethtool core discards the pending change and reports tcp-data-split
enabled. The device is no longer splitting, and subsequent ring changes
are blocked.
Move the call to netdev_update_features() after
mlx5e_ethtool_set_ringparam() exits successfully.
The issue was discovered by manual code inspection during review of
a change that stops mlx5 users from disabling tcp-data-split. It was
reproduced on a ConnectX-7 with ethtool alone.
Steps to reproduce:
ethtool -K eth0 rx-gro-hw on
ethtool -G eth0 tcp-data-split on
ethtool -K eth0 rx-gro-hw off # HW-GRO kept on for tcp-data-split
ethtool -G eth0 tcp-data-split off rx 1 # de-sync driver & kernel state
netlink error: mlx5_core: rx (1) < min (16)
netlink error: Invalid argument
ethtool -G eth0 rx 1024 # valid ring changes are now blocked
netlink error: mlx5_core: TCP-data-split is not supported when GRO HW is disabled
netlink error: Invalid argument
This is not a terminal state, users can recover by setting rx-gro-hw on.
With the fix, the failing ringparam set leaves rx-gro-hw on and later
ring changes succeed.
Fixes: 46bcce5dfd33 ("net/mlx5e: Support ethtool tcp-data-split settings")
Reported-by: Björn Töpel <bjorn@kernel.org>
Closes: https://lore.kernel.org/87se2grw3d.fsf@all.your.base.are.belong.to.us/
Signed-off-by: Dimitri Daskalakis <daskald@meta.com>
Reviewed-by: Björn Töpel <bjorn@kernel.org>
Reviewed-by: Nimrod Oren <noren@nvidia.com>
Acked-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20261017005401.1582755-1-dimitri.daskalakis1@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
MANA doesn't support byte queue limits, so each TX queue can hold 256
WQEs by default, and up to 16384, of up to 64 KB TSO packets, before the
qdisc layer sees any backpressure. This adds latency to all the flows
sharing a queue, and defeats AQM qdiscs such as fq_codel, which rely on
BQL to keep the driver queues short.
Report the bytes queued and completed to BQL, except for the XDP_TX and
XDP_REDIRECT frames. These share the SQs, but bypass the qdisc and are
sent even when the queue is stopped, so BQL can't hold them back.
Counting them would let sustained XDP traffic keep the queue stopped,
starving the stack, and the TX watchdog would then either fire while the
completions still arrive, or, if the XDP sends refreshed trans_start,
not fire when the completions stop. The XDP SKBs are marked in their
skb->cb, next to the WQE size, so that their completions are skipped as
well.
Reset the BQL state when destroying the queues, once their NAPI is
disabled, since the SKBs still pending after a drain timeout are freed
without being completed.
Lost TX completions can now stop a queue sooner: it also stops when the
bytes in flight exceed the BQL limit, not only when the SQ is full, and
the limit may never grow enough to cover the lost bytes. This includes
the completions skipped by the WARN_ON_ONCE() early returns in
mana_poll_tx_cq(), which already leak SQ space: completing the SKBs
already freed there wouldn't reliably balance BQL, since
mana_gd_poll_cq() has already consumed the CQEs of the rest of the
batch. The TX watchdog then fires, as nothing refreshes the trans_start
of a queue stopped by BQL, and its handler resets the queues along with
their BQL state. The exception, as before this patch, is XDP traffic
keeping the SQ full: each XDP send then stops the queue again,
refreshing its trans_start.
Tested on two Standard_D16ds_v6 Azure VMs in a proximity placement
group, where the throughput is capped at 10.6 Gbps, with the DUT
alternately booting net-next (c1c1f0a31712) with and without this patch
applied.
The throughput stays at the cap with 1, 8 and 64 TCP flows, and the idle
TCP_RR latency doesn't change (p50 of 47 us with vs. without the patch).
With 16 senders of 64-byte UDP packets, the DUT sends 3.7 to 4.0 Mpps
without the patch and 3.7 to 4.1 Mpps with it. With bulk TCP flows
sharing the queues, the netperf TCP_RR latency drops (medians of 6
runs):
16 queues, 64 flows: p50 4649 -> 2182 us, p99 5621 -> 2677 us
1 queue, 8 flows: p50 2554 -> 418 us, p99 2723 -> 624 us
The standing queue moves from the SQs to fq_codel, which now drops
packets: about 2500 qdisc drops and 88K TCP retransmissions per 48 s run
with 64 flows, against at most 29 retransmissions before. The
retransmissions are about 0.2% of the segments sent. The TCP_RR flows
lose no packets, and the packets of the bulk flows are dropped before
they reach the wire, so the goodput changes by less than 0.01%.
Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Link: https://patch.msgid.link/20261013214937.145312-1-hamzamahfooz@linux.microsoft.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
marvell_config_intr() rewrites the whole interrupt enable register, so
the config_intr call from phy_init_hw() on resume silently cleared
WOL_EIE on the 88E1318S and 88E1510: m88e1318_get_wol() still reported
WAKE_MAGIC, but a matched magic packet was no longer routed to INTn and
the board did not wake.
Bit 7 of that register is WOL_EIE only on these two PHYs; on others,
such as the 88E1111, it enables a FIFO error interrupt. So give the
88E1318S and 88E1510 their own config_intr and handle_interrupt, and
leave the shared callbacks unchanged.
m88e1318_set_wol() now records whether WoL is enabled, and both it and
the new config_intr derive WOL_EIE from that state under the MDIO bus
lock. WOL_EIE stays set across config_intr while WoL is enabled, except
when the PHY has an interrupt line and interrupts are being disabled,
as in phy_free_interrupt(): INTn is then the PHY IRQ, and nothing would
read IEVENT after free_irq() to release it. The bit is set again once
interrupts are re-enabled. phy_probe() still clears a WOL_EIE left by a
previous boot, since WoL starts out disabled. The new handler also
claims WoL events, so they do not go unacknowledged when the PHY IRQ is
in use.
Helios4 (Armada 388, 88E1512), 7.2.9. With this patch WOL_EIE stays set
over 3 link down/up cycles, "wol d" clears it, and a magic packet on a
running board is a handled interrupt. Without it, WOL_EIE is lost on the
first down/up, survives "wol d", and the magic packet is an unhandled
interrupt.
Fixes: 3871c3876f80 ("mv643xx_eth with 88E1318S: support Wake on LAN")
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Tested-by: Igor Velkov <iav@iav.lv>
Link: https://patch.msgid.link/20261014194818.11640-2-rosenp@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The fan worker changes the direction of both GPIOs and schedules its
next run. Its managed cancellation action is registered before the GPIOs
are acquired, so devres releases the GPIOs before cancelling the work. A
running worker can therefore change a GPIO after the driver has released
it.
Register the work cancellation action after both GPIO acquisitions. This
makes devres cancel and drain the worker before releasing either GPIO.
No work has been queued yet if GPIO acquisition or action registration
fails.
This issue was identified as part of our ongoing research while
reviewing kernel code.
Fixes: b82a7b018b93 ("platform/x86: gpd pocket fan: Clean-up by using managed work init")
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
Link: https://patch.msgid.link/179229442299.3956787.17526066623947466315.gpd-pocket-fan@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The RX walk in axienet_dma_bd_release() stops at the first descriptor
without an skb, assuming that such a slot and all after it were never
filled. That holds on the axienet_dma_bd_init() error path, but not once
the ring has been running: when axienet_rx_poll() fails to allocate or
map a replacement buffer it leaves the slot it emptied with a NULL skb,
in the middle of a populated ring, until a later poll refills it.
Closing the interface before then leaks the skb and the streaming DMA
mapping of every descriptor after that slot, which can be most of the
ring, and is most likely under memory pressure.
The walk also frees each skb before unmapping it. With swiotlb, the
DMA_FROM_DEVICE unmap copies the bounce buffer back into the skb data
that was just freed, and on non-coherent platforms it invalidates cache
lines that may already belong to a new owner.
Skip empty slots instead of stopping at the first one. An emptied slot
still has a non-zero cntrl but its buffer is already unmapped, so the
skip has to cover the unmap too, which it does by coming before it.
Then unmap before freeing, as axienet_rx_poll() does.
This was reported by the Sashiko AI review bot.
Tested on the AXI Ethernet MAC of an ADVA TimeCard X2 (PCIe card, with
the built-in AXI DMA): traffic passes after each of ten down/up cycles,
each running axienet_dma_bd_release(), so the unmap-then-free order is
exercised on every buffer. A failed RX refill was not reproduced, so
the skip over an empty slot was not exercised.
Fixes: f26667a373f3 ("net: axienet: Fix DMA descriptor cleanup path")
Fixes: 7a7d340ba4d9 ("net: axienet: fix RX ring refill allocation failure handling")
Signed-off-by: Sagi Maimon <maimon.sagi@gmail.com>
Link: https://patch.msgid.link/20261015084743.1798326-1-maimon.sagi@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
