| Age | Commit message (Collapse) | Author |
|---|
|
The 32-bit MSR interfaces rdmsr(), wrmsr(), rdmsr_safe() and
wrmsr_safe() are planned to be removed. Use the related 64-bit variants
instead.
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Link: https://patch.msgid.link/20260629060526.3638272-7-jgross@suse.com
|
|
The device tree binding allows both "ports" and "ethernet-ports" as
the container node name. Try "ethernet-ports" when "ports" is absent
so that newer DTBs with the preferred name work.
This matches the handling already present in qca8k-8xxx.c
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://patch.msgid.link/20260630015137.1591152-1-rosenp@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
page_pool_create() only registers pools with the netdev Netlink
interface when pp_params.netdev is set. Set netdev in page pool
params.
Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com>
Link: https://patch.msgid.link/20260630013814.3657831-1-rkannoth@marvell.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Linus Walleij says:
====================
net: dsa: realtek: rtl8366rb: Use generic RTL83xx code
As a follow-up to Luiz's and Alvin's series improvining the
generic handling of the Realtek DSA switches, this small
series brings the RTL8366RB closer to the way things are done
in the RTL8365MB driver.
This patch series switches over to using the generic helpers
for:
- Bridge joining and leaving (isolation)
- STP handling
- Learning enable/disable
It would be appreciated if this doesn't lead to AI-automated
request to fix the entire universe (hi Sashiko, I'm looking
at you but I bet you will do you compulsive C3P0-style review
anyway) since I'm just moving code around so some helper
functions come before their new users. The code itself is
pretty straight-forward.
Signed-off-by: Linus Walleij <linusw@kernel.org>
====================
Link: https://patch.msgid.link/20260630-rtl8366rb-improvements-v2-0-05eb9d6a37f5@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Instead of just writing the learning disablement register in setup
and a custom handling of BR_LEARNING, implement the generic RTL83xx
.port_set_learning() callback for setting learning on a port, and
call this in the per-port loop in .setup().
Instead of the custom rtl83366rb_port_bridge_flags() function for
setting learning mode on each port, use the RTL83xx generic
rtl83xx_port_bridge_flags() callback.
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260630-rtl8366rb-improvements-v2-5-05eb9d6a37f5@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
When we loop over all ports in the switch .setup() callback,
make sure to disable learning on all user ports. This is what
is normally expected and what the RTL8365MB is doing.
Move the code around to accommodate for the new call.
Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260630-rtl8366rb-improvements-v2-4-05eb9d6a37f5@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Instead of custom loops for intializing the ports (including the
CPU port) use the DSA helpers dsa_switch_for_each_port() and
dsa_switch_for_each_cpu_port() following the pattern in RTL8365MB by
accumulatong masks for the upstream and downstream ports.
This gives us similar enough code to the RTL8365MB that we
can start using more generic rtl83xx helpers.
Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260630-rtl8366rb-improvements-v2-3-05eb9d6a37f5@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
The RTL8366RB is using its own sub-standard port isolation code.
Implement the required isolation helpers, use these directly in
the port setup callback, and switch over to the standard port
isolation code.
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260630-rtl8366rb-improvements-v2-2-05eb9d6a37f5@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Mostly to make it possible to add rtl83xx support piece by piece,
make the port learning callback optional in rtl83xx_port_bridge_join()
and rtl83xx_port_bridge_leave().
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260630-rtl8366rb-improvements-v2-1-05eb9d6a37f5@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
The SPI NOR flash is powered the "always on" 1.8V LDO regulated power
rail.
Add the supply for the SPI NOR flash.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
The SPI NOR flash is powered from the always on 1.8V power rail through
a load switch that is controlled by the security chip.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
The original CCI OPP table minimum frequency 500Mhz is too low to cause
system stall, So it need update to new version, 1.4G ~ 0.8G.
Signed-off-by: Mark Tseng <chun-jen.tseng@mediatek.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
The LIST_HEAD macro can both define a linked list and initialize
it in one step. To simplify code, we replace the separate operations
of linked list definition and manual initialization with the LIST_HEAD
macro.
Signed-off-by: Lei Zhu <zhulei@kylinos.cn>
Reviewed-by: Brett Creeley <brett.creeley@amd.com>
Link: https://patch.msgid.link/20260630065457.160081-1-zhulei_szu@163.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
set_carrier() ignores the result of the USB control transfer and tests
the stack variable supplied as its receive buffer. If the device rejects
or aborts the request, that variable remains uninitialized and the driver
chooses an arbitrary carrier state.
Leave the existing carrier state unchanged when the link status cannot be
read. A transient USB error should not be treated as link loss.
Reported-by: syzbot+9db6c624635564ad813c@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=9db6c624635564ad813c
Suggested-by: Petko Manolov <petkan@nucleusys.com>
Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260630101216.10365-1-alhouseenyousef@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
We miss a failed allocation check for pgdat->per_cpu_nodestats, which
results in a NULL deref when we offset into the per-cpu area.
Propagate -ENOMEM up the stack and leave per_cpu_nodestats pointing
at boot_nodestats so a later online can retry the allocation.
hotadd_init_pgdat() returns NULL on failure, which __try_online_node()
already maps to -ENOMEM.
On failure nothing needs to be unwound:
- the node is never marked online
- per_cpu_nodestats is left pointing at boot_nodestats
- __add_memory_resource() cleans up pending memblock resources
- later online attempts retry the per_cpu_nodestats allocation
Reported-by: Sashiko <sashiko-bot@kernel.org>
Link: https://sashiko.dev/#/patchset/20260627202243.758289-1-gourry%40gourry.net
Fixes: 75ef71840539 ("mm, vmstat: add infrastructure for per-node vmstats")
Signed-off-by: Gregory Price <gourry@gourry.net>
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
Link: https://patch.msgid.link/20260701221613.2818148-1-gourry@gourry.net
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
|
|
David Christensen says:
====================
net: remove the orphaned IBM eHEA driver
The IBM eHEA (Ethernet Host Ethernet Adapter) driver has been orphaned
since April 2024 with no active maintainer stepping forward. This series
removes the driver and associated references from the kernel tree.
The driver was marked as an Orphan on April 18, 2024:
commit 97ec32b583bb ("MAINTAINERS: eth: mark IBM eHEA as an Orphan")
In the 13 months since, no maintainer has stepped forward to take
ownership.
The hardware was last supported on IBM POWER7 systems, which reached
end-of-support in December 2020. The driver has received no functional
updates since October 2022:
commit 0e7ce23a917a ("net: ehea: fix possible memory leak in ehea_register_port()")
And has only received mechanical API migrations affecting the entire kernel
tree since that time.
====================
Link: https://patch.msgid.link/20260629211343.3712775-1-drc@linux.ibm.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Follow-on cleanup after the removal of the IBM eHEA driver in commit
f721e8ffa92a ("ehea: remove the ehea driver").
Remove the CONFIG_IBM_EHEA entry from ppc64_defconfig and the
EXPORT_SYMBOL_GPL(walk_system_ram_range) export from arch/powerpc/mm/mem.c
that was only needed by the ehea driver.
Signed-off-by: David Christensen <drc@linux.ibm.com>
Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
Link: https://patch.msgid.link/20260629211343.3712775-3-drc@linux.ibm.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
The IBM eHEA (Ethernet Host Ethernet Adapter) driver has been orphaned
since April 2024 with no active maintainer. The hardware was last
supported on IBM POWER7 systems which reached end-of-support in
December 2020. The driver has received no functional updates since
October 2022, with all subsequent changes being mechanical API
migrations affecting the entire kernel tree.
A search of lore.kernel.org for the last 24 months reveals no user
reports, no objections to the orphan status, and no maintenance
discussions indicating active hardware deployment.
The code is preserved in git history and can be restored if a
maintainer steps forward to take ownership.
Signed-off-by: David Christensen <drc@linux.ibm.com>
Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
Link: https://patch.msgid.link/20260629211343.3712775-2-drc@linux.ibm.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Simon Wunderlich says:
====================
Here are some batman-adv bugfix, all by Sven Eckelmann:
- fix pointers after potential skb reallocs (5 patches)
- dat: ensure accessible eth_hdr proto field
* tag 'batadv-net-pullrequest-20260630' of https://git.open-mesh.org/batadv:
batman-adv: dat: ensure accessible eth_hdr proto field
batman-adv: bla: reacquire gw address after skb realloc
batman-adv: dat: acquire ARP hw source only after skb realloc
batman-adv: gw: acquire ethernet header only after skb realloc
batman-adv: access unicast_ttvn skb->data only after skb realloc
batman-adv: retrieve ethhdr after potential skb realloc on RX
====================
Link: https://patch.msgid.link/20260630134430.85786-1-sw@simonwunderlich.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Simon Wunderlich says:
====================
This cleanup patchset includes the following patches:
- drop hardif global list, by Nora Schiffer (2 patches)
- make hard_iface->mesh_iface immutable, by Sven Eckelmann
- further post-hardif global list cleanups,
by Nora Schiffer (3 patches)
- cleanups and simplifications depending on the hardif->mesh_iface
immutability guarantee, by Sven Eckelmann (3 patches)
- tvlv: extract tvlv header iterator, by Sven Eckelmann
- tp_meter: improve unacked list handling,
by Sven Eckelmann (5 patches)
* tag 'batadv-next-pullrequest-20260630' of https://git.open-mesh.org/batadv:
batman-adv: tp_meter: delay allocation of unacked entry
batman-adv: tp_meter: adjust name of receiver lock
batman-adv: tp_meter: keep unacked list for receivers
batman-adv: tp_meter: combine adjacent/overlapping unacked entries
batman-adv: tp_meter: simplify unordered ack calculation
batman-adv: tvlv: extract tvlv header iterator
batman-adv: iv: drop migration check for batadv_hard_iface
Revert "batman-adv: v: stop OGMv2 on disabled interface"
batman-adv: drop NULL check for immutable hardif->mesh_iface
batman-adv: drop unneeded goto and initialization from batadv_hardif_disable_interface()
batman-adv: move hardif generation counter into batadv_priv
batman-adv: remove BATADV_IF_NOT_IN_USE hardif state
batman-adv: make hard_iface->mesh_iface immutable
batman-adv: remove global hardif list
batman-adv: create hardif only for netdevs that are part of a mesh
====================
Link: https://patch.msgid.link/
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
The RPS test needs a free CPU within the first RPS_MAX_CPUS (16)
cores. This is easily violated if the NIC or env allocates the
IRQs to cores linearly.
Cap the Rx queues at 8, we don't need more. This makes the test
pass on CX7 in NIPA.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20260629234354.2154541-1-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
The phylink_mac_ops '.validate()' has been removed in:
commit da5f6b80ad64 ("net: phylink: remove .validate() method")
There are still a few comments around in phylink that references that,
related to the ports fields as well as the Pause configuration. Let's
drop these references and update the comments related to Pause handling.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260630083700.2041915-1-maxime.chevallier@bootlin.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Uncorrectable errors from different endpoints in the device are steered to
the USP(Upstream Switch Port) which is a PCI Advanced Error Reporting (AER)
Compliant device. Downgrade all the errors to non-fatal to prevent PCIe
bus driver from triggering a Secondary Bus Reset (SBR). This allows error
detection, containment and recovery in the driver.
The Uncorrectable Error Severity Register has the 'Uncorrectable
Internal Error Severity' set to fatal by default. Set this to
non-fatal and unmask the error.
Reviewed-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com>
Link: https://patch.msgid.link/20260629082802.3690896-10-riana.tauro@intel.com
Signed-off-by: Riana Tauro <riana.tauro@intel.com>
|
|
When a fatal error occurs and the error_detected callback is
invoked the device is inaccessible. The error_detected callback
wedges the device causing the jobs to timeout.
The timedout handler acquires forcewake to dump devcoredump and
triggers a GT reset. Since the device is inaccessible this causes
errors. Skip all mmio accesses and gt reset when the device
is in reset.
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Reviewed-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com>
Link: https://patch.msgid.link/20260629082802.3690896-9-riana.tauro@intel.com
Signed-off-by: Riana Tauro <riana.tauro@intel.com>
|
|
Add devres grouping to handle device resource cleanup during
PCI error recovery.
Secondary Bus Reset (SBR) is triggered by PCI core when the
error_detected/mmio_enabled callbacks return PCI_ERS_RESULT_NEED_RESET.
Once SBR is complete, the slot_reset callback is triggered. SBR wipes
out all device memory requiring XE KMD to perform a device removal and
reprobe.
Calling xe_pci_remove() alone does not free the devres allocated.
Since there are no exported functions to release all devres, group the
devres allocations and release the entire group during slot reset to
ensure proper cleanup.
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Reviewed-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com>
Link: https://patch.msgid.link/20260629082802.3690896-8-riana.tauro@intel.com
Signed-off-by: Riana Tauro <riana.tauro@intel.com>
|
|
Add error_detected, mmio_enabled, slot_reset and resume recovery callbacks
to handle PCIe Advanced Error Reporting (AER) errors.
For fatal errors, the device is wedged and becomes inaccessible. Return
PCI_ERS_RESULT_NEED_RESET from error_detected to request a Secondary
Bus Reset (SBR).
For non-fatal errors, return PCI_ERS_RESULT_CAN_RECOVER from
error_detected to trigger the mmio_enabled callback. In this callback, the
device is queried to determine the error cause and attempt recovery based
on the error type.
Once the secondary bus reset(SBR) is completed the slot_reset callback
cleanly removes and reprobe the device to restore functionality.
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com>
Link: https://patch.msgid.link/20260629082802.3690896-7-riana.tauro@intel.com
Signed-off-by: Riana Tauro <riana.tauro@intel.com>
|
|
This is to be included by all contributors and will be leaned on for
Sashiko's "reply to author" support.
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Load balancing can migrate delayed dequeue tasks to even the load between
CPUs.
sched_balance_rq()
-> detach_task()
-> deactivate_task(DEQUEUE_NOCLOCK)
-> set_task_cpu(dst_cpu)
-> attach_task()
-> activate_task(ENQUEUE_NOCLOCK)
-> wakeup_preempt()
A delayed task with shorter slice can be dequeued during pick_next_entity()
but then jump to preempt because eligible.
Always jump to update for delayed dequeue task even with shorter slice.
Fixes: ba0d3bf5f97b ("sched/eevdf: Cancel slice protection if short slice task is eligible")
Reported-by: K Prateek Nayak <kprateek.nayak@amd.com>
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com>
Tested-by: K Prateek Nayak <kprateek.nayak@amd.com>
Link: https://patch.msgid.link/20260701164920.1571352-1-vincent.guittot@linaro.org
|
|
The num_fences, count, i, and j variables in dma_fence_dedup_array() and
__dma_fence_unwrap_merge() have inconsistent integer types, mixing both
unsigned int and int.
Use type size_t consistently for these instead, and update the return
type of dma_fence_dedup_array() accordingly.
Signed-off-by: Shahyan Soltani <shahyan.soltani@amd.com>
Suggested-by: Philipp Stanner <phasta@mailbox.org>
Link: https://lore.kernel.org/r/20260630160401.67544-1-shahyan.soltani@amd.com
Reviewed-by: Philipp Stanner <phasta@kernel.org>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
|
|
hws_bwc_matcher_move() allocates a replacement matcher before setting it
as the resize target. If mlx5hws_matcher_resize_set_target() fails, the
replacement matcher is not attached anywhere and is leaked.
Fix the leak by destroying the replacement matcher before returning from
the resize-target failure path.
The bug was first flagged by an experimental analysis tool we are
developing for kernel memory-management bugs while analyzing
v6.13-rc1. The tool is still under development and is not yet publicly
available. Manual inspection confirms that the bug is still
present in v7.1.1.
An x86_64 allyesconfig build showed no new warnings. As we do not have a
mlx5 HWS-capable device to test with, no runtime testing was able to be
performed.
Fixes: 2111bb970c78 ("net/mlx5: HWS, added backward-compatible API handling")
Cc: stable@vger.kernel.org
Signed-off-by: Dawei Feng <dawei.feng@seu.edu.cn>
Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
Acked-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260629064049.3852759-1-dawei.feng@seu.edu.cn
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
syzbot reported a stack-out-of-bounds read in xfrm_state_find()
which flows from xfrm_tmpl_resolve_one().
Commit 3d776e31c841 ("xfrm: Reject optional tunnel/BEET mode
templates in outbound policies") disallowed optional tunnel and
BEET in outbound policies to prevent this. Later when IPTFS
added, it was not covered by that fix and can still trigger
the out-of-bounds read;
Extend the check to disallow optional IPTFS in outbound policies
as well. IPTFS should be identical to tunnel mode.
IN and FWD policies are not affected: xfrm_tmpl_resolve_one()
is only reachable via the outbound path.
Reproducer, before:
ip link add dummy0 type dummy
ip link set dummy0 up
ip addr add 10.1.1.1/24 dev dummy0
ip xfrm policy add src 10.1.1.1/32 dst 10.1.1.2/32 dir out tmpl
src fc00::dead:1 dst fc00::dead:2 proto esp reqid 1 mode iptfs
level use tmpl src fc00::dead:1 dst fc00::dead:2 proto esp reqid
2 mode transport
ping -W 1 -c 1 10.1.1.2
PING 10.1.1.2 (10.1.1.2) 56(84) bytes of data.
[ 64.168420] ==================================================================
[ 64.169977] BUG: KASAN: stack-out-of-bounds in __xfrm6_addr_hash+0x11e/0x170
[ 64.169977] Read of size 4 at addr ffff88800e1ffd20 by task ping/2844
[ 64.169977] CPU: 2 UID: 0 PID: 2844 Comm: ping Not tainted 7.1.0-rc7-00180-geb23b588430a #98 PREEMPT(full)
[ 64.169977] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 64.169977] Call Trace:
[ 64.169977] <TASK>
[ 64.169977] dump_stack_lvl+0x47/0x70
[ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170
[ 64.169977] print_report+0x152/0x4b0
[ 64.169977] ? ksys_mmap_pgoff+0x6d/0xa0
[ 64.169977] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 64.169977] ? rcu_read_unlock_sched+0xa/0x20
[ 64.169977] ? __virt_addr_valid+0x21b/0x230
[ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170
[ 64.169977] kasan_report+0xa8/0xd0
[ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170
[ 64.169977] __xfrm6_addr_hash+0x11e/0x170
[ 64.169977] __xfrm_dst_hash+0x24/0xc0
[ 64.169977] xfrm_state_find+0xa2d/0x2f90
[ 64.169977] ? __pfx_xfrm_state_find+0x10/0x10
[ 64.169977] ? __pfx_ftrace_graph_ret_addr+0x10/0x10
[ 64.169977] ? __pfx_ftrace_graph_ret_addr+0x10/0x10
[ 64.169977] xfrm_tmpl_resolve_one+0x210/0x570
[ 64.169977] ? __pfx_xfrm_tmpl_resolve_one+0x10/0x10
[ 64.169977] ? __pfx_stack_trace_consume_entry+0x10/0x10
[ 64.169977] ? kernel_text_address+0x5b/0x80
[ 64.169977] ? __kernel_text_address+0xe/0x30
[ 64.169977] ? unwind_get_return_address+0x5e/0x90
[ 64.169977] ? arch_stack_walk+0x8c/0xe0
[ 64.169977] xfrm_tmpl_resolve+0x130/0x200
[ 64.169977] ? __pfx_xfrm_tmpl_resolve+0x10/0x10
[ 64.169977] ? __pfx_xfrm_policy_inexact_lookup_rcu+0x10/0x10
[ 64.169977] ? __refcount_add_not_zero.constprop.0+0xb2/0x110
[ 64.169977] ? __pfx___refcount_add_not_zero.constprop.0+0x10/0x10
[ 64.169977] xfrm_resolve_and_create_bundle+0xd5/0x310
[ 64.169977] ? __pfx_xfrm_resolve_and_create_bundle+0x10/0x10
[ 64.169977] ? __pfx_xfrm_policy_lookup_bytype+0x10/0x10
[ 64.169977] ? __pfx_xfrm_policy_lookup_bytype+0x10/0x10
[ 64.169977] xfrm_lookup_with_ifid+0x3d8/0xb80
[ 64.169977] ? __pfx_xfrm_lookup_with_ifid+0x10/0x10
[ 64.169977] ? ip_route_output_key_hash+0xc6/0x110
[ 64.169977] ? kasan_save_track+0x10/0x30
[ 64.169977] xfrm_lookup_route+0x18/0xe0
[ 64.169977] ip4_datagram_release_cb+0x4c9/0x530
[ 64.169977] ? __pfx_ip4_datagram_release_cb+0x10/0x10
[ 64.169977] ? do_raw_spin_lock+0x71/0xc0
[ 64.169977] ? __pfx_do_raw_spin_lock+0x10/0x10
[ 64.169977] release_sock+0xb0/0x170
[ 64.169977] udp_connect+0x43/0x50
[ 64.169977] __sys_connect+0xa6/0x100
[ 64.169977] ? alloc_fd+0x2e9/0x300
[ 64.169977] ? __pfx___sys_connect+0x10/0x10
[ 64.169977] ? preempt_latency_start+0x1f/0x70
[ 64.169977] ? fd_install+0x7e/0x150
[ 64.169977] ? rcu_read_unlock_sched+0xa/0x20
[ 64.169977] ? __sys_socket+0xdf/0x130
[ 64.169977] ? __pfx___sys_socket+0x10/0x10
[ 64.169977] ? vma_refcount_put+0x43/0xa0
[ 64.169977] __x64_sys_connect+0x7e/0x90
[ 64.169977] do_syscall_64+0x11b/0x2b0
[ 64.169977] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 64.169977] RIP: 0033:0x7f4851ecb570
[ 64.169977] Code: 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 80 3d f9 ca 0d 00 00 74 17 b8 2a 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 48 83 ec 18 89 54
[ 64.169977] RSP: 002b:00007ffc830e3498 EFLAGS: 00000202 ORIG_RAX: 000000000000002a
[ 64.169977] RAX: ffffffffffffffda RBX: 00007ffc830e34d0 RCX: 00007f4851ecb570
[ 64.169977] RDX: 0000000000000010 RSI: 00007ffc830e34d0 RDI: 0000000000000005
[ 64.169977] RBP: 0000000000000000 R08: 0000000000000003 R09: 0000000000000000
[ 64.169977] R10: 0000000000000006 R11: 0000000000000202 R12: 0000000000000005
[ 64.169977] R13: 0000000000000000 R14: 00005619a863f340 R15: 0000000000000000
[ 64.169977] </TASK>
[ 64.169977] The buggy address belongs to stack of task ping/2844
[ 64.169977] and is located at offset 88 in frame:
[ 64.169977] ip4_datagram_release_cb+0x0/0x530
[ 64.169977] This frame has 1 object:
[ 64.169977] [32, 88) 'fl4'
[ 64.169977] The buggy address belongs to the physical page:
[ 64.169977] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xe1ff
[ 64.169977] flags: 0x4000000000000000(zone=1)
[ 64.169977] raw: 4000000000000000 0000000000000000 ffffea0000387fc8 0000000000000000
[ 64.169977] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
[ 64.169977] page dumped because: kasan: bad access detected
[ 64.169977] Memory state around the buggy address:
[ 64.169977] ffff88800e1ffc00: f2 f2 00 00 f3 f3 00 00 00 00 00 00 00 00 00 00
[ 64.169977] ffff88800e1ffc80: 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00
[ 64.169977] >ffff88800e1ffd00: 00 00 00 00 f3 f3 f3 f3 f3 00 00 00 00 00 00 00
[ 64.169977] ^
[ 64.169977] ffff88800e1ffd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
[ 64.169977] ffff88800e1ffe00: f1 f1 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 64.169977] ==================================================================
[ 64.245153] Disabling lock debugging due to kernel taint
After the fix:
ip xfrm policy add src 10.1.1.1/32 dst 10.1.1.2/32 dir out tmpl \
src fc00::dead:1 dst fc00::dead:2 proto esp reqid 1 mode iptfs \
level use tmpl src fc00::dead:1 dst fc00::dead:2 proto esp reqid 2 \
mode transport
Error: Mode in optional template not allowed in outbound policy.
Fixes: d1716d5a44c3 ("xfrm: add generic iptfs defines and functionality")
Reported-by: syzbot+0ac4d84afe1066a1f3e9@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/all/6a3ceb94.43b4ff68.30a095.0004.GAE@google.com/T/
Signed-off-by: Antony Antony <antony.antony@secunet.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
|
|
copy_to_user_state_extra() only holds a reference to the outer xfrm_state.
That does not pin x->xso.dev. NETDEV_DOWN and NETDEV_UNREGISTER can race
through xfrm_dev_state_flush(), xfrm_state_delete(), and
xfrm_dev_state_free(), which clears xso->dev and drops the netdev
reference before the GETSA dump reaches xso_to_xuo() and reads
xso->dev->ifindex.
The buggy scenario involves two paths, with each column showing the order
within that path:
XFRM_MSG_GETSA dump path: NETDEV teardown path:
1. xfrm_get_sa() gets xfrm_state 1. xfrm_dev_state_flush() finds x
2. copy_to_user_state_extra() sees 2. xfrm_state_delete() removes x
x->xso.dev from the SAD
3. copy_user_offload() calls 3. xfrm_dev_state_free() clears
xso_to_xuo() xso->dev
4. xso->dev->ifindex dereferences 4. netdev_put() drops the device
a detached net_device reference
Avoid following the live net_device from the dump paths. Cache the
attached ifindex in xfrm_dev_offload when state or policy offload is bound
to a device, and serialize that snapshot instead. This preserves the
user-visible XFRMA_OFFLOAD_DEV value without depending on the embedded
net_device lifetime.
Validation reproduced this kernel report:
Oops: general protection fault
Call Trace:
<TASK>
copy_to_user_state_extra+0xb8d/0x1370 [xfrm_user]
? __pfx_copy_to_user_state_extra+0x10/0x10 [xfrm_user]
? __asan_memset+0x23/0x50
? srso_alias_return_thunk+0x5/0xfbef5
? __alloc_skb+0x342/0x960
? srso_alias_return_thunk+0x5/0xfbef5
? __asan_memset+0x23/0x50
? srso_alias_return_thunk+0x5/0xfbef5
? __nlmsg_put+0x147/0x1b0
dump_one_state+0x1c7/0x3e0 [xfrm_user]
xfrm_state_netlink+0xcb/0x130 [xfrm_user]
? __pfx_xfrm_state_netlink+0x10/0x10 [xfrm_user]
? srso_alias_return_thunk+0x5/0xfbef5
? xfrm_user_state_lookup.constprop.0+0x230/0x310 [xfrm_user]
xfrm_get_sa+0x102/0x250 [xfrm_user]
? __pfx_xfrm_get_sa+0x10/0x10 [xfrm_user]
xfrm_user_rcv_msg+0x504/0xaa0 [xfrm_user]
? __pfx_xfrm_user_rcv_msg+0x10/0x10 [xfrm_user]
? srso_alias_return_thunk+0x5/0xfbef5
? stack_trace_save+0x8e/0xc0
? __pfx_stack_trace_save+0x10/0x10
netlink_rcv_skb+0x11f/0x350
? __pfx_xfrm_user_rcv_msg+0x10/0x10 [xfrm_user]
? __pfx_netlink_rcv_skb+0x10/0x10
? __pfx_mutex_lock+0x10/0x10
? srso_alias_return_thunk+0x5/0xfbef5
xfrm_netlink_rcv+0x65/0x80 [xfrm_user]
netlink_unicast+0x600/0x870
? __pfx_netlink_unicast+0x10/0x10
? srso_alias_return_thunk+0x5/0xfbef5
? __pfx_stack_trace_save+0x10/0x10
netlink_sendmsg+0x75d/0xc10
? __pfx_netlink_sendmsg+0x10/0x10
? srso_alias_return_thunk+0x5/0xfbef5
____sys_sendmsg+0x77a/0x900
? srso_alias_return_thunk+0x5/0xfbef5
? __pfx_____sys_sendmsg+0x10/0x10
? __pfx_copy_msghdr_from_user+0x10/0x10
? release_sock+0x1a/0x1d0
? srso_alias_return_thunk+0x5/0xfbef5
? netlink_insert+0x143/0xec0
___sys_sendmsg+0xff/0x180
? __pfx____sys_sendmsg+0x10/0x10
? _raw_spin_lock_irqsave+0x85/0xe0
? do_getsockname+0xf9/0x170
? srso_alias_return_thunk+0x5/0xfbef5
? fdget+0x53/0x3b0
__sys_sendmsg+0x111/0x1a0
? __pfx___sys_sendmsg+0x10/0x10
? srso_alias_return_thunk+0x5/0xfbef5
? __sys_getsockname+0x8c/0x100
do_syscall_64+0x102/0x5a0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Fixes: 07b87f9eea0c ("xfrm: Fix unregister netdevice hang on hardware offload.")
Assisted-by: Codex:gpt-5.5
Signed-off-by: Cen Zhang <zzzccc427@gmail.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
|
|
xfrm_user_policy() clears the socket dst cache with __sk_dst_reset(),
i.e. the non-atomic __sk_dst_set(sk, NULL): it reads sk_dst_cache with
rcu_dereference_protected(), stores NULL and dst_release()s the old dst.
That is only safe if no other thread modifies sk_dst_cache concurrently.
For a connected UDP socket that does not hold: the transmit fast path
(udp_sendmsg -> sk_dst_check -> sk_dst_reset) resets the cache locklessly
with an atomic xchg(). A per-socket policy change racing a send can make
both sides observe the same old dst and each dst_release() it, dropping
the socket's single reference twice and freeing the xfrm_dst bundle while
it is still referenced:
BUG: KASAN: slab-use-after-free in dst_release
Write of size 4 at addr ffff88801897b6c0 by task exploit/155
Call Trace:
...
dst_release (... ./include/linux/rcuref.h:109)
xfrm_user_policy (./include/net/sock.h:2239 ./include/net/sock.h:2256 net/xfrm/xfrm_state.c:3053)
do_ip_setsockopt (net/ipv4/ip_sockglue.c:1347)
ip_setsockopt (net/ipv4/ip_sockglue.c:1417)
do_sock_setsockopt (net/socket.c:2368)
__sys_setsockopt (net/socket.c:2393)
__x64_sys_setsockopt (net/socket.c:2396)
do_syscall_64 (arch/x86/entry/syscall_64.c:94)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
Reachable by an unprivileged user via a user+network namespace.
Use the atomic sk_dst_reset() so the cache is cleared and released with a
single xchg(): whichever side wins releases the dst once, the other sees
NULL and does nothing. Behaviour is otherwise unchanged.
Fixes: 2b06cdf3e688 ("xfrm: Clear sk_dst_cache when applying per-socket policy.")
Fixes: be8f8284cd89 ("net: xfrm: allow clearing socket xfrm policies.")
Reported-by: AutonomousCodeSecurity@microsoft.com
Signed-off-by: Xiang Mei (Microsoft) <xmei5@asu.edu>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
|
|
Mike Rapoport <rppt@kernel.org> says:
Make the behaviour of kernelcore= parameter uniform and treat mirror
just as another way to size the zones and cleanup a weird part of the
memory map initialization.
For example, for the memory layout below with the first two memory
ranges being mirrored (flags=0x2)
memory[0x0] [0x0000000000001000-0x000000000009efff], 0x000000000009e000 bytes on node 0 flags: 0x2
memory[0x1] [0x0000000000100000-0x00000000bffdefff], 0x00000000bfedf000 bytes on node 0 flags: 0x2
memory[0x2] [0x0000000100000000-0x000000013fffffff], 0x0000000040000000 bytes on node 0 flags: 0x2
memory[0x3] [0x0000000140000000-0x00000001bfffffff], 0x0000000080000000 bytes on node 0 flags: 0x0
with kernelcore=mirror set zone ranges would be
Normal [100000, 1c0000]
Movable [140000, 1c0000]
and range [140000, 1c0000] is spanned by both NORMAL and MOVABLE zones.
This range will be passed twice to memmap_init_range() - once for each
zone that spans it.
The memory map for this range will be initialized as ZONE_NORMAL during the
first pass and skipped because of overlap_memmap_init() during the second
pass (ZONE_MOVABLE initialization), although the pages in this range
actually belong to ZONE_MOVABLE.
Aligning kernelcore=mirror behaviour with other variants of
kernelcore=/movablecore= resolves this issue and makes the code less
obfuscated.
patches from https://patch.msgid.link/20260630072212.624305-1-rppt@kernel.org
mm/mm_init: don't overlap NORMAL and MOVABLE zones with kernelcore=mirror
mm/mm_init: drop overlap_memmap_init()
Link: https://patch.msgid.link/20260630072212.624305-1-rppt@kernel.org
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
|
|
When ZONE_NORMAL and ZONE_MOVABLE could overlap because kernelcore=mirror
didn't reduce the span of ZONE_NORMAL, initialization of the memory map had
to skip overlapping pages during initialization of ZONE_MOVABLE to avoid
double initialization of the same struct pages.
Since kernelcore=mirror works now the same way as other variants of
kernelcore=/movablecore=, and adjusts the span of ZONE_NORMAL, there can't
be an overlap between ZONE_NORMAL and ZONE_MOVABLE.
Remove overlap_memmap_init().
Co-developed-by: Wei Yang <richard.weiyang@gmail.com>
Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
Reviewed-by: David Hildenbrand (Arm) <david@kernel.org>
Link: https://patch.msgid.link/20260630072212.624305-3-rppt@kernel.org
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Reviewed-by: David Hildenbrand (Arm) <david@kernel.org>
|
|
When kernelcore or movablecore kernel parameters define size of the
NORMAL and MOVABLE zones as percents of the total memory or by absolute
value, ZONE_NORMAL is clamped at the beginning of ZONE_MOVABLE.
However, when kernelcore=mirror the ZONE_NORMAL span is not changed but
rather pages from ZONE_MOVABLE counted as absent in ZONE_NORMAL.
Make the behaviour of kernelcore= parameter uniform and treat mirror
just as another way to size the zones.
Co-developed-by: Wei Yang <richard.weiyang@gmail.com>
Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
Link: https://patch.msgid.link/20260630072212.624305-2-rppt@kernel.org
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Reviewed-by: David Hildenbrand (Arm) <david@kernel.org>
|
|
As documented in comments in struct xen_memory_exchange, the input to the
hypercall is a set of MFNs which are to be removed from the domain, plus a
set of PFNs where the newly allocated MFNs are to appear. Present comment
and parameter naming don't correctly reflect that.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Message-ID: <7e0c8795-cc60-4b78-8601-6a999739467a@suse.com>
|
|
IPQ5210 SoCs expose CPU frequency limits through an eFuse speed bin, and
the valid CPU OPPs depend on the SoC variant.
Add IPQ5210 support to the Qualcomm NVMEM cpufreq driver so the supported
OPPs can be selected at runtime using the eFuse value and the opp-
supported-hw OPP property. Also block the generic cpufreq-dt platform
device for IPQ5210 so the NVMEM-based driver is used.
Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
[ Viresh: Converted `!=` to `==` ]
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
According to Bspec we only need to write SSC Enable PLL A bit
and leave PLL B bit alone in PORT_CLOCK_CTL register.
Bspec: 74667, 74492
Fixes: 3383ba2479f7 ("drm/i915/ltphy: Enable SSC during port clock programming")
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20260701091503.1302226-3-suraj.kandpal@intel.com
|
|
We need to readout the ssc_enabled param for LT PHY pll state too.
Create a function that does that, we only need to read SSC Enable PLL A
bit since that is the only one we write Xe3p onwards. While at it
improve the dump using str_yes_or_no.
Bspec: 74667
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20260701091503.1302226-2-suraj.kandpal@intel.com
|
|
tools/include/linux/overflow.h uses SIZE_MAX in its size helper functions.
Include stdint.h so tools users that include overflow.h without another
SIZE_MAX provider can build.
Link: https://lore.kernel.org/20260629022124.131894-3-chenyichong@uniontech.com
Signed-off-by: Yichong Chen <chenyichong@uniontech.com>
Acked-by: Eugenio Pérez <eperezma@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
Patch series "tools: Fix tools/virtio test build", v2.
This series fixes build failures hit by:
make -C tools/virtio test
Patch 1 adds tools/virtio compatibility definitions needed by current
virtio headers when building the tools/virtio tests. Patch 2 makes
tools/include/linux/overflow.h include stdint.h for SIZE_MAX, which is
used by its size helper functions.
With the series applied, make -C tools/virtio test builds virtio_test,
vringh_test and vhost_net_test successfully.
Tested on x86_64 and arm64 with:
make -C tools/virtio clean
make -C tools/virtio test
This patch (of 2):
vhost_net_test builds virtio_ring.c in userspace.
Recent virtio headers pull in helper headers that are not provided by the
tools/virtio compatibility layer, including asm/percpu_types.h,
linux/completion.h, linux/mod_devicetable.h and linux/virtio_features.h.
Add the missing compat definitions and the DMA attribute used by the
current virtio ring code.
Link: https://lore.kernel.org/20260629022124.131894-1-chenyichong@uniontech.com
Link: https://lore.kernel.org/20260629022124.131894-2-chenyichong@uniontech.com
Signed-off-by: Yichong Chen <chenyichong@uniontech.com>
Acked-by: Eugenio Pérez <eperezma@redhat.com>
Cc: chenyichong <chenyichong@uniontech.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
Ever since idmapped mounts were introduced, inode ownership checks (for
side-channel protection) in mincore() and madvise(MADV_PAGEOUT) were done
against the nop_mnt_idmap, which completely ignores the file's mount's
idmap. This results in odd edgecases like:
1) mount/bind-mount with an idmap userA:userB:1
2) userB runs an owner_or_capable() check on file that is owned by userA
on-disk/in-memory, but owned by userB after idmap translation
3) owner_or_capable() mysteriously fails as the correct idmap wasn't supplied
In the case of mincore/madvise MADV_PAGEOUT, this is usually benign,
because file_permission(file, MAY_WRITE) will probably succeed, as it uses
the proper idmap internally, but it does not need to be the case on e.g a
0444 file where even the owner itself doesn't have permissions to write to
it.
Since this is clearly not trivial to get right, introduce a
file_owner_or_capable() that can carry the correct semantics, and switch
the various users in mm to it.
The issue was found by manual code inspection & an off-list discussion
with Jan Kara.
Link: https://lore.kernel.org/20260625153853.913949-1-pfalcato@suse.de
Fixes: 9caccd41541a ("fs: introduce MOUNT_ATTR_IDMAP")
Signed-off-by: Pedro Falcato <pfalcato@suse.de>
Reviewed-by: Jan Kara <jack@suse.cz>
Reviewed-by: Christian Brauner (Amutable) <brauner@kernel.org>
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Jann Horn <jannh@google.com>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Vlastimil Babka <vbabka@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
The comment on top of `struct damon_region` clearly says that
For any use case, @ar should be non-zero positive size.
which is now verified in damon_verify_new_region() if the kernel is built
with DAMON_DEBUG_SANITY.
The WARN_ONCE() can be triggered if the mtier sample module is enabled
before node{0,1}_{start,end}_addr have been properly initialized, which is
obviously not good.
------------[ cut here ]------------
start 0 >= end 0
WARNING: mm/damon/core.c:217 at damon_new_region+0xf4/0x118, CPU#59: bash/341468
Call trace:
damon_new_region+0xf4/0x118 (P)
damon_set_regions+0xfc/0x3c0
damon_sample_mtier_build_ctx+0xe8/0x3a8
damon_sample_mtier_start+0x1c/0x90
damon_sample_mtier_enable_store+0x98/0xb0
param_attr_store+0xb4/0x128
module_attr_store+0x2c/0x50
sysfs_kf_write+0x58/0x90
kernfs_fop_write_iter+0x16c/0x238
vfs_write+0x2c0/0x370
ksys_write+0x74/0x118
__arm64_sys_write+0x24/0x38
invoke_syscall+0xa8/0x118
el0_svc_common.constprop.0+0x48/0xf0
do_el0_svc+0x24/0x38
el0_svc+0x54/0x370
el0t_64_sync_handler+0xa0/0xe8
el0t_64_sync+0x1ac/0x1b0
---[ end trace 0000000000000000 ]---
Note that the same issue can happen if detect_node_addresses is true, and
node 0 or 1 is memoryless. Fix it together by checking the validity of
parameters right before damon_new_region() and fail early if they're
invalid.
Link: https://lore.kernel.org/20260629144432.133962-1-sj@kernel.org
Fixes: 82a08bde3cf7 ("samples/damon: implement a DAMON module for memory tiering")
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: SJ Park <sj@kernel.org>
Reviewed-by: SJ Park <sj@kernel.org>
Cc: <stable@vger.kernel.org> # 6.16.x
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
As MM is slowly transitioning towards a more distributed maintainership
model, we agreed with Matthew that I will be a co-maintainer in case he is
not available.
Link: https://lore.kernel.org/20260629135927.2586391-2-jack@suse.cz
Signed-off-by: Jan Kara <jack@suse.cz>
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
Acked-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Acked-by: Lorenzo Stoakes <ljs@kernel.org>
Cc: Christian Brauner <brauner@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
Fix below kernel document build warning:
WARNING: ../include/linux/damon.h:909 struct member 'rnd_state' not described in 'damon_ctx'
Link: https://lore.kernel.org/20260628220808.98931-3-sj@kernel.org
Fixes: 9012c4e647df ("mm/damon: replace damon_rand() with a per-ctx lockless PRNG")
Signed-off-by: SJ Park <sj@kernel.org>
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Closes: https://lore.kernel.org/4df95955-b255-4e5a-90c4-35db02f3111f@infradead.org
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
The two fields of damon_ctx struct dont have their kernel-doc comments.
That causes kernel document builds to warn. Fix those.
This patch (of 2):
Fix below document build warning:
WARNING: ../include/linux/damon.h:909 struct member 'probes' not described in 'damon_ctx'
Link: https://lore.kernel.org/20260628220808.98931-1-sj@kernel.org
Link: https://lore.kernel.org/20260628220808.98931-2-sj@kernel.org
Fixes: 18c777859f28 ("mm/damon/core: embed damon_probe objects in damon_ctx")
Signed-off-by: SJ Park <sj@kernel.org>
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Closes: https://lore.kernel.org/4df95955-b255-4e5a-90c4-35db02f3111f@infradead.org
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
I have used multiple email addresses for my kernel contributions, and some
of them are no longer active. Add all to .mailmap for clarity.
Link: https://lore.kernel.org/20260628150203.4105796-1-radu@rendec.net
Signed-off-by: Radu Rendec <radu@rendec.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
The following compilation error occurs with an old version of glibc due to
a recent commit adding MADV_COLLAPSE testing:
[root@localhost mm]# getconf GNU_LIBC_VERSION
glibc 2.34
[root@localhost mm]# make
CC hmm-tests
hmm-tests.c: In function 'hmm_migrate_anon_huge_fault':
hmm-tests.c:2355:27: error: 'MADV_COLLAPSE' undeclared (first use in this function); did you mean 'MADV_COLD'?
2355 | ret = madvise(map, size, MADV_COLLAPSE);
| ^~~~~~~~~~~~~
| MADV_COLD
hmm-tests.c:2355:27: note: each undeclared identifier is reported only once for each function it appears in
make: *** [../lib.mk:225: /root/code/linux/tools/testing/selftests/mm/hmm-tests] Error 1
Include linux/mman.h (which provides the definition of MADV_COLLAPSE) to
fix the build error.
Link: https://lore.kernel.org/20260628143111.36863-1-zenghui.yu@linux.dev
Fixes: e3d8707358ea ("selftests/mm/hmm-tests: test pagemap reads of PMD device-private entries")
Signed-off-by: Zenghui Yu <zenghui.yu@linux.dev>
Reviewed-by: Lorenzo Stoakes <ljs@kernel.org>
Reviewed-by: Dev Jain <dev.jain@arm.com>
Cc: David Hildenbrand <david@kernel.org>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Leon Romanovsky <leon@kernel.org>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Vlastimil Babka <vbabka@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
There are several places in transact_test() where we use the hardcoded
0x1000 (4k) as page size, which is not always correct for architectures
supporting multiple page sizes.
Switch to use the correct page size. Otherwise ./ksft_pagemap.sh on a
16k-page-size arm64 box fails with
$ ./ksft_pagemap.sh
[...]
# ok 96 mprotect_tests Both pages written after remap and mprotect
# ok 97 mprotect_tests Clear and make the pages written
# Bail out! ioctl failed
# # Planned tests != run tests (117 != 97)
# # Totals: pass:97 fail:0 xfail:0 xpass:0 skip:0 error:0
# [FAIL]
not ok 1 pagemap_ioctl # exit=1
# SUMMARY: PASS=0 SKIP=0 FAIL=1
1..1
Link: https://lore.kernel.org/20260628101118.35861-1-zenghui.yu@linux.dev
Fixes: 46fd75d4a3c9 ("selftests: mm: add pagemap ioctl tests")
Signed-off-by: Zenghui Yu <zenghui.yu@linux.dev>
Cc: Muhammad Usama Anjum <usama.anjum@arm.com>
Cc: David Hildenbrand <david@kernel.org>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Vlastimil Babka <vbabka@kernel.org>
Cc: Zenghui Yu <zenghui.yu@linux.dev>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
