| Age | Commit message (Collapse) | Author |
|---|
|
Commit 730ff06d3f5c ("net: mana: Use page pool fragments for RX buffers
instead of full pages to improve memory efficiency.") started handing
out RX buffers with zero headroom so that two buffers fit into one page
at the default MTU.
The MANA TX path, however, stores the per scatter-gather entry DMA
mappings in `struct mana_skb_head` at skb->head, and mana_start_xmit()
therefore calls skb_cow_head(skb, MANA_HEADROOM). The port advertises
this requirement as ndev->needed_headroom = MANA_HEADROOM.
As a result every packet that is received and then forwarded out of a
MANA port fails the skb_cow() in ip_forward() and gets reallocated and
copied by pskb_expand_head(). This is invisible to a plain RX or TX
workload, but it puts a full skb reallocation plus memcpy on the hot
path of every single forwarded packet, which is exactly what a
router/NVA workload does.
Restore the headroom. Note that reserving MANA_HEADROOM (232) is not
enough: ip_forward() asks for LL_RESERVED_SPACE(dev), which rounds
hard_header_len + needed_headroom up to HH_DATA_MOD and is 256 bytes on
ethernet. Use LL_RESERVED_SPACE() directly so the value keeps tracking
both constants. Also, since LL_RESERVED_SPACE() tracks MANA_HEADROOM,
it grows with MAX_SKB_FRAGS and for MAX_SKB_FRAGS >= 19 it is greater
than 256, so we have to account for that by using the headroom the RX
queue actually uses (instead of assuming XDP_PACKET_HEADROOM) and
turning MANA_XDP_MTU_MAX into MANA_XDP_MTU_MAX(ndev) (note that at the
default CONFIG_MAX_SKB_FRAGS=17 they are equivalent).
At the default MTU on a 4K page this means a buffer no longer fits twice
into a page (SKB_DATA_ALIGN(1500 + MANA_RXBUF_PAD + 256) = 2112), so the
frag-vs-single decision is now made by computing the real buffer size
instead of comparing the MTU against PAGE_SIZE / 2. The page_pool
fragment path is still used wherever at least two buffers genuinely fit,
e.g. on 16K and 64K page sizes.
Measured on an Azure VM with a MANA NIC acting as a forwarding NVA (UDP,
1400 byte payload, 4 streams, 8 Gbps offered, only the forwarding
node's kernel differs), 8 runs each, median:
forwarded pps throughput
before 272,830 3.06 Gbps
after 390,560 4.37 Gbps (+43%)
perf on the forwarding node, same workload:
memset_orig __pi_memcpy pskb_expand_head
before 10.07% 3.96% present
after 0.94% 0.64% gone
Cc: stable@vger.kernel.org
Fixes: 730ff06d3f5c ("net: mana: Use page pool fragments for RX buffers instead of full pages to improve memory efficiency.")
Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20261003013647.2051416-1-hamzamahfooz@linux.microsoft.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
is_journal_aborted() reads journal->j_flags from ext4 and JBD2 hot
paths. At the same time, transaction start and stop paths repeatedly
acquire and release j_state_lock. read_lock() and read_unlock() update
the lock word, so this traffic invalidates the cache line containing
j_flags.
On the tested x86-64 build, j_flags, j_errno, and j_state_lock occupy
the same 64-byte cache line. j_flags starts at offset 0, j_errno at
offset 8, and j_state_lock at offset 56.
Align j_state_lock to a cacheline boundary on SMP builds. This moves it
to offset 64 and prevents lock traffic from invalidating j_flags and
j_errno. Tests were run on Linux 7.3-rc1.
On a two-socket Intel Xeon Silver 4208 system with SMT disabled, CPUs
fixed at 2 GHz, and 16 stress-ng workers, ten-run average bogo-ops/s for
stress-ng.utime, stress-ng.access, stress-ng.file-ioctl, and
stress-ng.open increased by 9.60%, 5.42%, 2.05%, and 4.65%,
respectively. In separate five-run perf c2c measurements, average
Remote HITM samples for the affected j_flags/j_errno line decreased
from 1996, 2041, 1555, and 383 to zero, respectively.
Signed-off-by: JonasZhou-oc <jonaszhou-oc@zhaoxin.com>
Link: https://patch.msgid.link/20260902070331.820322-1-jonaszhou-oc@zhaoxin.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
|
|
Add support for SDM (Secure Device Manager) mailbox doorbell interrupt for
async transactions. On interrupt, a workqueue is triggered which polls the
ATF for pending responses and retrieves the bitmap of all retrieved and
unprocessed transaction ids of mailbox responses from SDM. It then triggers
the corresponding registered callbacks.
Signed-off-by: Mahesh Rao <mahesh.rao@altera.com>
Signed-off-by: Tze Yee Ng <tze.yee.ng@altera.com>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
|
|
On Agilex5, DDR starts at 0x8000_0000 which is outside the SDM's
addressable range. When SMMU is active, the driver must allocate
DMA-coherent buffers and pass IOVAs (not physical addresses) to ATF.
Add SVC_SDM_DMA_ADDR_BITS (29) and SVC_SDM_DMA_ADDR_OFFSET
(0x8000_0000) to constrain IOVAs to the 0-512 MB window the SDM can
reach and to satisfy ATF's address range check respectively.
Extend struct stratix10_svc_data_mem with dma_addr, and
struct stratix10_svc_controller with use_dma_mem and dma_addr_offset.
Update allocate/free and svc_thread_cmd_data_claim() for the DMA path.
Wire the Agilex5 path in probe: require an IOMMU domain for
intel,agilex5-svc, bypass the SDM address remapper via
INTEL_SIP_SMC_SDM_REMAPPER_CONFIG, call svc_setup_dma_memory() to set
the 29-bit DMA mask, select the DMA path through stratix10_svc_pdata,
register a devm cleanup for leaked buffers, and guard err_destroy_pool
against a NULL genpool.
Signed-off-by: Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
|
|
The registered field of hdac_device is a bitfield sharing the same
word with other bitfields like lazy_cache, and those are updated in a
non-atomic read-modify-write manner without any lock. Meanwhile, the
registered flag is read from the unsolicited event worker
concurrently, so the concurrent updates of the neighboring bitfields
may race with it.
Convert it to a plain bool for avoiding such a subtle race. Also
replace the assignments of 0/1 with false/true accordingly.
Assisted-by: LLM
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20261007215650.159871-4-tiwai@suse.de
|
|
At unbinding a codec driver, hda_codec_driver_remove() calls the
codec's remove callback that releases the driver resources, followed
by snd_hda_codec_cleanup_for_unbind(). Meanwhile, the unsolicited
events are processed asynchronously in bus->unsol_work, and
snd_hdac_bus_process_unsol_events() checks only codec->registered flag
before calling the driver's unsol_event callback without the lock.
Since codec->registered is cleared only in
snd_hda_codec_cleanup_for_unbind(), and there is no flush of the unsol
work at unbinding, the unsol event handler may run concurrently during
the running remove callback, which may lead to a UAF. The same
problem applies to the jack polling work, which is canceled only after
the remove callback.
For addressing those races, introduce a new flag unsol_disabled to
hdac_device, to be checked it in the unsol event worker, while a new
helper snd_hdac_device_disable_unsol() sets this flag and flushes the
pending unsol work. The helper is called at hda_codec_driver_remove()
together with the cancel of jackpoll_work to assure that no
asynchronous jack handling can run. The flag is cleared again at
probing the codec driver, while the events are still blocked by the
registered flag until the codec gets registered.
Reported-by: Sashiko <sashiko-bot@kernel.org>
Assisted-by: LLM
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20261007215650.159871-2-tiwai@suse.de
|
|
So far we've used snd_array infrastructure for managing the
hda_jack_tbl elements, but it turned out that this may lead to a UAF
when a different order of destruction procedure is applied; namely,
each hda_jack_tbl object creates a snd_jack object and sets the
private_data pointing to the hda_jack_tbl, and private_free to release
it. It looks harmless, but since snd_array may reallocate the whole
table at growing, the formerly referred jack pointer may become stale.
Fortunately, currently there is no call pattern that triggers this
issue, so it's only hypothetical, but we should address it in anyway.
There are several ways to address this, and at this time, we rather
redesign the hda_jack_tbl allocations: instead of snd_array(), do a
normal kmalloc() + linked list. There will be more kmalloc calls than
the original code, but as the number of jacks are usually at most
handful, it must not be a problem. This change allows us the
persistent jack pointer, so no stale pointer access can happen any
longer.
This also fixes another reported issue about the stale jack pointer
reference in snd_hda_jack_tbl_new(), too.
Fixes: 31ef22579302 ("ALSA: hda - Integrate input-jack stuff into kctl-jack")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20261007171057.7462-1-tiwai@suse.de
|
|
udp_tunnel_dst_lookup() and udp_tunnel6_dst_lookup() return -ELOOP
when the route to the remote end goes out of the vxlan device itself,
and vxlan_xmit_one() counts that in collisions, apart from the
-ENETUNREACH of a failed lookup. The drop reason does not tell them
apart: both are reported as SKB_DROP_REASON_IP_OUTNOROUTES, which
describes a failed route lookup.
Such a route would send the encapsulated packet back into the device
it leaves, which is the dead loop on a virtual device that
SKB_DROP_REASON_RECURSION_LIMIT describes. Report the -ELOOP case with
that reason, and add the tunnel case to the description of the reason
as an example. ip_tunnel and ip6_tunnel make the same check,
rt->dst.dev == dev in ip_tunnel_xmit() and ip_md_tunnel_xmit() and
tdev == dev in ip6_tnl_xmit(), and can report it with the same reason.
Signed-off-by: Anton Danilov <littlesmilingcloud@gmail.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20261005201417.906344-5-littlesmilingcloud@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
__iptunnel_pull_header() returns -ENOMEM whenever it fails. It can
fail in two pskb_may_pull() calls, one for the tunnel header and one
for the inner Ethernet header of ETH_P_TEB, and in the skb_unclone()
done for GSO packets. pskb_may_pull() fails when the packet is shorter
than the requested length as well as when pulling from the frags cannot
allocate, so a truncated packet and an allocation failure look the same
to the callers. The ones that report a drop reason can only pick
SKB_DROP_REASON_NOMEM, as vxlan_rcv() does, and so would the GRE
receive paths once they report drop reasons. In ip6_gre, gre_rcv()
pulls the header before the tunnel lookup, so a packet from any sender
whose ETH_P_TEB inner Ethernet header or WCCPv2 extra word is cut short
would be reported as an out of memory condition.
Make __iptunnel_pull_header() and iptunnel_pull_header() return the
reason pskb_may_pull_reason() already computes, SKB_DROP_REASON_NOMEM
when skb_unclone() fails, and SKB_NOT_DROPPED_YET on success. A failure
is still non-zero, so the callers that only test the result keep
working. Three callers, in ip_gre and ip6_gre, test it with "< 0"
instead; the enum has no negative values, so that test would always be
false, and the compiler does not warn about it. Make them test for a
non-zero value. vxlan_rcv() keeps reporting NOMEM for any failure until
the next patch has it report the returned reason.
Suggested-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Anton Danilov <littlesmilingcloud@gmail.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20261005201417.906344-3-littlesmilingcloud@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
VXLAN_INVALID_HDR and VXLAN_VNI_NOT_FOUND describe conditions that are
not specific to vxlan: a malformed tunnel header, and a packet for
which no tunnel device is found. The GRE receive paths drop packets
for the same two conditions, and can report them with the same reasons
once they are converted to drop reasons.
Rename them to TUNNEL_INVALID_HDR and TUNNEL_NOT_FOUND and reword their
descriptions, the way VXLAN_NO_REMOTE became NO_TX_TARGET in commit
46e0ccfb88f0 ("net: vxlan: rename SKB_DROP_REASON_VXLAN_NO_REMOTE").
The numeric values stay the same; the names that the skb:kfree_skb
tracepoint and drop_monitor report change.
Suggested-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Anton Danilov <littlesmilingcloud@gmail.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20261005201417.906344-2-littlesmilingcloud@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next
Johannes Berg says:
====================
Not too much going on:
- brcmfmac: plenty of improvements
- mac80211: NAN Instant Communications support
- iwlegacy: remove sysfs
- nxpwifi: IW610 support
- couple of fixes for recent regressions
* tag 'wireless-next-2026-10-07' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (50 commits)
wifi: mac80211: use the AP address as RA for a 4-addr MLO station
wifi: mac80211: acquire wiphy lock for unlisted sdata teardown
wifi: mac80211: fix non-MLD link ID handling
wifi: brcmsmac: Adjust txpwrindex value in nphy_ipa_rxcal_gaintbl_2GHz
wifi: iwlegacy: 3945: remove custom sysfs files
wifi: iwlegacy: 4965: remove custom sysfs files
wifi: iwlegacy: set debug level using debugfs
wifi: nxpwifi: bound debug info output
wifi: nxpwifi: bound histogram debugfs output
wifi: nxpwifi: validate variable IE lengths in beacon parser
wifi: nxpwifi: fix missing error codes in _nxpwifi_fw_dpc()
wifi: mac80211_hwsim: add NAN Instant Communication support
wifi: mac80211_hwsim: nan: Handle more of the NAN configuration
wifi: mac80211_hwsim: nan: prepare for more configurable NAN settings
wifi: mac80211_hwsim: nan: use ieee80211_is_nan_beacon() helper
wifi: ieee80211: add NAN service ID list attribute definitions
wifi: mac80211: accept NAN beacons only when IC is enabled
wifi: mac80211: nan: allow Rx registration for NAN beacons
wifi: cfg80211: do not use NAN beacons to update the BSS table
wifi: cfg80211: nan: check Rx registration for NAN beacons
...
====================
Link: https://patch.msgid.link/20261007205827.467974-3-johannes@sipsolutions.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Both __neigh_lookup() and __neigh_lookup_errno() not only
look up but also create a new neighbour entry.
The names were misleading and there was __neigh_lookup(..., 0),
which should have been simply written as neigh_lookup().
Now, __neigh_lookup() has only 1 user left.
Let's convert the last user to neigh_lookup() and neigh_create()
and remove __neigh_lookup() and __neigh_lookup_errno().
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20261003212336.1304988-9-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
syzbot reported the splat below in neigh_mark_dead() [0]
where tbl->lock was not held while neigh_ifdown() should
have acquired one.
This only happens when a neigh_table accidentally has a
neighbour from a different netns.
In ip6_finish_output2(), the net argument is the caller's and
does not always match dev_net(dev) fetched from dst. (e.g. xfrm)
It is error-prone to require callers to fetch netns and
neigh_table and pass it with dev to neigh_lookup(), etc.
Let's replace neigh_lookup() and friends with IPv6 helpers.
Note that __neigh_lookup() is split into ipv6_neigh_lookup()
and ipv6_neigh_create().
[0]:
debug_locks && !(lock_is_held(&(&n->tbl->lock)->dep_map) != 0)
WARNING: net/core/neighbour.c:154 at neigh_mark_dead+0x2fb/0x340 net/core/neighbour.c:154, CPU#0: syz.0.857/9765
Modules linked in:
CPU: 0 UID: 0 PID: 9765 Comm: syz.0.857 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/24/2026
RIP: 0010:neigh_mark_dead+0x2fb/0x340 net/core/neighbour.c:154
Code: e8 03 42 80 3c 28 00 74 08 48 89 df e8 ee 9a 80 f8 4c 89 33 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc e8 86 95 10 f8 90 <0f> 0b 90 e9 8f fd ff ff 48 c7 c1 80 9a 7a 90 80 e1 07 80 c1 03 38
RSP: 0018:ffffc90003726600 EFLAGS: 00010287
RAX: ffffffff89b7467a RBX: ffff888022e86000 RCX: 0000000000080000
RDX: ffffc900047fa000 RSI: 0000000000003e08 RDI: 0000000000003e09
RBP: 0000000000000000 R08: 0000000000000003 R09: 0000000000000004
R10: dffffc0000000000 R11: fffff520006e4cb8 R12: ffff888022e8613c
R13: dffffc0000000000 R14: ffff888022e86020 R15: ffff888022e86000
FS: 00007f9c30f046c0(0000) GS:ffff888124cc6000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 0000000076c56000 CR4: 00000000003526f0
Call Trace:
<TASK>
neigh_flush_one+0x27c/0x5a0 net/core/neighbour.c:388
neigh_flush_dev net/core/neighbour.c:432 [inline]
__neigh_ifdown+0x1fb/0xc70 net/core/neighbour.c:465
neigh_ifdown+0x1f/0x30 net/core/neighbour.c:487
rt6_disable_ip+0x751/0x7e0 net/ipv6/route.c:5058
addrconf_ifdown+0x155/0x1ad0 net/ipv6/addrconf.c:3892
addrconf_notify+0x1bc/0x1050 net/ipv6/addrconf.c:-1
notifier_call_chain+0x1a5/0x3d0 kernel/notifier.c:85
call_netdevice_notifiers_mtu net/core/dev.c:2350 [inline]
netif_set_mtu_ext+0x5ac/0x830 net/core/dev.c:9963
do_setlink+0xa81/0x47a0 net/core/rtnetlink.c:3247
rtnl_setlink+0x578/0x820 net/core/rtnetlink.c:3623
rtnetlink_rcv_msg+0x802/0xc00 net/core/rtnetlink.c:7159
netlink_rcv_skb+0x226/0x4a0 net/netlink/af_netlink.c:2572
netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]
netlink_unicast+0x7bd/0x940 net/netlink/af_netlink.c:1361
netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1916
sock_sendmsg_nosec+0x13a/0x180 net/socket.c:800
__sock_sendmsg net/socket.c:815 [inline]
sock_write_iter+0x2de/0x3e0 net/socket.c:1266
do_iter_readv_writev+0x612/0x8c0 fs/read_write.c:-1
vfs_writev+0x343/0x990 fs/read_write.c:1058
do_writev+0x154/0x2e0 fs/read_write.c:1104
do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f9c2ff9e159
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f9c30f04028 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
RAX: ffffffffffffffda RBX: 00007f9c30225fa0 RCX: 00007f9c2ff9e159
RDX: 0000000000000001 RSI: 00002000000003c0 RDI: 0000000000000004
RBP: 00007f9c3003506b R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f9c30226038 R14: 00007f9c30225fa0 R15: 00007ffed3c74808
</TASK>
Fixes: df5f4f372de5 ("ipv6: Replace &nd_tbl with nd_table(net).")
Reported-by: syzbot+5a8857f0b4a0a7b12c62@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/netdev/6abd69a9.80e1c6cc.22483f.0005.GAE@google.com/
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20261003212336.1304988-7-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
neigh_lookup() accepts struct neigh_table *tbl and struct
net_device *dev, and both of them must exist in the same
netns.
It is error-prone to require callers to fetch a netns and
get neigh_table, which might belong to a different netns
than dev_net(dev).
Let's add IPv6-specific wrappers for neigh_lookup() and
(__)?neigh_create() that always fetch netns from dev.
Similar to IPv4, we do not add wrappers for __neigh_lookup()
since 3 out of 4 users call it with create=1, which should be
simply written as neigh_lookup() and neigh_create().
IPv6 has 3 callers of __neigh_create(want_ref=false), so
ipv6_neigh_create_noref() is also added.
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20261003212336.1304988-5-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
neigh_lookup() accepts struct neigh_table *tbl and struct
net_device *dev, and both of them must exist in the same
netns.
It is error-prone to require callers to fetch a netns and
get neigh_table, which might belong to a different netns
than dev_net(dev).
Let's add IPv4-specific wrappers for neigh_lookup() and
neigh_create() that always fetch netns from dev.
Note that we do not add wrappers for __neigh_lookup() and
__neigh_lookup_errno(), which we will remove later.
__neigh_lookup_errno() is a simple combo of neigh_lookup()
and neigh_create(). __neigh_lookup() is almost the same
but converts errno from neigh_create() to NULL.
So both names are confusing.
For IPv4, __neigh_lookup_errno() is only used in arp_req_set()
and is not worth a new wrapper. Instead, it should be inlined.
arp_process() uses __neigh_lookup(create=0) but it should
simply be neigh_lookup(), and then __neigh_lookup(create=1)
is only used in arp_process(), so this should be inlined too.
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20261003212336.1304988-4-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Later, we will add ipv6_neigh_lookup() as a wrapper for
neigh_lookup(nd_table(net), ...).
The existing ip6_neigh_lookup() is called from ip6_dst_neigh_lookup()
with a gateway address.
Let's rename ip6_neigh_lookup() to __ip6_dst_neigh_lookup().
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20261003212336.1304988-3-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Fix a potential build error (like below, when asm/kvm_emulate.h gets
included after the kvm/arm_psci.h) by including the missing header file
in kvm/arm_psci.h:
./include/kvm/arm_psci.h: In function ‘kvm_psci_version’:
./include/kvm/arm_psci.h:29:13: error: implicit declaration of function
‘vcpu_has_feature’; did you mean ‘cpu_have_feature’? [-Werror=implicit-function-declaration]
29 | if (vcpu_has_feature(vcpu, KVM_ARM_VCPU_PSCI_0_2)) {
| ^~~~~~~~~~~~~~~~
| cpu_have_feature
Reviewed-by: Gavin Shan <gshan@redhat.com>
Reviewed-by: Fuad Tabba <fuad.tabba@linux.dev>
Reviewed-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
Tested-by: Gavin Shan <gshan@redhat.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://patch.msgid.link/20261007073537.2454351-4-suzuki.poulose@arm.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
controller
Add DT bindings for the MT6735 pin controller.
Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
|
Add a DAI for the SDCA OT25 stream on SoundWire DP4.
The SDCA-defined OT25 stream is an amp reference feedback, typically used
for AEC. The firmware outputs this on DP4. The firmware owns all control
registers for this stream so there are no mixer controls or any other
configuration options.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20261005155235.1386525-2-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Peter Ujfalusi <peter.ujfalusi@linux.intel.com> says:
This series adds compressed audio support for SOF with IPC4 firmware.
Supported formats are PCM, MP3, AAC and VORBIS, the feature set is
PAUSE_PUSH/RELEASE, DRAIN and position reporting.
Patches 1-5 are prerequisites in the ALSA compress core and in
soc-compress.c.
These are core fixes rather than driver level workarounds on purpose.
The other users of compressed DPCM have DSP internal ports on their
BEs, driven by code they own. An Intel/SOF BE ends at a third party
CODEC driver which is shared with the non DPCM case and has no reason
to know that the FE is compressed. That set of CODECs is open ended,
so teaching each of them to cope with a compressed FE does not scale.
The core has to hand a BE the same substream state whether the FE is
a PCM or a compressed one.
Two of these patches change behaviour for the existing users of
compressed DPCM, so they would need a look from Qualcomm and NXP:
- "ASoC: soc-compress: Implement trigger FE-BE sequencing as with
normal PCMs" makes the FE/BE trigger order follow
dai_link->trigger[], the way dpcm_fe_dai_do_trigger() does it.
Neither sound/soc/qcom/ nor sound/soc/fsl/ sets it, so both default
to SND_SOC_DPCM_TRIGGER_PRE: START keeps the current order, but
STOP, SUSPEND and PAUSE_PUSH now trigger the BE before the FE.
- "ASoC: soc-compress: Stop running dpcm on free" sends a STOP trigger
from soc_compr_free_fe() if the DPCM is still in START state, which
is the case when the last trigger the stream received was a DRAIN.
Patches 6-20 implement the IPC4 compressed support, patch 21 is a
Kconfig cleanup. The last two patches enable the feature, in Kconfig
for TGL and later and in the topology parser, so the compressed device
type only becomes usable once the code behind it is in place.
Testing:
- IPC4: Arrow Lake, compressed playback on speaker and headphone
(cs42l43), MP3, AAC and VORBIS.
- IPC3: tested by NXP. This does not cover the STOP on free path
above, as they do not implement DRAIN.
Link: https://patch.msgid.link/20261007084955.1256-1-peter.ujfalusi@linux.intel.com
|
|
The decoder module sends a drain done notification when the last chunk of
the stream after the EOS from host has been decoded.
The notification is a module notification with 0xc0c0 as magic number in
event_id upper 16 bit.
Call sof_ipc4_compr_drain_done() when the notification arrives to handle
it.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Link: https://patch.msgid.link/20261007084955.1256-26-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
SOF_INFO (id == 35) tuple holds tuple structured information about SOF
features.
The first entry in SOF_INFO is the SOF_CODEC_INFO (id == 0) which contains
information about the supported codecs for decode/encode in the booted
firmware.
If present in the fw_config payload, make a copy of it and store it
sof_ipc4_fw_data->codec_info to be used by the compressed code.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Link: https://patch.msgid.link/20261007084955.1256-20-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The object array of the MODULE_INIT message can carry different types of
objects, identified by SOF_IPC4_MOD_INIT_EXT_OBJ_ID in the object header.
Add the SOF_IPC4_MOD_INIT_DATA_ID_MODULE_DATA type to pass module specific
initialization data to a module. Unlike the existing DP_DATA object, its
content is opaque to the driver and its size is variable, defined by the
module itself. It is going to be used to configure the decoder and encoder
process modules.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Link: https://patch.msgid.link/20261007084955.1256-17-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Track open compressed streams per device so disconnect can stop
active streams and wake waiters before snd_unregister_device().
This aligns compressed stream teardown with PCM disconnect behavior
and prevents active userspace streams from running into unregister
races.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20261007084955.1256-4-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Ricardo Rivera-Matos <rriveram@opensource.cirrus.com> says:
The CS35L45 has an input signal level dependent power
management (LDPM) feature. The feature is used to reduce
power consumption when the amplifier is playing sustained
low amplitude audio. This feature is made up of two
responding groups each with a distinct threshold level and
entry time delay.
Group 1 can issue a low power request to either or both the
integrated boost converter and amplifier output stage
functional blocks.
Group 2 can issue a low power request to either or both the
VMON and IMON functional blocks.
This patch series introduces support for this feature as
devicetree properties applied at boot time.
Link: https://patch.msgid.link/20261001-cs35l45-ldpm-v1-0-545787a5afe5@opensource.cirrus.com
|
|
Introduce devicetree properties for configuring level
dependent power management (LDPM) functionality.
Signed-off-by: Ricardo Rivera-Matos <rriveram@opensource.cirrus.com>
Link: https://patch.msgid.link/20261001-cs35l45-ldpm-v1-1-545787a5afe5@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
When the hardware won't apply a timer's offset, KVM programs CVAL +
offset and lets it compare that against the raw counter. The compare is
unsigned (IsTimerConditionMet, DDI0487M_c J1.4.3.29):
condition_met = (UInt(PhysicalCountInt() - offset) -
UInt(compare_value)) >= 0;
so adding the offset to both sides holds only while both sums wrap or
neither does. A guest whose counter is ahead of the host's by more than
CVAL has an expired timer that never fires, and one behind it can have
a far-future timer fire at once.
On a CNTPOFF_EL2 host the first case livelocks: each entry reloads the
guest's CVAL, the timer fires, and the exit rewrites it as CVAL + offset
before the host can take the interrupt. Without CNTPOFF_EL2 the timer
hangs until the vCPU is next loaded, which is what Zenghui reported on
a Kunpeng920.
Program the value from the current count instead: CVAL + offset while
the deadline is ahead, 0 once the timer has expired for the guest, ~0
past the counter's wrap. KVM recomputes it at load, at exit and on a
trapped CVAL write, and an expired timer stays expired in between. The
value can't be inverted, so with an offset timer_save_state() keeps the
memory copy, and kvm_hyp_handle_timer() returns that copy for a guest
hypervisor's read of its physical CVAL rather than subtracting the
offset back out.
Fixes: c605ee245097 ("KVM: arm64: timers: Allow physical offset without CNTPOFF_EL2")
Fixes: 9404673293b0 ("KVM: arm64: timers: Correctly handle TGE flip with CNTPOFF_EL2")
Fixes: 0bc9a9e85fcf ("KVM: arm64: Work around x1e's CNTVOFF_EL2 bogosity")
Reported-by: Zenghui Yu <yuzenghui@huawei.com>
Closes: https://lore.kernel.org/r/460258be-0102-e922-c342-4e87cd94b9e5@huawei.com
Cc: stable@vger.kernel.org
Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
Link: https://patch.msgid.link/20261007074343.324269-2-fuad.tabba@linux.dev
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
Neither the VCPU_RUN in kvm_main.c nor the VCPU RUN in kvm_host.h names
an ioctl that exists. The one that enters the guest is KVM_RUN, so refer
to it by that name.
Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
Link: https://patch.msgid.link/20260915084441.3846947-2-fuad.tabba@linux.dev
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
snd_hdac_power_down() and snd_hdac_power_down_pm() are defined to return
an int, but their return values are never used by any caller.
snd_hdac_power_down() also passes the return value of
pm_runtime_put_autosuspend() to the caller, which is not very useful.
Returning an error code from pm_runtime_put_autosuspend() merely means
that it has not queued up a timer or work item to check whether or not
the device can be suspended and there are many perfectly valid
situations in which that can happen, like after writing "on" to the
device's runtime PM "control" attribute in sysfs for one example.
Modify snd_hdac_power_down() to discard the pm_runtime_put_autosuspend()
return value and change the return types of snd_hdac_power_down() and
snd_hdac_power_down_pm() to void.
No intentional functional impact.
This will facilitate a planned change of the
pm_runtime_put_autosuspend() return type to void in the future, similar
to commit 3afd8df02433 ("PM: runtime: Change pm_runtime_put() return
type to void").
Signed-off-by: Brian Norris <briannorris@chromium.org>
Link: https://patch.msgid.link/20261006161337.8.Idcada3ae757100bf3a38f7e71bac37f827be06c6@changeid
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Patch series "Introduce arch_do_panic", v6.
Replace architecture-specific ifdef sections in vpanic() with a clean
arch_do_panic() hook. Currently s390 and sparc embed their panic handlers
directly in vpanic() using preprocessor conditionals, making the common
code path harder to maintain.
Introduce arch_do_panic() as an architecture extension point called at the
end of vpanic(). Architectures can use this hook to implement their
specific panic handling without polluting the generic panic code.
Remove s390s ifdef block in vpanic() and move the corresponding code block
to s390s own arch_do_panic() implementation in architecture specific code.
Move sparc panic handling from ifdef blocks to arch_do_panic(). Remove
the preprocessor conditionals from vpanic() and place the Stop-A
enablement code in architecture-specific files where it belongs. Stop-A
enablement markers are now printed after "end Kernel panic" line. To me,
there are no better alternatives other than setup.c to put sparc's
arch_do_panic() implementation. The other files under arch/sparc/kernel
are either divided to *_32.c and *_64.c variants, which mean code
duplication, or unrelated.
The cleanup reduces vpanic() complexity and establishes a pattern for
other architectures needing custom panic behavior. No functional changes,
only minor print order changes.
This patch (of 3):
Introduce a hook for architectures to put their specific panic handlers.
s390 and sparc already have ifdef preprocessor checks to execute
architecture specific code. Pave the way for vpanic() cleanup.
Link: https://lore.kernel.org/20260831-arch_do_panic-v6-1-a1e170a9e7fd@linux.ibm.com
Link: https://lore.kernel.org/all/20260730-arch_do_panic-v3-0-d5401e683cdb@linux.ibm.com/ [1]
Signed-off-by: Mete Durlu <meted@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Bradley Morgan <include@grrlz.net>
Suggested-by: Sven Schnelle <svens@linux.ibm.com>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Andreas Larsson <andreas@gaisler.com>
Cc: Christian Borntraeger <borntraeger@linux.ibm.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
|
|
Commit b280bb27a9f7 ("minmax.h: reduce the #define expansion of min(),
max() and clamp()") made __sign_use(), __is_nonneg() and __types_ok() take
only 'ux', and commit a5743f32baec ("minmax.h: use BUILD_BUG_ON_MSG() for
the lo < hi test in clamp()") did the same for the clamp() limit test.
The comment describing the old split was added one patch earlier and was
never updated.
'ux' now carries the value check too, since __is_nonneg() tests it rather
than the original expression, and nothing here looks at the value of 'x'
any more: it is expanded only to initialise 'ux' and in the error message,
as the first of those changes intended.
Link: https://lore.kernel.org/20260817121613.3846511-1-zhanxusheng@xiaomi.com
Signed-off-by: Zhan Xusheng <zhanxusheng@xiaomi.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: David Laight <david.laight.linux@gmail.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
|
|
fault_create_debugfs_attr() has always taken an extra dentry reference on
the created directory (attr->dname = dget(dir)) so that fail_dump() could
print the name via %pd from any context. Nothing anywhere in the tree
ever calls dput() on attr->dname.
For callers with a matching teardown, that unmatched reference causes one
dentry plus its attached inode to leak per fault_create_debugfs_attr /
debugfs_remove_recursive cycle. simple_recursive_removal() drops
debugfs's own +1 ref on the child dentry, but the dget()'d ref keeps its
refcount at 1: the dentry ends up unhashed but pinned, and its inode is
never freed.
Boot-once callers (mm/failslab, block/blk-core, etc.) leak exactly once at
init and never destroy the tree, so the impact there is bounded. But
per-lifecycle callers (drivers/nvme, drivers/infiniband/hw/hfi1,
drivers/mmc, drivers/iommu/iommufd, drivers/media, drivers/misc,
drivers/gpu/drm/msm, drivers/crypto, net/sunrpc) leak on every
create/destroy cycle.
We observed this in production: an NVMe/RDMA host repeatedly reconnecting
to a target that rejected the CRTO Property Get went through ~50 nvme
controller create/destroy cycles per second, and dentry and inode_cache
grew by ~13k pinned objects per 240 s -- unrecoverable through
drop_caches. Byte math matched a per-cycle 1-dentry / 1-inode leak from
the "fault_inject" directory dentry.
Fix this by not holding any external reference in fault_attr. Embed the
directory name as a fixed-size char array (FAULT_ATTR_DNAME_LEN, 64 bytes)
inside struct fault_attr, copied by strscpy() at
fault_create_debugfs_attr() time. fail_dump() prints it via %s.
Advantages of an embedded array over kstrdup() + kfree() paired with a new
destroy API:
- Zero API footprint. No new export and no caller changes required:
callers already own their fault_attr's memory and free it when
they are done, and now that suffices.
- No allocation on the create path.
- fault_create_debugfs_attr() cannot fail from the name-copy step.
- No lifetime coupling between attr->dname and debugfs; the string
is valid for exactly as long as the containing struct.
The 64-byte length accommodates every in-tree caller with generous
headroom (the longest current name is "fail_dma_array_full", 19 chars).
The user-visible fail_dump() format changes from "name %pd" to "name %s",
but the printed content is identical -- %pd on the created directory
renders the same string that was passed in as @name.
drivers/infiniband/hw/hfi1/fault.c drops a now-invalid "attr.dname = NULL"
statement; the surrounding kzalloc() already zero-initialises the array.
Link: https://lore.kernel.org/20260821181527.3271414-1-mliang@purestorage.com
Fixes: 6adc4a22f20b ("fault-inject: add ratelimit option")
Signed-off-by: Michael Liang <mliang@purestorage.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Akinbou Mita <akinobu.mita@gmail.com>
Cc: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Leon Romanovsky <leon@kernel.org>
Cc: Vlastimil Babka <vbabka@kernel.org>
Cc: <stable@vger.kernel.org>
|
|
Since commit 083e64a3af77 ("net: devmem: replace gen_pool with
freelist"), a binding has a single net_iov_area covering the whole
dma-buf, and base_virtual is always 0. Its only reader is
net_iov_virtual_addr(), where it adds nothing. io_uring zcrx never
uses it.
Drop the field and the store, and compute the dma-buf offset from the
net_iov index alone.
No functional change. From review feedback on:
https://lore.kernel.org/netdev/asPUZ8DPllHd6Yu9@devvm7509.cco0.facebook.com/
Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
Acked-by: Mina Almasry <almasrymina@google.com>
Link: https://patch.msgid.link/20261005201822.3060658-1-sdf@fomichev.me
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux
Tariq Toukan says:
====================
mlx5: Move data direct infrastructure to mlx5_core
Data direct support currently lives in mlx5_ib, which owns the data
direct PCI driver, device matching and resource management. To prepare
for data direct support in netdev, move this infrastructure to mlx5_core
and provide a common interface for its consumers.
The series first replaces the direct IB unbind callback with a blocking
notifier chain, allowing multiple consumers to receive unbind events.
It then separates consumer registration from initialization, consolidates
the per-device state and resources, and keeps IB-specific locking and MR
teardown in mlx5_ib.
With these preparations in place, the final patch moves the shared
implementation and PCI driver to mlx5_core. Data direct initialization
and resource creation run during core load, before consumers attach;
cleanup runs during core unload, after consumers detach.
The data direct PCI driver is also explicitly named "mlx5_dd", replacing
the previous "mlx5_ib" name derived from KBUILD_MODNAME.
This series prepares the shared infrastructure for netdev support.
The netdev consumer will follow in a separate series.
* 'mlx5-next' of git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux:
mlx5: Move data direct implementation to mlx5_core
RDMA/mlx5: Pull data_direct resource creation in init phase
RDMA/mlx5: Consolidate data direct state into one object
RDMA/mlx5: Extract IB specific lock out of data direct
RDMA/mlx5: Add new registration stage for data direct users
RDMA/mlx5: Move and rename data direct resource functions
RDMA/mlx5: Give the data direct PCI driver a proper name
RDMA/mlx5: Make the data direct VUID query self-contained
RDMA/mlx5: Add mlx5_data_direct_supported() helper
RDMA/mlx5: Notify data direct users via a notifier chain on unbind
====================
Link: https://patch.msgid.link/20261004064921.213888-1-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The comment above strp_done() claims that if strp is stopped,
strp_recv will no longer be called. That's only true if the caller has
a mechanism (eg locking) to guarantee that strp_recv() calls that
started before strp_stop() have completed by the time we call
strp_done().
This adds a dummy lock_sock/release_sock pair to guarantee that any
in-flight strp_recv() (which runs under either bh_lock_sock or
lock_sock, depending if it's called from ->sk_data_ready or strp_work)
has completed.
Only espintcp can be affected by this race condition, but this patch
makes sure no future user of strp can have the bug.
This could crash on strp->sk ("general mode" of strp), but this mode
has been here for 9 years and has never been used. It'll be gone soon,
no point worrying about it.
Switch the stopped/paused/etc bits to u8's to avoid races between
strp_stop() and strp_pause/unpause().
A reproducer has been published and turns the possible UAF into an
exploit [1].
Reported-by: Hyunwoo Kim <imv4bel@gmail.com>
Link: https://lore.kernel.org/all/aZLn2Faeg1FB7XOf@v4bel/
Link: https://lore.kernel.org/all/aZgpkyTDU3aXe_V0@v4bel/
Link: https://github.com/m0x41nos/RustyTux [1]
Fixes: e27cca96cd68 ("xfrm: add espintcp (RFC 8229)")
Cc: stable@vger.kernel.org
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Reviewed-by: Hyunwoo Kim <imv4bel@gmail.com>
Link: https://patch.msgid.link/425d9d926709b542ed5331110c19fee4aee1f28d.1791206940.git.sd@queasysnail.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can
Marc Kleine-Budde says:
====================
pull-request: can 2026-10-01
The first patch is by zjamg and restores the skb header initialization
lost during the v7.0 release cycle.
Oliver Hartkopp contributes a patch for the CAN net layer to fix the
unique skb identifier regression under RPS, introduced in the v7.0
release cycle, which causes lost packets.
The last patch is by Ji-Ze Hong and fixes a struct size mismatch in
the f81604 CAN driver, which results in a TX starvation.
* tag 'linux-can-fixes-for-7.3-20261001' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can:
usb: f81604: fix struct f81604_int_data size mismatch
can: fix unique skb identifier regression under RPS
can: dev: init_can_skb(): restore skb header initialization
====================
Link: https://patch.msgid.link/20261001151905.1556270-1-mkl@pengutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
PF_KCOMPACTD was introduced by commit ce6d9c1c2b5c ("NFS: fix
nfs_release_folio() to not deadlock via kcompactd writeback") so
nfs_release_folio() could detect kcompactd context and skip writeback.
The flag is only consumed by current_is_kcompactd(), whose sole caller is
nfs_release_folio().
Replace the flag-based check with kthread_func(current) == kcompactd,
freeing the 0x00010000 PF flag bit.
Link: https://lore.kernel.org/20260902131653.1338227-5-wangkefeng.wang@huawei.com
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Shakeel Butt <shakeel.butt@linux.dev>
Acked-by: Zi Yan <ziy@nvidia.com>
Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
Reviewed-by: David Hildenbrand (Arm) <david@kernel.org>
Cc: Brendan Jackman <brendan.jackman@linux.dev>
Cc: Carlos Maiolino <cem@kernel.org>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>
Cc: "Darrick J. Wong" <djwong@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Suren Baghdasaryan <surenb@google.com>
|
|
The preceding commits removed the last consumer that propagated PF_KSWAPD
beyond kswapd itself (XFS btree split worker inheritance). The only
remaining setter of PF_KSWAPD is kswapd(), and every current_is_kswapd()
caller only needs to check whether the current task *is* the kswapd
thread, not whether it inherited the flag.
Replace the flag-based test with kthread_func(current) == kswapd,
freeing the 0x00020000 PF flag bit.
Link: https://lore.kernel.org/20260902131653.1338227-4-wangkefeng.wang@huawei.com
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Shakeel Butt <shakeel.butt@linux.dev>
Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
Acked-by: Zi Yan <ziy@nvidia.com>
Cc: Brendan Jackman <brendan.jackman@linux.dev>
Cc: Carlos Maiolino <cem@kernel.org>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>
Cc: "Darrick J. Wong" <djwong@kernel.org>
Cc: David Hildenbrand <david@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Suren Baghdasaryan <surenb@google.com>
|
|
totalram_pages_inc() and totalram_pages_dec() have had no callers since
commit 7fbc5e26123e ("memblock: extract page freeing from
free_reserved_area() into a helper") and commit 287b89773d81
("powerpc/pseries/cmm: Use adjust_managed_page_count() insted of
totalram_pages_*"), respectively. Remove them.
Drop the totalram_pages_inc() stub from tools mm.h too.
Link: https://lore.kernel.org/20260901-mm-remove-unused-helpers-v2-2-f6474e169c23@columbia.edu
Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Signed-off-by: Tal Zussman <tz2294@columbia.edu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Vlastimil Babka <vbabka@kernel.org>
|
|
Patch series "mm: remove three unused helpers from mm.h", v2.
I happened to notice these were unused. Two of them are relatively
recently unused, and one has been unused for a few years. Remove them.
This patch (of 2):
mark_page_reserved() lost its last caller in commit 6215d9f4470f ("arch,
mm: consolidate empty_zero_page"). Remove it.
Link: https://lore.kernel.org/20260901-mm-remove-unused-helpers-v2-0-f6474e169c23@columbia.edu
Link: https://lore.kernel.org/20260901-mm-remove-unused-helpers-v2-1-f6474e169c23@columbia.edu
Signed-off-by: Tal Zussman <tz2294@columbia.edu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Vlastimil Babka <vbabka@kernel.org>
|
|
damon_prep needs to be executed by the underlying DAMON operation set.
Extend the operation set callback list for the execution of damon_prep
actions. If the underlying operation set implements the callback, DAMON
core executes it in the monitoring preparation time.
Link: https://lore.kernel.org/20260901132506.99243-8-sj@kernel.org
Signed-off-by: SJ Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: David Hildenbrand <david@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
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: Randy Dunlap <rdunlap@infradead.org>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Vlastimil Babka <vbabka@kernel.org>
|
|
Some DAMON probe filter types require preparatory actions. For example,
pgilde_unset probe filter can say if the page was accessed but when. To
answer the second question, the PG_Idle flag should be set at a specific
time. It can make life much easier if DAMON can do such preparatory
actions. Introduce a new data type called damon_prep. It specifies each
of the preparation actions for each probe. DAMON will execute the action
for each region per sampling interval, like it clears page table accessed
bits and unsets PG_Idle flag for access monitoring.
Also introduce DAMON_PREP_SET_PGIDLE as the initial prep action. As the
name says, it will do exactly what DAMON was doing as the preparation
action for the access monitoring.
Link: https://lore.kernel.org/20260901132506.99243-6-sj@kernel.org
Signed-off-by: SJ Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: David Hildenbrand <david@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
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: Randy Dunlap <rdunlap@infradead.org>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Vlastimil Babka <vbabka@kernel.org>
|
|
Patch series "mm/damon: introduce data access-as-a-data attribute", v1.1.
TL;DR: extend DAMON's data attributes monitoring system to support page
table accessed bit and PG_idle based access monitoring.
DAMON was initially introduced as a data access monitor. Users found data
access pattern becomes more useful when it is combined with other data
attributes such as belonging cgroups and backing page types. For such
cases, DAMON has extended to support such data attributes monitoring in
addition to the original data access monitoring. The DAMON probes system
was introduced for this purpose. Users set probes for filtering data
attributes of their interest. For use cases where the primary interests
are the attributes but the access pattern, probe weights system has been
introduced. When it is used, DAMON applies its adaptive regions
adjustment based on the monitored data attributes.
However, DAMON stops access monitoring when the probe weights are used.
DAMON cannot optimally help users who have interests in both data
attributes and access patterns. Data access can also be thought of as
another data attribute, though. Extend the probe system to support data
access as a data attribute.
Introduce a new probe filter type, pgidle_unset. It shows if the page is
not set as idle. Specifically, it shows the page table accessed bit and
the PG_idle flag. It can inform if the region is ever accessed. But it
cannot say when it is accessed. To answer the second question, introduce
a new probe feature, prep actions. Using the features, Users can specify
what preparation actions should be made to each region for each probe.
DAMON executes the preparation actions for each sampling interval, like it
is doing the preparation for access check in the access monitoring mode.
To help 'pgidle_unset' probe action use case, 'set_pgidle' preparation
action is introduced together. The action does exactly what the access
monitoring was doing: clearing the page table accessed bits and setting
the PG_idle flags.
Tests
=====
I compared the access pattern monitoring results from the classic way and
the probe based way. As expected, the probe based way shows the results
similar to that of the classic way. More detailed test methods and
results are below.
First, do the access monitoring using the DAMON user-space tool [1] in the
classic way. The system is idle. It shows no access as expected.
$ sudo ./damo/damo start
$ sudo ./damo/damo report access
heatmap:
00000000000000000000000000000000000000008999999811111110000000000000000000000000
# min/max temperatures: -640,000,000, -100,000,000, column size: 99.800
MiB
intervals: sample 5 ms aggr 100 ms (max access hz 200)
0 addr 4.000 KiB size 3.898 GiB access 0 hz age 6.400 s
1 addr 3.898 GiB size 787.301 MiB access 0 hz age 1 s
2 addr 4.667 GiB size 773.457 MiB access 0 hz age 5.800 s
3 addr 5.423 GiB size 2.374 GiB access 0 hz age 6.400 s
memory bw estimate: 0 B per second
total size: 7.797 GiB
record DAMON intervals: sample 5 ms, aggr 100 ms
Start an artificial memory access generator (masim) [2] in another window.
$ ./masim/masim.py run --config_file ./masim/configs/zigzag.cfg
Show the monitoring results. As expected, it captures accesses.
$ sudo ./damo/damo report access
heatmap:
00000000000000000000000000000000000000011111111111111118888888833378988888888888
# min/max temperatures: -1,470,000,000, -12,482,536, column size: 99.800
MiB
intervals: sample 5 ms aggr 100 ms (max access hz 200)
0 addr 4.000 KiB size 1.542 GiB access 0 hz age 14.700 s
1 addr 1.542 GiB size 788.324 MiB access 0 hz age 14.600 s
2 addr 2.311 GiB size 772.844 MiB access 0 hz age 14.200 s
[...]
50 addr 6.839 GiB size 1.742 MiB access 0 hz age 1.300 s
51 addr 6.840 GiB size 8.000 KiB access 100 hz age 0 ns
52 addr 6.840 GiB size 1.496 MiB access 160 hz age 0 ns
[...]
97 addr 7.162 GiB size 1.199 MiB access 40 hz age 400 ms
98 addr 7.163 GiB size 1.199 MiB access 20 hz age 400 ms
99 addr 7.164 GiB size 2.004 MiB access 160 hz age 0 ns
100 addr 7.166 GiB size 646.004 MiB access 0 hz age 400 ms
memory bw estimate: 26.148 GiB per second
total size: 7.797 GiB
record DAMON intervals: sample 5 ms, aggr 100 ms
After the artificial memory access generator (masim) is terminated,
restart DAMON with the probe-based access monitoring. As expected, it
shows no access since the system is idle again.
$ sudo ./damo/damo stop
$ sudo ./damo/damo start --probe_prep set_pgidle \
--probe_filter allow pgidle_unset --probe_weight 1
$ sudo ./damo/damo report attrs
heatmap:
00000000000000000000000000000000000000008999999711111100000000000000000000000000
# min/max temperatures: -600,000,000, -430,000,000, column size: 99.800
MiB
probe prep: set_pgidle, filter: allow pgidle_unset (weight: 1)
intervals: sample 5 ms aggr 100 ms (max probe hits 20)
# addr size age probe_hits
0 4.000 KiB 3.898 GiB 6 s 0
1 5.285 GiB 2.512 GiB 6 s 0
2 4.659 GiB 641.816 MiB 5.700 s 0
3 3.898 GiB 778.375 MiB 4.300 s 0
memory bw estimate: 0 B per second
total size: 7.797 GiB
record DAMON intervals: sample 5 ms, aggr 100 ms
Start the artificial memory access generator [2] again.
$ ./masim/masim.py run --config_file ./masim/configs/zigzag.cfg
Show the monitoring results. As expected, it captures accesses similar to
the classic monitoring mode.
$ sudo ./damo/damo report attrs
heatmap:
00000000000000000000000000000000000000011111110000000177777777777777878798887777
# min/max temperatures: -1,330,000,000, 84,847,514, column size: 99.800
MiB
probe prep: set_pgidle, filter: allow pgidle_unset (weight: 1)
intervals: sample 5 ms aggr 100 ms (max probe hits 20)
# addr size age probe_hits
0 4.000 KiB 1.508 GiB 13.300 s 0
1 1.508 GiB 794.684 MiB 13.200 s 0
2 2.284 GiB 764.555 MiB 13 s 0
[...]
50 6.711 GiB 4.625 MiB 0 ns 17
51 6.716 GiB 2.504 MiB 0 ns 17
52 6.732 GiB 796.000 KiB 0 ns 17
[...]
90 7.162 GiB 512.000 KiB 2.200 s 2
91 7.061 GiB 700.000 KiB 2.300 s 1
92 6.935 GiB 316.000 KiB 2.300 s 4
memory bw estimate: 0 B per second
total size: 7.797 GiB
record DAMON intervals: sample 5 ms, aggr 100 ms
Patches Sequence
================
First four patches (patches 1-4) introduce the new probe filter type for
knowing if a region is accessed. Patch 1 defines the new type in the
core. Patch 2 implements the execution of the new filter in the physical
address space DAMON operation set. Patch 3 implements a user interface on
DAMON sysfs interface. Patch 4 updates the documentation for the new
filter type.
Following 13 patches (patches 5-17) introduce the probe preparation
actions feature. Patch 5 defines the data structure for specifying the
preparation actions. Patch 6 completes setup of the API parameter for the
prep. Patch 7 extends the DAMON operation set callback list to connect
the parameter with the underlying operation set. Patch 8 implements the
execution of the prep in the physical address space DAMON operation set.
Following five patches (patches 9-13) extends DAMON sysfs interface for
the new prep feature. Patch 14 adds simple selftest for basic file
operations of the new sysfs files. Final three patches (patches 15-17)
respectively update design, usage and ABI documents for the new feature
and its interface.
This patch (of 17):
Introduce a new DAMON filter type, pgidle_unset. It will match pages that
have their PG_Idle flag unset, or the page table accessed bit set. In
other words, it says if the page is accessed.
Link: https://lore.kernel.org/20260901132506.99243-1-sj@kernel.org
Link: https://lore.kernel.org/20260901132506.99243-2-sj@kernel.org
Link: https://github.com/damonitor/damo [1]
Link: https://github.com/sjp38/masim [2]
Signed-off-by: SJ Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: David Hildenbrand <david@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
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: Randy Dunlap <rdunlap@infradead.org>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Vlastimil Babka <vbabka@kernel.org>
|
|
folio_alloc_swap() reports most failures with generic negative error
codes. Reclaim callers consequently cannot tell whether splitting a large
folio could make progress, or whether no swap space is available for even
a single page.
Classify failures using both the global free swap count and the remaining
capacity in the folio's memcg swap hierarchy. Return -ENOSPC when global
swap space is exhausted, -ENOMEM when splitting cannot overcome the
failure, and -E2BIG for a large folio when allocating or charging a
smaller folio might still succeed.
Use this classification for all folio_alloc_swap() failure paths,
including capability rejection, swap slot allocation failure, and memcg
swap charge failure. Callers are updated separately to split large folios
only on -E2BIG.
Link: https://lore.kernel.org/20260830042920.2280454-3-xueyuan.chen21@gmail.com
Signed-off-by: Xueyuan Chen <xueyuan.chen21@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Suggested-by: Kairui Song <ryncsn@gmail.com>
Suggested-by: Barry Song <baohua@kernel.org>
Suggested-by: Youngjun Park <youngjun.park@lge.com>
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
Cc: Baolin Wang <baolin.wang@linux.alibaba.com>
Cc: Baoquan He <baoquan.he@linux.dev>
Cc: Chris Li <chrisl@kernel.org>
Cc: Hugh Dickins <hughd@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Kemeng Shi <shikemeng@huaweicloud.com>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Nanzhe Zhao <zhaonanzhe@xiaomi.com>
Cc: Nhat Pham <nphamcs@gmail.com>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
Cc: Shakeel Butt <shakeel.butt@linux.dev>
|
|
Patch series "mm: avoid large folio splits when swap is unavailable", v7.
This is v7 of Barry's original RFC patch, "mm: Avoiding split large folios
if swap has no space":
https://lore.kernel.org/r/20260618221720.71768-1-baohua@kernel.org
Barry's RFC showed the no-swap case with MADV_PAGEOUT on 16KB mTHP: the
large-folio split counter increased by 1024 even though no swapout
progress was possible. Skipping the split in that case kept the counter
at 0.
This series makes folio_alloc_swap() classify failures according to
whether splitting a large folio might allow swapout to make progress.
Callers can then avoid destroying the large folio when neither global swap
availability nor the folio's memcg swap hierarchy has capacity for even a
smaller folio.
Patch #1 adds page_counter_margin(), a small helper that computes the
minimum remaining chargeable space across a page_counter hierarchy.
Patch #2 establishes the folio_alloc_swap() return-value contract:
- -E2BIG: splitting may let smaller folios make progress
- -ENOSPC: no global swap space is available
- -ENOMEM: splitting is not expected to help, including when the
folio's memcg swap hierarchy has no remaining capacity
Patch #3 makes vmscan split a large folio only when folio_alloc_swap()
returns -E2BIG. Other failures keep the existing activation path and
avoid destroying the large folio when no smaller part can be backed by
swap either.
Patch #4 applies the same contract to shmem_writeout(), which currently
splits a large folio on every folio_alloc_swap() failure. It now enters
the split fallback only on -E2BIG; other failures redirty and reactivate
the folio as before.
Testing:
With a 1GB anonymous mapping backed by 16KB mTHPs and memory.swap.max=0,
the patch reduced the median latency of 30 process_madvise(MADV_PAGEOUT)
runs from 743.8 ms to 181.7 ms, while the number of large-folio splits per
run dropped from 65536 to 0. Neither kernel swapped out any pages.
I also ran DaCapo h2 under swap pressure and found no statistically
significant change in wall time or CPU time. The overall benefit appears
minor and workload-dependent.
This patch (of 4):
mem_cgroup_get_nr_swap_pages() open-codes the remaining capacity across
the memcg swap counter hierarchy.
Add page_counter_margin() to return the minimum usable space from a page
counter to the root, and use it in mem_cgroup_get_nr_swap_pages(). This
is a pure refactoring with no intended behavior change.
Link: https://lore.kernel.org/20260830042920.2280454-1-xueyuan.chen21@gmail.com
Link: https://lore.kernel.org/20260830042920.2280454-2-xueyuan.chen21@gmail.com
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Xueyuan Chen <xueyuan.chen21@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: David Hildenbrand (Arm) <david@kernel.org>
Reviewed-by: Barry Song <baohua@kernel.org>
Cc: Baolin Wang <baolin.wang@linux.alibaba.com>
Cc: Baoquan He <baoquan.he@linux.dev>
Cc: Chris Li <chrisl@kernel.org>
Cc: Hugh Dickins <hughd@google.com>
Cc: Kairui Song <ryncsn@gmail.com>
Cc: Kemeng Shi <shikemeng@huaweicloud.com>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Nhat Pham <nphamcs@gmail.com>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
Cc: Shakeel Butt <shakeel.butt@linux.dev>
Cc: Nanzhe Zhao <zhaonanzhe@xiaomi.com>
Cc: Youngjun Park <youngjun.park@lge.com>
|
|
There are no more users left for any pxd_ERROR() either in generic MM or
in the platform MM. Hence all these platform macros along with their
generic fallback could be dropped across the tree.
Link: https://lore.kernel.org/20260831054331.625505-9-anshuman.khandual@arm.com
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> # m68k
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Cc: Helge Deller <deller@gmx.de>
Cc: Huacai Chen <chenhuacai@kernel.org>
Cc: James Bottomley <james.bottomley@HansenPartnership.com>
Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: Rich Felker <dalias@libc.org>
Cc: Samuel Holland <samuel.holland@sifive.com>
Cc: WANG Xuerui <kernel@xen0n.name>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
|
|
Patch series "mm: Drop pxd_ERROR()".
pxd_ERROR() macros have been provided by all platforms, which are very
much identical and can be dropped off completely if these pgtable printing
could be moved to callers in generic MM aka all pxd_clear_bad().
But first cleanups and re-organizations are required in some platforms
that are using these macros internally. Afterwards
[pte|pmd|pud|p4d|pgd]_ERROR() macros have been completely dropped from the
entire tree.
This patch (of 8):
Move ptval_to_str() inside a header thus making the helper more generally
available for new users which are being added later. While here, also
move another related string size macro PTVAL_STR_MAX inside the header as
well.
Link: https://lore.kernel.org/20260831054331.625505-1-anshuman.khandual@arm.com
Link: https://lore.kernel.org/20260831054331.625505-2-anshuman.khandual@arm.com
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: Helge Deller <deller@gmx.de>
Cc: Huacai Chen <chenhuacai@kernel.org>
Cc: James Bottomley <james.bottomley@HansenPartnership.com>
Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: Rich Felker <dalias@libc.org>
Cc: Samuel Holland <samuel.holland@sifive.com>
Cc: WANG Xuerui <kernel@xen0n.name>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
|
|
Introduce memcpy_nontemporal() for write-once copy sites that want a named
non-temporal copy primitive.
On x86_64, override the helper in arch/x86/include/asm/string_64.h using
the usual self-macro pattern, next to the existing memcpy_flushcache()
backend that memcpy_nontemporal() wraps.
include/linux/string.h provides the generic memcpy_nontemporal() fallback
as
#define memcpy_nontemporal(dst, src, len) \
((void)memcpy(dst, src, len))
instead of an inline wrapper, so architectures without a specialized
backend keep the usual memcpy() FORTIFY coverage when the compiler can
still see object sizes at the original call site. It also makes the
memcpy_nontemporal() API uniformly void, matching memcpy_flushcache() and
the x86 backend, so callers cannot accidentally depend on a return value
on fallback architectures.
memcpy_nontemporal() is only a copy primitive. It does not imply a drain
or a publication barrier. Callers that use it before a producer-consumer
or device-visible handoff must provide the required ordering at that
handoff point.
The immediate user is the ZONE_DEVICE template-copy path. It populates
struct page descriptors in a write-once pattern, so a regular cached
memcpy() can incur avoidable write-allocate traffic and cache pollution
for data with little near-term reuse.
Link: https://lore.kernel.org/20260831111638.76012-6-lizhe.67@bytedance.com
Signed-off-by: Li Zhe <lizhe.67@bytedance.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Alistair Popple <apopple@nvidia.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Balbir Singh <balbirs@nvidia.com>
Cc: "Borislav Petkov (AMD)" <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: David Hildenbrand (Arm) <david@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Kees Cook <kees@kernel.org>
Cc: Mike Rapoport (Microsoft) <rppt@kernel.org>
Cc: Muchun Song <muchun.song@linux.dev>
|
|
Callers that want to update section bits from a PFN currently need to
open-code:
set_page_section(page, pfn_to_section_nr(pfn));
and guard that sequence with #ifdef SECTION_IN_PAGE_FLAGS.
Add set_page_section_from_pfn() to wrap that update in one place. When
section bits are stored in page flags, the helper derives the section
number from the PFN and updates the page flags. Otherwise keep it as a
no-op so callers can use one helper without open-coding
SECTION_IN_PAGE_FLAGS.
Convert set_page_links() to use the new helper so later ZONE_DEVICE
fast-path patches can also update section bits without open-coding
SECTION_IN_PAGE_FLAGS at each callsite.
This keeps the PFN-to-section translation local to the configurations that
actually store section bits in struct page flags, and avoids exposing that
detail to generic callers.
No functional change intended.
Link: https://lore.kernel.org/20260831111638.76012-3-lizhe.67@bytedance.com
Signed-off-by: Li Zhe <lizhe.67@bytedance.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Acked-by: Muchun Song <muchun.song@linux.dev>
Reviewed-by: Balbir Singh <balbirs@nvidia.com>
Cc: Alistair Popple <apopple@nvidia.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: "Borislav Petkov (AMD)" <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: David Hildenbrand (Arm) <david@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Kees Cook <kees@kernel.org>
|
|
The logic that finds the struct pid for a given pid number and assigns it
to a damon_target is duplicated in multiple places. Including
damon_sysfs_add_target() of mm/damon/sysfs.c and the start functions of
the two sample modules, samples/damon/wsse.c and samples/damon/prcl.c.
Add a function that does the work, and replace the duplicated code in the
places with calls to the function.
Link: https://lore.kernel.org/20260831142611.77572-3-sj@kernel.org
Signed-off-by: Enze Li <lienze@kylinos.cn>
Signed-off-by: SJ Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: SJ Park <sj@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Hari Mishal <harimishal1@gmail.com>
Cc: Jaeyeon Lee <jaeyeon.lee.dev@gmail.com>
Cc: Li Youhong <liyouhong@kylinos.cn>
Cc: Shuah Khan <shuah@kernel.org>
Cc: "Zenghui Yu (Huawei)" <zenghui.yu@linux.dev>
Cc: zhaozhengzhuo <zhaozhengzhuo@uniontech.com>
|
