| Age | Commit message (Collapse) | Author |
|---|
|
The RX rings and the shared NAPI are carried by an internal "dummy" netdev
(eth->dummy_dev). mtk_probe() creates that dummy device, and adds the
shared tx/rx NAPI to it, only after the MAC netdevs have been registered.
That order has been there since the MT7623 support was added and leaves a
window in which the netdevs are visible to the network core before the
shared NAPI and the dummy device exist.
If anything brings the first netdev up during that window (e.g. netifd
opening the WAN link the instant the interface is registered), the
first-open path runs without them. On NETSYS v2 and later SoCs
mtk_rx_alloc() -> __xdp_rxq_info_reg() then dereferences eth->dummy_dev ==
NULL:
WARNING: CPU: ... Missing net_device from driver
in net/core/xdp.c and mtk_open() fails with -ENODEV. On NETSYS v1 SoCs
(MT7621/MT7622/MT7623/MT7629) there is no page pool, so the same open
instead calls napi_enable() on a napi_struct that netif_napi_add() has not
initialised yet and dereferences a NULL napi->dev.
Allocate the dummy netdev and add the shared tx/rx NAPI to it before the
register_netdev() loop. Both the dummy-allocation failure and a
register_netdev() failure now unwind through mtk_unreg_dev(), which
unregisters the net_device notifiers and the netdevs registered so far,
stopping a concurrently-opened netdev (ndo_stop) and its NAPI before the
dummy carrier is freed.
A netdev that opened during the window can also have queued the
frame-engine reset worker (via the tx watchdog or phylink), so the probe
error path now cancels eth->pending_work before freeing the shared state,
as mtk_cleanup() already does on remove.
Fixes: 656e705243fd ("net-next: mediatek: add support for MT7623 ethernet")
Signed-off-by: Sandeep Haemoon <sandeeph@loljews.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/patch-e52c13380b0768fec63af04c80e4b487@loljews.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
It is possible for eb_relocate_parse_slow() to call kvfree() on
entries outside the original exec array during following
scenario inside eb_relocate_parse_slow():
1) eb_copy_relocations() allocates as many as eb->buffer_count
copies for exec entries;
2) eb_parse() appends up to two VMAs, right after incrementing
eb->buffer_count;
3) cleanup under "out" label uses this incremented buffer_count
to release relocation pointers from exec array via kvfree(),
not from VMA array.
To amend this problem, ensure that relocation cleanup uses the
original exec object count, excluding the VMAs appended by the
command parser.
Fixes: 8e4ba491b0ba ("drm/i915: Parse command buffer earlier in eb_relocate(slow)")
Signed-off-by: Krzysztof Karas <krzysztof.karas@intel.com>
Assisted-by: GitHub-Copilot:gpt-6-astra
Cc: stable@vger.kernel.org # 5.10+
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patch.msgid.link/20260911061145.3535489-1-krzysztof.karas@intel.com
|
|
Detect the carrier state on the w5500 Ethernet controller using the
Link Status bit from the PHY Configuration register (PHYCFGR).
On w5100/w5200, which lack this register, get_link() is not implemented
and the carrier state is not reported (netif_carrier_(on|off) is not
called).
For the w5500, add an optional interrupt, wired to the LINKLED pin of
the device, to detect link status changes with a read of the PHYCFGR
register and update of the carrier state with netif_carrier_(on|off).
If this interrupt is not set in the DT binding, get_link() is not
implemented and the carrier state is not reported
(netif_carrier_(on|off) is not called).
The interrupt handler and the PHYCFGR register readings are
synchronized using a mutex.
A few changes are also brought for the bring-up/teardown
synchronization:
- The net device is registered last in the probe() function so no
operation can be performed before the probing is finished
- The net device is unregistered first in remove()
- dev_name is now used instead of netdev_name
- w5100_stop() calls cancel_work_sync() and flush_work() to make sure
there is no race condition or unfinished work
- w5100_suspend() calls w5100_stop()
- w5100_resume() calls w5100_open()
- The main irq is not automatically enabled in w5100_probe() but in
w5100_open() and disabled in w5100_stop()
Commit dacf281771a9 ("w5100: remove unused gpio link detection")
dropped the link_gpio/link_irq handling on the grounds that no
devicetree user passed a "link" gpio at the time and that it used the
old gpio interface.
This isn't a plain revert of that removal: link detection is now done
using a second interrupt rather than a gpio with a documented DT
binding.
Set the WIZNET entry as DRIVER and add drivers/net/ethernet/wiznet in
MAINTAINERS file.
Signed-off-by: Arthur Crepin Leblond <arthur@marmottus.net>
Fixes: dacf281771a9 ("w5100: remove unused gpio link detection")
Link: https://patch.msgid.link/20260924-wiznet-link-gpio-v11-3-42a332517b30@marmottus.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Paul reported kernel splat:
[ 0.000000] TRACE EVENT ERROR: Event mtu3_gadget_ep_set_halt has double dereference in TP_printk: &REC->gpd_ring->dma
[ 0.000000] ------------[ cut here ]------------
[ 0.000000] Event mtu3_gadget_ep_set_halt has double dereference in TP_printk: &REC->gpd_ring->dma
[ 0.000000] WARNING: kernel/trace/trace_events.c:420 at test_double_dereference+0x144/0x14c, CPU#0: swapper/0/0
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.3.0-rc1 #15247 PREEMPT
[ 0.000000] Hardware name: linux,dummy-virt (DT)
[ 0.000000] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 0.000000] pc : test_double_dereference+0x144/0x14c
[ 0.000000] lr : test_double_dereference+0x144/0x14c
[ 0.000000] sp : ffffc80aa7633bf0
[ 0.000000] x29: ffffc80aa7633bf0 x28: ffffc80aa7c0f047 x27: 000508b58019388f
[ 0.000000] x26: 0000000000000003 x25: 0000000000000007 x24: ffffc80aa5fceff8
[ 0.000000] x23: ffffc80aa7c0f05a x22: ffffc80aa64edfe8 x21: ffffc80aa7c0fce8
[ 0.000000] x20: ffffc80aa7c0f047 x19: 0000000000000013 x18: 0000000000000001
[ 0.000000] x17: 6572656420656c62 x16: 756f642073616820 x15: 746c61685f746573
[ 0.000000] x14: 0000000000000000 x13: ffff000139d90000 x12: 0000000000000045
[ 0.000000] x11: 00000000000000cf x10: ffff00013f546428 x9 : ffff000139d90000
[ 0.000000] x8 : 3fffffffffffc000 x7 : 0000000000000001 x6 : 0000000000000001
[ 0.000000] x5 : ffff00013f4e6440 x4 : 0000000000000000 x3 : 0000000000000000
[ 0.000000] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffc80aa764a700
[ 0.000000] Call trace:
[ 0.000000] test_double_dereference+0x144/0x14c (P)
[ 0.000000] trace_event_raw_init+0x37c/0x5d8
[ 0.000000] event_init+0x34/0xc0
[ 0.000000] trace_event_init+0xec/0x588
[ 0.000000] trace_init+0x24/0x6e0
[ 0.000000] start_kernel+0x4a0/0x8ec
[ 0.000000] __primary_switched+0x88/0x90
[ 0.000000] irq event stamp: 0
[ 0.000000] hardirqs last enabled at (0): [<0000000000000000>] 0x0
[ 0.000000] hardirqs last disabled at (0): [<0000000000000000>] 0x0
[ 0.000000] softirqs last enabled at (0): [<0000000000000000>] 0x0
[ 0.000000] softirqs last disabled at (0): [<0000000000000000>] 0x0
[ 0.000000] ---[ end trace 0000000000000000 ]---
[ 0.000000] TRACE EVENT ERROR: Event mtu3_gadget_ep_disable has double dereference in TP_printk: &REC->gpd_ring->dma
[ 0.000000] TRACE EVENT ERROR: Event mtu3_gadget_ep_enable has double dereference in TP_printk: &REC->gpd_ring->dma
Which also observed by Mark and myself.
The splat it result of new check introduced by b5cc230af5e5 ("tracing:
Warn when an event dereferences a pointer in TP_printk()") which
correctly catches issue with %pad dereferencing the address saved in
the ring buffer. TP_fast_assign() logic gets executed when the
tracepoint is triggered, however the TP_printk() is executed when the
user reads the trace buffer which could be seconds, minutes, hours,
days, even months later and nothing guarantee that __entry->gpd_ring
pointer will still be pointing to what it was when it was recorded.
Fix the issue by capturing immediate value of gpd_ring.dma when trace
point is triggered.
Reported-by: Paul E. McKenney <paulmck@kernel.org>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
|
|
After reclaiming, the Tx poll asks to be polled again. That extra poll
finds nothing to do and does not reduce the interrupt rate.
Complete the NAPI and unmask the ring interrupt right after the reclaim.
On a CM4 this raises 60 byte pktgen Tx from about 187k to 224k pps and
saves about 5% of one core at TCP line rate.
Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260928121454.901306-1-nb@tipi-net.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The Rx ring priv and index are only set in bcmgenet_init_rx_ring(),
which runs at open. Setting the Rx coalescing parameters on an interface
that was never opened, e.g. "ethtool -C eth0 rx-usecs 50", dereferences
a NULL ring->priv. The oops happens with RTNL held, so networking
stays stuck until a reboot:
Unable to handle kernel paging request at virtual address 0000000000002788
pc : bcmgenet_set_rx_coalesce.isra.0+0x10/0x88
lr : bcmgenet_set_coalesce+0xe8/0x180
Call trace:
bcmgenet_set_rx_coalesce.isra.0+0x10/0x88 (P)
__ethnl_set_coalesce.isra.0+0x490/0x570
ethnl_set_coalesce+0x48/0xc0
ethnl_default_set_doit+0xf4/0x230
genl_family_rcv_msg_doit+0xe8/0x160
genl_rcv_msg+0x220/0x2a0
netlink_rcv_skb+0x68/0x140
genl_rcv+0x40/0x60
netlink_unicast+0x338/0x3c0
netlink_sendmsg+0x19c/0x3f8
__sock_sendmsg+0x64/0xc0
__sys_sendto+0x124/0x198
__arm64_sys_sendto+0x30/0x48
Set priv and index at probe. Writing the registers while the interface
is down is harmless because open resets the MAC and
bcmgenet_init_rx_coalesce() reapplies the stored values.
It was observed on a Raspberry Pi CM4, but should apply to all other
genet devices.
Fixes: 9f4ca05827a2 ("net: bcmgenet: Add support for adaptive RX coalescing")
Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://patch.msgid.link/20260928105642.856210-1-nb@tipi-net.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
On RZ/T2H and RZ/N1D MIIC, writing 0x0000 to the MIIC protection
register clears the protection state machine.
The initial protection state cannot be assumed to be constant,
as it may be influenced by previous activity before the driver
takes ownership of the hardware.
Clear the protection state before issuing the unprotect sequence
so that register access always starts from a known state, regardless
of any previous activity.
Fixes: 7dc54d3b8d91 ("net: pcs: add Renesas MII converter driver")
Signed-off-by: Yoshihisa Yamamoto <yoshihisa.yamamoto.xn@renesas.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Link: https://patch.msgid.link/TYCPR01MB74815955A10817B64BD6FB93A4812@TYCPR01MB7481.jpnprd01.prod.outlook.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Replace if/else blocks using regmap_set_bits()/regmap_clear_bits() with
the simpler regmap_assign_bits() calls in the lantiq gswip, mt7530 and
qca8k drivers.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Link: https://patch.msgid.link/20260924083538.461887-1-peng.fan@oss.nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
When disconnecting a device while firmware is not present on the system,
usbatm_usb_disconnect() waits for the heavy_init thread to finish:
wait_for_completion(&instance->thread_exited);
If CONFIG_FW_LOADER_USER_HELPER_FALLBACK is enabled, missing firmware
causes request_firmware() to fall back to sysfs/udevd. This creates a
circular dependency during disconnect:
1. usb_disconnect() holds device_lock(&udev->dev).
2. usbatm_usb_disconnect() waits for instance->thread to exit.
3. instance->thread waits for request_firmware() sysfs fallback.
4. udevd receives the firmware uevent and attempts to read sysfs
attributes (e.g. serial), blocking on device_lock(&udev->dev).
Furthermore, the fallback wait uses wait_for_completion_killable_timeout(),
which ignores the non-fatal SIGTERM signal sent by usbatm_usb_disconnect().
Because speedtch and cxacru probe multiple candidate firmware files
sequentially, each file stalls for the 60-second fallback timeout,
triggering hung task timeouts (>120s) reported by syzbot.
Switch to request_firmware_direct() to probe firmware files directly from
the filesystem without falling back to user-mode helper.
Cc: stable+noautosel@kernel.org # untested fix to a driver init path race
Reported-by: syzbot+9ca2c9f85bd8b5e46516@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=9ca2c9f85bd8b5e46516
Signed-off-by: Matvey Valigura <valigurasm@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260924050654.15347-1-valigurasm@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Pull shared branch with RDMA:
- net: ionic: Fetch qid allocation and SRQ capability from firmware
Link: https://lore.kernel.org/20260925082802.2675902-1-abhijit.gangurde@amd.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Use the device_set_node() helper instead of manually setting
adap.dev.of_node. This:
1. Ensures that if the parent has an of_node, adap.dev.fwnode
also points to the parent's of_node rather than remaining
NULL.
2. Removes the need to handle a parent with an ACPI fwnode
specially, since the generic helpers take care of this too.
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://patch.msgid.link/20260919141434.22999-1-johannes.goede@oss.qualcomm.com
|
|
Commit b44a06bd28f2 ("vfio/pci: Remove #ifdef iowrite64 and #ifdef
ioread64") inadvertently converted a conditional 8-byte rejection
into an unconditional one.
Originally, 'count == 8' was rejected only if iowrite64 was undefined
(#ifndef iowrite64). When iowrite64 became globally available via generic
fallbacks, this rejection became dead code, allowing 8-byte ioeventfds.
However, b44a06bd28f2 removed the #ifndef wrappers but left the nested
'if (count == 8) return -EINVAL;' intact, breaking all 8-byte
registrations.
Drop the unconditional check to restore 8-byte ioeventfd support,
matching the original intent.
Fixes: b44a06bd28f2 ("vfio/pci: Remove #ifdef iowrite64 and #ifdef ioread64")
Cc: stable@vger.kernel.org
Signed-off-by: Li RongQing <lirongqing@baidu.com>
Link: https://lore.kernel.org/r/20260922040013.2188-1-lirongqing@baidu.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
|
|
When a short-single SGE payload crosses a page boundary, siw_try_1seg()
computes the length of the first chunk as the amount that spills into
the second page instead of the amount left in the first page
part = bytes - (PAGE_SIZE - off);
Use the remaining length of the first page as the first chunk.
Fixes: b9be6f18cf9e ("rdma/siw: transmit path")
Link: https://patch.msgid.link/r/20260927115351.12245-1-serhatkumral1@gmail.com
Assisted-by: LLM
Signed-off-by: Serhat Kumral <serhatkumral1@gmail.com>
Acked-by: Bernard Metzler <bernard.metzler@linux.dev>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
|
|
process_io_rsp() indexes clt_path->reqs[] with the 19-bit msg_id
taken from a WRITE_WITH_IMM immediate. That value is chosen by the
peer. The only check was WARN_ON(msg_id >= queue_depth), which still
lets a completion run after free_path_reqs() has set reqs to NULL,
or against a slot whose FRWR is already gone. Either path
dereferences req->mr and can GPF; KASAN reports a null-ptr-deref at
offsetof(struct rtrs_clt_io_req, mr).
Treat a missing reqs array, an out-of-range msg_id, or a req
without an MR as a protocol error and recover the connection.
Link: https://patch.msgid.link/r/20260923-rtrs-warning-inrtrs-clt-rdma-done-v1-1-0827a9a77c0b@proton.me
Reported-by: Farhad Alemi <farhad.alemi@berkeley.edu>
Closes: https://lore.kernel.org/r/CA+0ovCiJZz6O8LzsS9Dq1-JE1OE1L_OTA6Mr-WratpUE6jczHw@mail.gmail.com
Fixes: 6a98d71daea1 ("RDMA/rtrs: client: main functionality")
Signed-off-by: Quanye Yang <quanyeyang@proton.me>
Reviewed-by: Jack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
|
|
i2c_smbus_read_block_data() is dangerous to use because it may deliver
up to I2C_SMBUS_BLOCK_MAX (32) bytes, which may be surprising to the
caller. Callers tend to allocate buffers of sizes big enough to hold
data from a well-behaving device and do not expect that
i2c_smbus_read_block_data() may attempt to write more data than
expected.
To make i2c_smbus_read_block_data() safer to use, change it so that
it accepts size of the supplied buffer as another argument and ensure
that it will not copy more data than the size of the buffer. Signal
oversized responses with -EMSGSIZE.
To allow users to gradually transition to the new API employ some
macro trickery allowing calling i2c_smbus_read_block_data() with either
3 or 4 arguments. When called with 3 arguments it is assumed that
the buffer size is I2C_SMBUS_BLOCK_MAX bytes. Once everyone is
transitioned to the 4 argument form the macros should be removed.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://patch.msgid.link/ammWUROtUGeriY8G@google.com
|
|
Remove special case logic for disabling all queues in ice_vc_dis_qs_msg().
There were no actual speedup from it, the only difference was in saved
bitmap checks, but the HW operations take the majority of time anyway.
ice_vsi_stop_all_rx_rings() used (in the removed code) loops over rings
anyway.
With a message added just before removed code, in the "remove VF" scenario
there were no noticeable difference with the "speedup" and without, and it
takes ~0.06s on my machine from this point to the whole iavf removed, so
really no big deal anyway.
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
|
|
The function has 3 callers, all except one explicitly require
pf != NULL. Add the corresponding check to the remaining caller,
and remove it from the ice_pf_state_is_nominal(). It makes the
fun function a one-liner.
Signed-off-by: Yury Norov <ynorov@nvidia.com>
Reviewed-by: Sergey Temerkhanov <sergey.temerkhanov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
|
|
cxl/region: Warn on user region position mismatch
|
|
dmaengine_desc_free() is designed for DMA_CTRL_REUSE. If DMA_CTRL_REUSE
is not set, dmaengine_desc_free() will return -EPERM.
if (!dmaengine_desc_test_reuse(desc))
return -EPERM;
So calling dmaengine_desc_free() does nothing.
dmaengine_terminate_(a)sync() will free all already allocated descriptors.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260929190621.3516424-1-Frank.Li@oss.nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The function creates a temporary mask on stack just to check that
first ICE_STATE_NOMINAL_CHECK_BITS is empty. Simplify it by using
the ice_pf_state_is_nominal().
Signed-off-by: Yury Norov <ynorov@nvidia.com>
Reviewed-by: Sergey Temerkhanov <sergey.temerkhanov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
|
|
Use kcalloc() when calculating the parser table allocation size so an
overflow in the firmware-provided item dimensions is detected before
allocation.
Signed-off-by: Weimin Xiong <xiongwm2026@163.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
|
|
Add ice_rx_hwtstamp trace event to help debug PTP rx timestamp issues.
The trace captures cached_time, ts_high, and the extended ts_ns value in
ice_ptp_get_rx_hwts().
Enable with:
echo 1 > /sys/kernel/debug/tracing/events/ice/ice_rx_hwtstamp/enable
cat /sys/kernel/debug/tracing/trace_pipe
Signed-off-by: Przemyslaw Korba <przemyslaw.korba@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux
Pull MTD fixes from Miquel Raynal:
"The most important set of fixes are around the handling of the QE bit
in SPI NAND.
There are also a couple of behavioral fixes (mutex issue in SPI-NOR,
spurious bitflips on vf610_nfc, OOB bytes count in SPI NAND and
cfi_cmdset stack usage).
The rest is mostly AI fuzzing results"
* tag 'mtd/fixes-for-7.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux:
mtd: spinand: Do not update the QE bit on devices without one
mtd: spi-nor: core: Fix mutex leak in spi_nor_rww_start_exclusive()
mtd: rawnand: cadence: Initialize IRQ state before requesting IRQ
mtd: rawnand: vf610_nfc: fix false bitflips on reads of erased pages
mtd: rawnand: vf610_nfc: fix reads on chips with more than 64 bytes of OOB
mtd: spinand: fix zero oobavail when no ECC engine is used
mtd: spinand: fix NULL pointer dereference with no ECC engine
mtd: mtd_intel_dg: reset poll counter for each erase
mtd: cfi_cmdset_0001: shrink do_write_buffer() stack frame
mtd: core: call _get_device() with the master MTD
mtd: core: avoid double-free of OTP NVMEM device
mtd: spinand: Enable QE on all dies
mtd: block2mtd: Fix divide error when erase_size is zero
|
|
ice_ethtool_fdir
Replace static full_ipv6_addr_mask / zero_ipv6_addr_mask structs
and the associated memcmp() calls in ice_ethtool_fdir.c with the
kernel-provided ipv6_addr_any() helper and a new ice_ipv6_mask_full()
inline, reducing boilerplate and making intent clearer.
Suggested-by: Larysa Zaremba <larysa.zaremba@intel.com>
Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Tested-by: Alexander Nowlin <alexander.nowlin@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
|
|
The miscellaneous interrupt cause (OICR) is throttled to 8K
interrupts per second (124 us minimum spacing). This interrupt
handles VF mailbox messages and Tx timestamps, so the low rate
imposes a minimum latency floor on both use-cases.
Raise the rate to 20K interrupts per second (50 us minimum
spacing) to allow lower latency handling for Tx timestamp
bursts and high VF message rates.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Tested-by: Alexander Nowlin <alexander.nowlin@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
|
|
The ice_flash_info structure has a u16 sr_words field before a u32
flash_size value. This creates a 2-byte hole as well as 3 bytes of
padding at the end of the structure due to the blank_nvm_mode bitfield.
Re-order the structure to place flash_size first, which gives a better
layout and reduces padding.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Tested-by: Alexander Nowlin <alexander.nowlin@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
|
|
Use the already existing helper function to fill Ethernet header. Also
replace sizeof with a (also existing) macro to reduce the number of
variables.
Suggested-by: Martyna Szapar-Mudlaw <martyna.szapar-mudlaw@intel.com>
Signed-off-by: Marcin Szycik <marcin.szycik@intel.com>
Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
|
|
Reduce netdev message "Can't delete DSCP netlink app ..." from error
to debug level when in FW (firmware) DCB mode.
This is not a real error and a kind of expected behavior. The device
is fully operational and error message might be wrongly interpreted by
the user.
Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com>
Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Tested-by: Arpana Arland <arpanax.arland@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
|
|
vfio_cdx_mmap() accepts MAP_PRIVATE mappings. A non-shared mapping
with VM_MAYWRITE is a COW mapping, and remap_pfn_range()'s COW special
case in get_remap_pgoff() then overwrites vma->vm_pgoff with the
physical frame number:
if (is_cow) {
if (addr != vm_start || end != vm_end)
return -EINVAL;
*vm_pgoff_p = pfn;
}
The VMA is inserted into the device file's mapping->i_mmap interval
tree keyed by vm_pgoff, which VFIO expects to be the logical file
offset: the core links every device mmap to the device inode's
i_mapping precisely so that unmap_mapping_range() can revoke all
mappings associated with a device (see vfio_device_open_file() and
vfio_device_fops_cdev_open()).
A raw PFN in vm_pgoff lands the interval tree entry in the wrong
coordinate space, so unmap_mapping_range() cannot find the VMA and a
stale MMIO mapping survives any revocation attempt. Without this
check, a MAP_PRIVATE mapping reintroduces that corruption even with
the logical-vm_pgoff fix in place.
Require VM_SHARED as vfio-pci, vfio-fsl-mc and vfio-platform already
do. This is defensive hygiene: vfio-cdx does not call
unmap_mapping_range() today, so no reachable stale-mapping issue
exists.
Signed-off-by: Abdifatah Suruur <suruurism@gmail.com>
Link: https://lore.kernel.org/r/20260929094848.7439-8-suruurism@gmail.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
|
|
vfio_cdx_mmap_mmio() overwrites vma->vm_pgoff with the physical frame
number of the MMIO region and passes it to io_remap_pfn_range(). The
VMA is inserted into the device file's mapping->i_mmap interval tree
keyed by vm_pgoff, which VFIO expects to be the logical file offset:
the core links every device mmap to the device inode's i_mapping
precisely so that unmap_mapping_range() can revoke all mappings
associated with a device (see vfio_device_cdev_open()).
With a raw PFN in vm_pgoff the interval tree entry lands in the wrong
coordinate space and unmap_mapping_range() cannot find the VMA,
leaving stale MMIO mappings behind any revocation attempt. Keep
vm_pgoff in the logical VFIO offset space, as vfio-pci does, and pass
the physical PFN to io_remap_pfn_range() explicitly.
This is defensive hygiene: none of vfio-platform, vfio/fsl-mc and
vfio/cdx call unmap_mapping_range() today, so no reachable
stale-mapping issue exists. Keeping vm_pgoff logical preserves the
VFIO core contract for any future revocation path.
Signed-off-by: Abdifatah Suruur <suruurism@gmail.com>
Link: https://lore.kernel.org/r/20260929094848.7439-7-suruurism@gmail.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
|
|
vfio_fsl_mc_mmap_mmio() overwrites vma->vm_pgoff with the physical
frame number of the MMIO region and passes it to remap_pfn_range().
The VMA is inserted into the device file's mapping->i_mmap interval
tree keyed by vm_pgoff, which VFIO expects to be the logical file
offset: the core links every device mmap to the device inode's
i_mapping precisely so that unmap_mapping_range() can revoke all
mappings associated with a device (see vfio_device_cdev_open()).
With a raw PFN in vm_pgoff the interval tree entry lands in the wrong
coordinate space and unmap_mapping_range() cannot find the VMA,
leaving stale MMIO mappings behind any revocation attempt. Keep
vm_pgoff in the logical VFIO offset space, as vfio-pci does, and pass
the physical PFN to remap_pfn_range() explicitly.
This is defensive hygiene: none of vfio-platform, vfio/fsl-mc and
vfio/cdx call unmap_mapping_range() today, so no reachable
stale-mapping issue exists. Keeping vm_pgoff logical preserves the
VFIO core contract for any future revocation path.
Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Signed-off-by: Abdifatah Suruur <suruurism@gmail.com>
Link: https://lore.kernel.org/r/20260929094848.7439-6-suruurism@gmail.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
|
|
vfio_platform_mmap_mmio() overwrites vma->vm_pgoff with the physical
frame number of the MMIO region and passes it to remap_pfn_range().
The VMA is inserted into the device file's mapping->i_mmap interval
tree keyed by vm_pgoff, which VFIO expects to be the logical file
offset: the core links every device mmap to the device inode's
i_mapping precisely so that unmap_mapping_range() can revoke all
mappings associated with a device (see vfio_device_cdev_open()).
With a raw PFN in vm_pgoff the interval tree entry lands in the wrong
coordinate space and unmap_mapping_range() cannot find the VMA,
leaving stale MMIO mappings behind any revocation attempt. Keep
vm_pgoff in the logical VFIO offset space, as vfio-pci does, and pass
the physical PFN to remap_pfn_range() explicitly.
This is defensive hygiene: none of vfio-platform, vfio/fsl-mc and
vfio/cdx call unmap_mapping_range() today, so no reachable
stale-mapping issue exists. Keeping vm_pgoff logical preserves the
VFIO core contract for any future revocation path.
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Abdifatah Suruur <suruurism@gmail.com>
Link: https://lore.kernel.org/r/20260929094848.7439-5-suruurism@gmail.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
|
|
vfio_cdx_mmap() rejects writable mappings of regions without the WRITE
flag, but leaves VM_MAYWRITE set. Userspace can map such a region
read-only and then upgrade the mapping to writable with mprotect(),
writing to MMIO regions the device marks read-only.
Clear VM_MAYWRITE for regions without the WRITE flag, as i915 does for
its read-only objects and as fixed in drm/vc4 (CVE-2026-68445),
drm/panthor (CVE-2024-53071) and commit a5edadbae57e ("ptp: vmclock:
prevent read-only mappings from becoming writable").
Note this is defensive hardening: no in-tree cdx device currently
publishes a region without the WRITE flag. The guard costs nothing and
keeps the mmap() interface honest if a read-only region ever appears.
Fixes: 234489ac56130 ("vfio/cdx: add support for CDX bus")
Signed-off-by: Abdifatah Suruur <suruurism@gmail.com>
Link: https://lore.kernel.org/r/20260929094848.7439-4-suruurism@gmail.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
|
|
vfio_fsl_mc_mmap() rejects writable mappings of regions without the
WRITE flag, but leaves VM_MAYWRITE set. Userspace can map such a region
read-only and then upgrade the mapping to writable with mprotect().
Clear VM_MAYWRITE for regions without the WRITE flag, as i915 does for
its read-only objects and as fixed in drm/vc4 (CVE-2026-68445),
drm/panthor (CVE-2024-53071) and commit a5edadbae57e ("ptp: vmclock:
prevent read-only mappings from becoming writable").
Note this is defensive hardening: the fsl-mc bus publishes all device
regions with the WRITE flag set, so no device can currently reach the
read-only path. The guard costs nothing and keeps the mmap() interface
honest if a read-only region ever appears.
Fixes: 67247289688d4 ("vfio/fsl-mc: Allow userspace to MMAP fsl-mc device MMIO regions")
Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Signed-off-by: Abdifatah Suruur <suruurism@gmail.com>
Link: https://lore.kernel.org/r/20260929094848.7439-3-suruurism@gmail.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
|
|
vfio_platform_mmap() rejects writable mappings of regions without the
WRITE flag, but leaves VM_MAYWRITE set. Userspace can map such a region
read-only and then upgrade the mapping to writable with mprotect().
Clear VM_MAYWRITE for regions without the WRITE flag, as i915 does for
its read-only objects and as fixed in drm/vc4 (CVE-2026-68445),
drm/panthor (CVE-2024-53071) and commit a5edadbae57e ("ptp: vmclock:
prevent read-only mappings from becoming writable").
Note this is defensive hardening: no in-tree platform driver currently
publishes a region without the WRITE flag. The guard costs nothing and
keeps the mmap() interface honest if a read-only region ever appears.
Fixes: fad4d5b1f042 ("vfio/platform: support MMAP of MMIO regions")
Reviewed-by: Mostafa Saleh <smostafa@google.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Signed-off-by: Abdifatah Suruur <suruurism@gmail.com>
Link: https://lore.kernel.org/r/20260929094848.7439-2-suruurism@gmail.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
|
|
The info-response receive is posted for a SEND. The completion
opcode comes from the peer, so RDMA WRITE with Immediate is a
legal WC on that WQE even though it violates the RTRS handshake.
WARN_ON(wc->opcode != IB_WC_RECV) treats that peer-controlled
field as an internal invariant and panics with panic_on_warn.
Treat a non-SEND completion as a handshake failure: log it and
keep the existing CONNECTING_ERR cleanup.
Fixes: 6a98d71daea1 ("RDMA/rtrs: client: main functionality")
Link: https://patch.msgid.link/r/20260921-rtrs-fix-rtrs-clt-info-rsp-done-v1-1-c64281ed97c0@proton.me
Reported-by: Farhad Alemi <farhad.alemi@berkeley.edu>
Closes: https://lore.kernel.org/linux-rdma/CA+0ovCge-K+hcGHXZ4R3Ww5+cg159uxHBeVbKeUSLBRSMT8OWA@mail.gmail.com/
Signed-off-by: Quanye Yang <quanyeyang@proton.me>
Reviewed-by: Jack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
|
|
RQ and CQ ring buffers require physically contiguous memory. On
systems under memory pressure, high-order allocations can fail
even when sufficient free memory exists because the allocator
gives up after a single reclaim and compaction attempt for
costly-order requests that lack __GFP_RETRY_MAYFAIL.
Add __GFP_RETRY_MAYFAIL to the GFP flags in efa_zalloc_mapped()
to allow retries with escalating compaction priority and release
of highatomic reserves before giving up.
Link: https://patch.msgid.link/r/20260917105101.9365-1-mrgolin@amazon.com
Reviewed-by: Firas Jahjah <firasj@amazon.com>
Reviewed-by: Yonatan Nachum <ynachum@amazon.com>
Signed-off-by: Michael Margolin <mrgolin@amazon.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
|
|
DP v2.1b specifies that REMOTE_DPCD_READ and REMOTE_DPCD_WRITE
transactions should only be issued to downstream ports where ddps=1
(device plug status indicates a device is connected). Issuing these
transactions to empty ports (ddps=0) is non-compliant and causes
problems in practice: some MST hubs NAK the request, and all hubs
introduce a delay waiting for the transaction to complete or fail
before the driver can proceed, increasing link training latency.
Guard drm_dp_mst_dpcd_read() and drm_dp_mst_dpcd_write() with a
ddps check and return -EIO immediately for unoccupied ports. This
avoids the spurious sideband transactions without changing connector
lifetime semantics — connectors for all output ports are still
created at enumeration time, regardless of ddps.
Signed-off-by: Xiao Lu <xiaolu.xie@intel.com>
Changes in v2:
- Instead of skipping connector creation for ddps=0 ports (v1),
keep connectors around and guard DPCD transactions at the
drm_dp_mst_dpcd_read/write level. This avoids changing connector
lifetime semantics visible to userspace, per Lyude's review.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patch.msgid.link/20260920022144.2209244-1-xiaolu.xie@intel.com
|
|
The null key name check exists to protect against TPM reset attacks, so
a mismatch should stop the device from serving further requests.
Currently it does not disable the chip when it finds a mismatch.
The mismatch is logged:
tpm tpm0: null key integrity check failed
but the chip keeps serving commands:
/ # tpm2_getcap -c properties-fixed
TPM_PT_FAMILY_INDICATOR:
as UINT32: 0x08322e3000
as string: "2.0"
...
tpm2_load_null() where the null key name check is run sets the chip as
disabled only if the rc is non zero. When the mismatch is seen, rc is
zero at that point and it returns success. The other issue is that the
caller expects the null key handle to be populated when the function
returns 0 which it does here without writing the handle and proceeds
assuming the null key handle is valid.
During the test, I noticed that tpm2_start_auth_session() uses the
uninitialized stack value as the key handle since tpm2_load_null()
returns 0 despite the integrity failure and proceeds with
TPM2_CC_START_AUTH_SESS with this value as salt key handle.
Set rc to -ENODEV on the mismatch. The error path then disables the chip
and returns the correct code to the caller.
Tested in QEMU with swtpm and CONFIG_TCG_TPM2_HMAC=y by making
TPM2_CC_CONTEXT_LOAD fail with TPM2_RC_INTEGRITY and changing the name
of the re-created null key. The chip is now disabled on the mismatch.
Fixes: cc7d8594342a ("tpm: Rollback tpm2_load_null()")
Fixes: 423893fcbe7e ("tpm: Disable TPM on tpm2_create_primary() failure")
Cc: stable@vger.kernel.org # v6.12+
Assisted-by: LLM
Signed-off-by: Surendran Kanagaraj <surenkj@amazon.com>
Link: https://lore.kernel.org/r/20260918000731.48657-1-surenkj@amazon.com
Reviewed-by: Gunnar Kudrjavets <gunnarku@amazon.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
|
|
When the response carries the TPM2_ST_SESSIONS tag, tpm2_get_random()
skips the 4-byte parameter size field before locating the random data,
but the bounds check still validates the response length against
TPM_HEADER_SIZE. A truncated response can pass the check and make
memcpy() read up to 4 bytes past the response end, so stale buffer
contents end up in the caller's random bytes.
Fix this by checking the response length against 'offset', which
already includes the skipped parameter size field.
Cc: stable@vger.kernel.org # v6.12+
Fixes: 1b6d7f9eb150 ("tpm: add session encryption protection to tpm2_get_random()")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260902074839.417419-1-yijiangshan%40kylinos.cn
Signed-off-by: Jiangshan Yi <yijiangshan@kylinos.cn>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Link: https://lore.kernel.org/r/20260903035837.219284-1-yijiangshan@kylinos.cn
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
|
|
When tpm_buf_fill_hmac_session() fails in tpm2_get_random(), the error
path returns without calling tpm2_end_auth_session(), leaking the auth
session. All other error paths in the function handle this correctly.
Fixes: 3d9e043dab0a ("tpm-buf: Memory-safe allocations")
Cc: stable@vger.kernel.orga # v6.12+
Signed-off-by: Jiangshan Yi <yijiangshan@kylinos.cn>
Link: https://lore.kernel.org/r/20260902074839.417419-1-yijiangshan@kylinos.cn
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
|
|
struct tpm_buf now uses an embedded flexible array for data, which is
6 bytes shorter than TPM_BUFSIZE due to the struct header. But
tpm_transmit_cmd() still passes PAGE_SIZE to tpm_transmit(), and after
clamping to TPM_BUFSIZE in tpm_try_transmit(), chip->ops->recv() can
write past the end of data[] by 6 bytes.
Pass buf->capacity to tpm_transmit() instead.
Fixes: 3d9e043dab0a ("tpm-buf: Memory-safe allocations")
Signed-off-by: Jiangshan Yi <yijiangshan@kylinos.cn>
Link: https://lore.kernel.org/r/20260901062850.379870-1-yijiangshan@kylinos.cn
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
|
|
Just like in Gpu::new() a single try_pin_init!() block makes the code
more readable.
Besides that, it prepares the code for a proper PCI device enable guard
that we will get soon.
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260927144417.1280385-1-dakr@kernel.org
[ Drop useless dev_dbg!() in probe(). - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Replace if/else blocks using regmap_set_bits()/regmap_clear_bits() with
the simpler regmap_assign_bits() call.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com>
Reviewed-by: Drew Fustini (Tenstorrent) <fustini@kernel.org>
Link: https://patch.msgid.link/20260924083439.461769-1-peng.fan@oss.nxp.com
Signed-off-by: Drew Fustini (Tenstorrent) <fustini@kernel.org>
|
|
atlantis_clk_gate_shared_enable() increments the refcount for the number
of clks requesting the shared gate clk to be enabled always. It should
only do this when the enable for the gate took effect in hardware. It's
possible to end up in a situation where the gate enable failed, but the
refcount is incremented anyway, so subsequent requests by other clks
that share the same refcount get ignored and the gate enable is never
retried.
Update this function so that the refcount is not incremented when the
gate clk enable fails in hardware.
Fixes: 23c8ebc95284 ("clk: tenstorrent: Add Atlantis clock controller driver")
Cc: stable@vger.kernel.org
Reported-by: Sashiko <sashiko-bot@kernel.org>
Link: https://sashiko.dev/#/patchset/AS8P251MB00013BD9A093C06D2D60E10EC8B42%40AS8P251MB0001.EURP251.PROD.OUTLOOK.COM
Signed-off-by: Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com>
Reviewed-by: Drew Fustini (Tenstorrent) <fustini@kernel.org>
Link: https://patch.msgid.link/20260924-atlantis_gate_shared_enable_fix-v1-1-303f925b8a3d@oss.tenstorrent.com
Signed-off-by: Drew Fustini (Tenstorrent) <fustini@kernel.org>
|
|
Commit f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with
__counted_by") annotated the hws member of 'struct clk_hw_onecell_data'
with __counted_by, which informs the bounds sanitizer (UBSAN_BOUNDS)
about the number of elements in .hws[], so that it can warn when .hws[]
is accessed out of bounds. As noted in that change, the __counted_by
member must be initialized with the number of elements before the first
array access happens, otherwise there will be a warning from each access
prior to the initialization because the number of elements is zero.
This occurs in atlantis_prcm_clocks_register() due to .num being
assigned only after every clock has been stored in .hws[]. With
CONFIG_UBSAN_BOUNDS and a compiler that implements __counted_by (GCC
15.1+ or Clang 20.1+), this triggers an array-index-out-of-bounds report
during probe, and with CONFIG_UBSAN_TRAP the first store traps so the
clock provider never registers.
Move the .num initialization to right after the allocation.
Fixes: 23c8ebc95284 ("clk: tenstorrent: Add Atlantis clock controller driver")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Aamir Ahmed <elb12345@hotmail.co.uk>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com>
Reviewed-by: Drew Fustini (Tenstorrent) <fustini@kernel.org>
Link: https://patch.msgid.link/AS8P251MB00013BD9A093C06D2D60E10EC8B42@AS8P251MB0001.EURP251.PROD.OUTLOOK.COM
[fustini: drop num_clks, use data->num per Gustavo]
Signed-off-by: Drew Fustini (Tenstorrent) <fustini@kernel.org>
|
|
The device status page is shared by all userspace contexts and contains
db_off, which the driver updates to control doorbell flow. The rdma-core
provider maps it with PROT_READ, but c4iw_mmap() passes the requested page
protection through when handling CXGB4_MMAP_CONTIG.
A process can therefore request PROT_WRITE directly or later upgrade a
read-only mapping with mprotect() because VM_MAYWRITE remains set. This
lets userspace alter device-wide flow-control state seen by the kernel and
other contexts.
Reject initially writable mappings and clear VM_MAYWRITE before mapping the
page. This preserves the existing read-only userspace ABI.
Fixes: 05eb23893c2c ("cxgb4/iw_cxgb4: Doorbell Drop Avoidance Bug Fixes")
Signed-off-by: Jiale Yao <yaojiale02@163.com>
Link: https://patch.msgid.link/20260926112611.3214382-1-yaojiale02@163.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
mlx4_ib_mmap() maps the internal clock page to userspace through
rdma_user_mmap_io(), which does not restrict write access. Userspace can
request PROT_WRITE directly, or upgrade a read-only mapping later with
mprotect() because VM_MAYWRITE remains set.
Reject VM_WRITE, VM_EXEC and clear VM_MAYWRITE, applying the same read-only
policy as commit c660133c339f ("RDMA/mlx5: Do not allow the user to write to the
clock page"). The rdma-core mlx4 provider requests this mapping with
PROT_READ, so its existing behavior is unchanged.
Fixes: 52033cfb5aab ("IB/mlx4: Add mmap call to map the hardware clock")
Signed-off-by: Jiale Yao <yaojiale02@163.com>
Link: https://patch.msgid.link/20260926111150.3197004-1-yaojiale02@163.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
ib_mad_recv_done() derives the OPA MAD length by subtracting the GRH
size from wc->byte_len without ensuring the receive completion covers
the GRH. If it is shorter, the subtraction wraps before the result is
stored in mad_len and an invalid length can be passed downstream.
Reject receive completions shorter than the GRH before inspecting the
MAD header or deriving the MAD length.
Fixes: 8e4349d13f33 ("IB/mad: Add final OPA MAD processing")
Signed-off-by: Jiale Yao <yaojiale02@163.com>
Link: https://patch.msgid.link/20260926105927.3183294-1-yaojiale02@163.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
virtblk_read_zoned_limits() reads the write granularity that the device
reports in virtio_blk_zoned_characteristics and assigns it to the
physical block size and to io_min, but never to the limit that is named
after it. queue_limits.zone_write_granularity is left at zero, so
blk_validate_zoned_limits() raises it to the logical block size:
if (lim->zone_write_granularity < lim->logical_block_size)
lim->zone_write_granularity = lim->logical_block_size;
A device that reports a granularity coarser than its logical block size,
which is what the field exists to express, therefore has it silently
reduced. A 512e host managed disk passed through to a guest reports a
logical block size of 512 and a write granularity of 4096, and the guest
ends up with a zone write granularity of 512.
bio_split_alignment() returns lim->zone_write_granularity if it is non-zero
and bio_split_io_at() may split a bio with as per bio_split_alignment().
This can real to the write getting rejected by the host drive, as the write
is not aligned to the physical block size.
zonefs also takes its block size from bdev_zone_write_granularity(), so it
would incorrectly use 512 on a disk that requires 4096.
sd_zbc_read_zones() sets the limit from the physical block size for the
same reason. NVMe ZNS and null_blk leave it unset, but the fallback
gives the right answer for them, as their write granularity is the
logical block size. virtio carries a separate value that may exceed it.
Set the zone write granularity from the value that the device reports.
Fixes: 95bfec41bd3d ("virtio-blk: add support for zoned block devices")
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Link: https://patch.msgid.link/20260918140641.2031075-2-cassel@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
