The Rx completion queue writeback coalescing window controls how long
the queue manager may defer writing completions to host memory.
Expose this window through the standard rx-cqe-nsecs ethtool
parameter. Preserve the existing 2000 ns default and accept values
from 1000 ns through the device maximum (~109 us).
Hardware expresses COAL_WAIT in 600 MHz core clock cycles, or 1.667 ns
per cycle. Programming rounds the configured value to the nearest clock
cycle, resulting in an error of less than 1 ns. Retain the requested
value for get_coalesce() because this error is below the one-nanosecond
resolution of the ethtool interface.
Signed-off-by: Mohsin Bashir <hmohsin@meta.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260909211111.1795726-1-mohsin.bashr@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The smc9194 driver was removed in commit 9fdf9f61fa ("drivers: net:
smsc: smc9194: Remove this driver"), but smc9194.h was left behind.
Remove it.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Joe Damato <joe@dama.to>
Link: https://patch.msgid.link/20260910143516.87304-1-enelsonmoore@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Kicinski says:
====================
netlink: specs: conntrack: minor spec fixes
Clashiko raised a bunch of pre-existing issues on a recent series
from Ilya. Let's fix those and whatever else pops out in AI review
and looks relatively legitimate.
====================
Link: https://patch.msgid.link/20260910003852.2184031-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
CTA_SECMARK, CTA_COUNTERS32_{PACKETS,BYTES} are all obsolete
be32 attrs. Since they are obsolete we don't bother with
the byte-order annotation, but let's be consistent about
marking them as u32 with doc: obsolete.
The attrs were obsoleted by:
commit 584015727a ("netfilter: accounting rework: ct_extend + 64bit counters (v4)")
commit 1cc63249ad ("conntrack: export lsm context rather than internal secid via netlink")
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260910003852.2184031-8-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
ctnetlink_ct_stat_cpu_fill_info() emits CTA_STATS_INVALID but
does not emit CTA_STATS_SEARCHED. Update the attr list, and
remove the false annotation of invalid as obsolete.
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260910003852.2184031-7-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
nfnl_cthelper_to_nlattr() seems to output CTA_HELP_INFO but the spec
doesn't have a definition for it, add one.
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260910003852.2184031-6-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The enum for attr IDs says:
CTA_NAT_V4_MINIP,
#define CTA_NAT_MINIP CTA_NAT_V4_MINIP
CTA_NAT_V4_MAXIP,
#define CTA_NAT_MAXIP CTA_NAT_V4_MAXIP
CTA_NAT_PROTO,
CTA_NAT_V6_MINIP,
CTA_NAT_V6_MAXIP,
Move nat-proto to the right place in the YAML spec to make sure
the attr IDs match.
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260910003852.2184031-5-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Correct the names of constants:
Value 1 is SCTP_CONNTRACK_CLOSED, not "cloned".
Value 6 is SCTP_CONNTRACK_SHUTDOWN_RECD, not "shutdown-received".
Value 8 is SCTP_CONNTRACK_HEARTBEAT_SENT, there is no "shutdown-heartbeat"
state.
Note that there's also a value of 9 (HEARTBEAT_ACKED) but sctp_nla_policy
caps the attribute at HEARTBEAT_SENT and HEARTBEAT_ACKED is marked no
longer used in the header.
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260910003852.2184031-4-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
CTA_NAT_SRC and CTA_NAT_DST are input-only. The only references to either
are cda[] reads in ctnetlink_setup_nat() and the rejection in
ctnetlink_change_conntrack(); no path ever puts them into a message, so
neither belongs in a reply. nat-dst was listed twice on top of that.
CTA_TIMESTAMP is the opposite case - both the do and the dump reach
ctnetlink_fill_info() with extinfo set, so ctnetlink_dump_extinfo() ->
ctnetlink_dump_timestamp() emits it, but the lists never named it.
Reported-by: Sashiko <netdev-bot+sashiko@kernel.org>
Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260826220444.4054714-1-i.maximets@ovn.org
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260910003852.2184031-3-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
ctnetlink_dump_timestamp() wraps CTA_TIMESTAMP_START
and CTA_TIMESTAMP_STOP in a nest, but the spec declares CTA_TIMESTAMP
as a flat be64. ynl picks reply attributes out of the attribute set rather
than the operation's attribute list, so the mistyped attribute stops
the whole dump:
Error decoding 'timestamp' from 'conntrack-attrs'
Traceback (most recent call last):
File "tools/net/ynl/pyynl/cli.py", line 314, in main
reply = ynl.dump(args.dump, attrs)
File "tools/net/ynl/pyynl/lib/ynl.py", line 1082, in _decode
decoded = attr.as_scalar(attr_spec['type'], attr_spec.byte_order)
File "tools/net/ynl/pyynl/lib/ynl.py", line 291, in as_scalar
return format_.unpack(self.raw)[0]
struct.error: unpack requires a buffer of 8 bytes
The tstamp extension is only attached when CONFIG_NF_CONNTRACK_TIMESTAMP
is enabled and nf_conntrack_timestamp is turned on, which is off by default
and is why every dump does not hit this.
stop is omitted for live entries, so it stays optional like every other
member here. The pad member mirrors counter-attrs, which covers the same
nla_put_be64() padding.
Reported-by: Sashiko <netdev-bot+sashiko@kernel.org>
Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260826220444.4054714-1-i.maximets@ovn.org
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260910003852.2184031-2-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The forwarding paths report an expired TTL or hop limit as
SKB_DROP_REASON_IP_INHDR, the reason otherwise used for a header that is
malformed (ip_input.c, exthdrs.c, br_netfilter). Nothing else in the drop
path separates the two: IPSTATS_MIB_INHDRERRORS covers both, and the TTL
check runs before NF_INET_FORWARD, so netfilter tracing stops at
PREROUTING and never sees the drop.
The Fedora bug linked below shows how that reads in practice. The
reporter took kfree_skb(reason=IP_INHDR, loc=ip_forward) to mean the
software header checksum check had failed, and worked through RX checksum
offload, tc csum actions and both libvirt firewall backends before the
drops turned out to be replies arriving with TTL 1. ip_forward() never
verifies the header checksum; that runs earlier, in ip_rcv_core(), and
reports IP_CSUM.
TTL expiry is not a corner case -- every traceroute through a Linux
router goes through too_many_hops.
The three loopback hop limit checks in exthdrs.c drop with no reason at
all; give them the new one.
IPSTATS_MIB_INHDRERRORS stays as it is: RFC 1213 counts time-to-live
exceeded under ipInHdrErrors. The drop reason has no such constraint.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2517131
Signed-off-by: Junjie Cao <junjie.cao@intel.com>
Reviewed-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260910094937.536150-1-junjie.cao@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
bui duc phuc says:
====================
net: xilinx: axienet: Fix IRQ error handling
This series fixes IRQ error handling in the Xilinx AXI Ethernet driver
Handle errors from optional IRQ lookup and preserve the original error
codes instead of returning -ENOMEM.
The changes were found by manual code inspection and compile-tested
only.
====================
Link: https://patch.msgid.link/20260909045450.16176-1-phucduc.bui@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
irq_of_parse_and_map() returns 0 when parsing or mapping an IRQ fails,
while platform_get_irq() returns a negative error code on failure.
Handle both failure cases appropriately: return -EINVAL when
irq_of_parse_and_map() fails, and propagate the original error code
returned by platform_get_irq() instead of returning -ENOMEM.
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Reviewed-by: Suraj Gupta <suraj.gupta2@amd.com>
Link: https://patch.msgid.link/20260909045450.16176-4-phucduc.bui@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
lp->eth_irq is assigned from platform_get_irq_optional(), which returns
a non-zero interrupt number on success or a negative error number on
failure. Errors other than -ENXIO are handled before this check,
so -ENXIO is the only error value that can reach this point.
Check for a negative value instead of treating 0 as an undefined IRQ.
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Link: https://patch.msgid.link/20260909045450.16176-3-phucduc.bui@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
platform_get_irq_optional() returns a positive IRQ number on success or
a negative error code on failure. For an optional IRQ, -ENXIO indicates
that no optional IRQ is available, while other errors should be propagated.
Propagate all error codes returned by platform_get_irq_optional() other
than -ENXIO.
Another call to platform_get_irq_optional() in the same function already
handles the return value this way. Apply the same error handling to this
call site for consistency.
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Link: https://patch.msgid.link/20260909045450.16176-2-phucduc.bui@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
I recently changed jobs, let's update the .mailmap entry so that patches
are attributed to the right (current) company.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
One fix for pf1550 which checked for errors on multiple regulators but
always notified via one of them regardless of which one had the problem,
plus one device ID addition in the fan53555 DT bindings.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmqkbckACgkQJNaLcl1U
h9Dfewf+PacEx4Rc51FaF9OGmniMQ5wLU8W7maJv8L/68hghxhwGQZL/KxgYZAjU
HuniSGz6GMbsJ+S1HVYVqA5GPzJgjf6CpCc8WvHZnyCNQ+R5zrAW2e9tylWJniwu
7ngrImiRdtRJkyyTv01j5KSORc7jGqXJR/Iea2nqe5IAdNxYVAbl5Jar6vynF3wA
rOJ5s2WTMu7J/ygRAVdqH0yIDbpqKaLTBn9IrCzFYxGllMkNMnKmjNICKI7OpQGu
hP8Dghe1TSFCJUPCuWMG9O8GjRZZNkYOQakr52pClhBCvI2vJPCY5D5yRCp7CDoY
5bQtDEv+we+FsuuVxvCJ60NhH8zH7A==
=fjiq
-----END PGP SIGNATURE-----
Merge tag 'regulator-fix-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fixes from Mark Brown:
"One fix for pf1550 which checked for errors on multiple regulators
but always notified via one of them regardless of which one had the
problem, plus one device ID addition in the fan53555 DT bindings"
* tag 'regulator-fix-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: pf1550: fix which regulator is notified
regulator: dt-bindings: fan53555: add tcs,tcs4526
Update the DesignWare DT binding to say how to describe the UltraRISC
DP1000 instance of the controller.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmqkbi8ACgkQJNaLcl1U
h9AmXwf/fx62hiA+UOPrKA1d4hjMI1s828iif4dgo2WPfZLkAeMnd4ibFgf/gIYv
gLKJHmdtLAJ0z1JY+01cOEvRw4UvSiPLuwaM9+tR/jWc+KhF711IJBFRba8aKH0Q
GHjbooYTkmJotx70V6MkACRgJSQjoHizHgHQoYF/UdG9YO6S8Ee0ya9XC3jMbvaZ
0cRhKPtZozuJrrra7IvNVANt0KR4W8mKcuYFWaXmtwIP8wZyL4FilGcnLfNZiz7B
GfrZ9GLJcoRbSq4gnQx4/I/8GTS8J7AaEQo69dNiexYWs+fOgDCSclLcR/GznVAU
bawIajipjKNi3pZcaoaSrgKjAWMu5Q==
=ta0L
-----END PGP SIGNATURE-----
Merge tag 'spi-fix-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fix from Mark Brown:
"New device ID for v7.3: update the DesignWare DT binding to say how to
describe the UltraRISC DP1000 instance of the controller"
* tag 'spi-fix-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi: dt-bindings: snps,dw-apb-ssi: Add compatible for UltraRISC DP1000 SoC
encrypted_key_alloc() stores datablob_len in a u16. It is computed from
multiple string and payload lengths. If the result exceeds U16_MAX, the
assignment truncates the allocation size. KASAN reports a 32760-byte
slab-out-of-bounds write when __ekey_init() copies the master key
description into the undersized buffer.
The total payload length stored in key->datalen is also a u16. Use
check_add_overflow() to reject values that do not fit either destination,
and use kzalloc_flex() for the flexible-array allocation.
Fixes: 7e70cb4978 ("keys: add new key-type encrypted")
Cc: stable@vger.kernel.org
Assisted-by: GitHub-Copilot:claude-opus-4.6
Signed-off-by: Cen Zhang <cenzhang@linux.microsoft.com>
Signed-off-by: Francis Perron <francis@akrites.dev>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Tested-by: R Nageswara Sastry <rnsastry@linux.ibm.com>
Link: https://lore.kernel.org/r/20260909153433.83117-1-cenzhang@linux.microsoft.com
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
request_key_auth_describe() prints rka->pid into /proc/keys as a raw
pid_t in the initial pid namespace. A reader can open /proc/keys through
a mount in another pid namespace. That reader sees a number with no
meaning there. The number can even name an unrelated task. The line
needs VIEW on the key. So the reader either shares the key owner's uid
or possesses the key.
The fix keeps a struct pid. Commit 4f82f45730 ("net ip6 flowlabel:
Make owner a union of struct pid * and kuid_t") gave
/proc/net/ip6_flowlabel the same storage. The print goes through
pid_nr_ns(). It renders against the pid namespace of the procfs instance
the line is read through. Commit ad08978ab4 ("ipv6/flowlabel: simplify
pid namespace lookup") moved that print to the same anchor. Output
through an initial namespace /proc does not change. The line shows 0 for
a requestor with no number in that namespace.
Translating at read time was the alternative. find_pid_ns() can resolve
a recycled number. The line would then name a live task with no
connection to the key. A stored struct pid gives 0 instead when the
requestor has no number there.
Link: https://lore.kernel.org/keyrings/20260809110202.2180410-1-maoyixie.tju@gmail.com/
Fixes: 78b7280cce ("KEYS: Improve /proc/keys")
Cc: stable@vger.kernel.org # v5.10+
Assisted-by: Claude:claude-opus-5 codeql
Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com>
Link: https://lore.kernel.org/r/20260821095935.1864998-1-maoyixie.tju@gmail.com
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
clear_bit() is atomic with respect to the word it modifies, but it is
an unordered operation: it implies no memory barrier on either side
(Documentation/atomic_bitops.txt).
key_garbage_collector() clears KEY_GC_REAPING_KEYTYPE with clear_bit()
and calls wake_up_bit() after reaping a dead key type. wake_up_bit()
uses a lockless waitqueue check and requires a full barrier after the
clear.
The existing smp_mb() is before clear_bit(), so nothing orders the clear
against that check. The GC can see an empty waitqueue while
unregister_key_type() still sees the bit set. The final wakeup is then
lost, leaving module unload stuck in wait_on_bit().
Use clear_and_wake_up_bit(). Its clear_bit_unlock() has RELEASE
semantics, so the completed GC work stays ordered before the clear, and
its smp_mb__after_atomic() orders the clear before the waitqueue check.
Fixes: 0c061b5707 ("KEYS: Correctly destroy key payloads when their keytype is removed")
Assisted-by: Claude:claude-fable-5
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Link: https://lore.kernel.org/r/20260821025327.61488-1-kmehltretter@gmail.com
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
- Revert a bad fix, likely LLM-generated, in the pointer masking code
that confused the RISC-V hardware pointer masking implementation
with the Linux kernel tagged address feature
- Fix unexpected faults caused by kprobe instruction slot writes when
!CONFIG_STRICT_MODULE_RWX
- Fix unexpected faults on minimal configurations during runtime code
patching on !CONFIG_STRICT_MODULE_RWX systems
- Fix a misplaced variable clear causing incorrect reuse of previous
values in the RISC-V hardware feature probing code
- Fix two bugs in the PMU SBI perf code on rv32: use BIT_ULL rather
than BIT on 64-bit masks; and use a bitmap rather than an unsigned
long on a quantity that can exceed 32 bits
And a few miscellaneous cleanups:
- Avoid a potential dereference-before-NULL-pointer-check bug in the
PMU SBI perf driver
- Simplify the rv32 bug table code by using
CONFIG_GENERIC_BUG_RELATIVE_POINTERS (following x86 and PPC)
- Report the RISC-V standard ISA extensions Z[v]fhmin when support is
claimed for the superset RISC-V standard ISA extensions Z[v]fh; and
simplify our FPU test code to only check for the presence of the D
extension
- Use an existing kernel string helper in place of some open-coded
code in kernel/usercfi.c
- Fix some yamllint issues in the RISC-V DT bindings for CPUs
- Convert one use of __ASSEMBLY__ to __ASSEMBLER__ that snuck into the
RISC-V CFI selftest code
- Update the translation for the simplified Chinese translation of the
RISC-V kernel patch acceptance policy
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEElRDoIDdEz9/svf2Kx4+xDQu9KksFAmqghcoACgkQx4+xDQu9
KkvmEQ/7BVmPFuoR6OLNk2Eu8Exqen6a41KxdM/B91NJBEbBM60GAyejjWDXWmm0
K21yhRu58RGbfg2kKUJMvawzwIfuDswxCS31VtpDKnTrmP4HQz1Yvnh2M7jH9D2d
/wJCIYcJ0hJx0yDIZOUhU24aoy63ZXRygp8nTOgjkAxhkF31w+MJxTPDD0Ir7Eai
y4sRMTCabMonmyA0qozfnMoXaO3FkPv9l7pw/LHfqUYjaLNQyMHiiDPrRj1oNZPD
GQFUWykRgMccMW6kIgTJrjmzn7+vEJ7UZ/fvOD97+rGeaoyE19vcW8owUQWp6Hgb
Jq3WyS9HImrpCBTr079ht5lhu3ZucpAEP6sK5v/m4GOlBv1HdYHUS6JH0qo4DnXZ
aFrxg7WXxaFZ8dD3P8ErZkXy5Vid3+ZlpK//AOfWAqxX7q6c4K1w3lJm4bPKyNBX
vh3ASQr5oEj3KpGbihsrX2lVB/5LVP3pWTcH5f6rBBYiVFMMhWKLJXA3pjiRFN7v
ZXClKh5MznvS6ycMp5pXVYpVn2Kk+Y/mywsDqNRUigHwppkxI9MTJBq8+qcOiM9I
a7mHna4XHVVu0+B4/JMhkWgnGYRjFD6bsGzxPZODLFcmBUxmsoa5+HOENLAGdQ1w
s/Z2HmDO8yL37DxLq5O2aF3KNPSkXNBl+upQwj5lTTzR/bmghjc=
=oMU+
-----END PGP SIGNATURE-----
Merge tag 'riscv-for-linus-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux
Pull RISC-V fixes from Paul Walmsley:
"From a RISC-V point of view, there's one notable fix here, reverting
an earlier bogus fix to the pointer masking code. Fortunately the
practical impact appears to be small.
- Revert a bad fix, likely LLM-generated, in the pointer masking code
that confused the RISC-V hardware pointer masking implementation
with the Linux kernel tagged address feature
- Fix unexpected faults caused by kprobe instruction slot writes when
!CONFIG_STRICT_MODULE_RWX
- Fix unexpected faults on minimal configurations during runtime code
patching on !CONFIG_STRICT_MODULE_RWX systems
- Fix a misplaced variable clear causing incorrect reuse of previous
values in the RISC-V hardware feature probing code
- Fix two bugs in the PMU SBI perf code on rv32: use BIT_ULL rather
than BIT on 64-bit masks; and use a bitmap rather than an unsigned
long on a quantity that can exceed 32 bits
And a few miscellaneous cleanups:
- Avoid a potential dereference-before-NULL-pointer-check bug in the
PMU SBI perf driver
- Use CONFIG_GENERIC_BUG_RELATIVE_POINTERS to simplify the rv32 bug
table code (like x86 and PPC)
- Report the RISC-V standard ISA extensions Z[v]fhmin when support is
claimed for the superset RISC-V standard ISA extensions Z[v]fh; and
simplify our FPU test code to only check for the presence of the D
extension
- Use an existing kernel string helper in place of some open-coded
code in kernel/usercfi.c
- Fix some yamllint issues in the RISC-V DT bindings for CPUs
- Convert one use of __ASSEMBLY__ to __ASSEMBLER__ that snuck into
the RISC-V CFI selftest code
- Update the translation for the simplified Chinese translation of
the RISC-V kernel patch acceptance policy"
* tag 'riscv-for-linus-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
riscv: skip software algning code for HAVE_EFFICIENT_UNALIGNED_ACCESS
kselftest/riscv: Replace __ASSEMBLY__ with __ASSEMBLER__
docs/zh_CN: Update arch/riscv/patch-acceptance.rst translation
dt-bindings: riscv: cpus: Fix yamllint style issues
riscv: hwprobe: simplify has_fpu() to check D extension only
perf: RISC-V: check cpu_hw_evt before dereference in overflow IRQ
riscv: report Zfhmin/Zvfhmin when Zfh/Zvfh are present
perf: RISC-V: store available counter mask as bitmap
perf: RISC-V: use BIT_ULL for u64 overflow masks
riscv: bug: Make RV32 use GENERIC_BUG_RELATIVE_POINTERS
riscv: hwprobe: initialize pair->value in hwprobe_one_pair()
riscv: use string helper in setup_global_riscv_enable()
Revert "riscv: Reset pmm when PR_TAGGED_ADDR_ENABLE is not set"
riscv: patch: skip fixmap mapping when kernel text is already writable
riscv: mm: make EXECMEM_KPROBES writable without CONFIG_STRICT_MODULE_RWX
- Drop documentation for no longer existing pata_legacy kernel
parameters (Ethan)
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQRN+ES/c4tHlMch3DzJZDGjmcZNcgUCaqRQ0QAKCRDJZDGjmcZN
ct1FAP96qnI8tDPHzWU+1znXhDEBXl3aVw8lvSBokR4yvqyDVQEAs3Jeaq38mZTQ
C3jV+RbN4YUC/St8AFt7t73soEOb8wc=
=zZKx
-----END PGP SIGNATURE-----
Merge tag 'ata-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux
Pull ata fix from Niklas Cassel:
- Drop documentation for no longer existing pata_legacy kernel
parameters (Ethan)
* tag 'ata-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux:
ata: pata_legacy: remove documentation for removed module parameters
-----BEGIN PGP SIGNATURE-----
iQJEBAABCAAuFiEEwPw5LcreJtl1+l5K99NY+ylx4KYFAmqj5hAQHGF4Ym9lQGtl
cm5lbC5kawAKCRD301j7KXHgphqIEADE/9nkItU8nufHLICBr8FI+IncrvHJQpag
1iLerBftMLxNJDS+CAQEF5oOcorL/6bUga6nHmMAds7pILdDzafWkvnuCbrGIC1q
j0V7a0Rkalv87ObbYZcoKWTTjv0IdCmNEC93fitwTujqYclI7Hwvr/t+0nkprcxU
jjbHq9tzkVHVX771usCIKOVRdI+xc5TSDbOfm13tE5ESH2GzZaPqu4Aqq3nvVSOO
xmLYzDlz8NRApmCl6a3KzCxHi8fROMnjlaeQrAmh6+Zov/iB5Bzqo98NBeWXgbh6
WvFxLm/zR5+WFppp+GblAZ5FtkOv5ICAYeM9fQkuiCo6o8/t+cxnTUgyex9qtMBr
Uhoct1jM+eNCEWEgA1ZBRVWLsyr0FbNDrowsP4YvvqW3WdQeq8ABRz44lcRqhQJy
BQYydnk7PpANdDhaAOO2JpoYbkokvPfT/8TwDFMmJlp+gwydXfE64IjE5ljaf6xr
DRMxeZzFkwYrF++1KiN3Kozqe0jFINDuB9ysPrGlDHlPFK/tbx8nZn8aKOIHccBj
mGNJ+fNWkFJczeuGiIbWEtNci0ZL+8eaDqF+uOp5odQ7vo8rYPv2TRff436dcI0c
0EnQrC9orScabgRAIklnnEWjw9XoHmpoCTQE/LhlA1rf+zDNQ2cvNopBePDuxaku
IChLh+u+0g==
=JeEt
-----END PGP SIGNATURE-----
Merge tag 'block-7.3-20260911' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux
Pull block fixes from Jens Axboe:
- Fix the start and length check added to iov_iter_extract_bvecs(),
which used iter_iov_addr()/iter_iov_len() helpers that aren't safe
for the ITER_BVEC/FOLIOQ/etc iterator types passed
- sunvdc fixes for an -EIO issue from lack of retries, and unmapping
LDC cookies when the descriptor send fails
- Clear force_abort in ublk_queue_reset_io_flags()
- ublk selftest install fix
* tag 'block-7.3-20260911' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux:
selftests: ublk: add batch IO cases to recover_03
ublk: clear force_abort in ublk_queue_reset_io_flags()
sunvdc: fix -EIO issue due to lack of retries
sunvdc: unmap LDC cookies when the descriptor send fails
block: Fix start and length check added to iov_iter_extract_bvecs()
selftests: ublk: install test_common.sh and trace/ scripts
-----BEGIN PGP SIGNATURE-----
iQJEBAABCAAuFiEEwPw5LcreJtl1+l5K99NY+ylx4KYFAmqj5fsQHGF4Ym9lQGtl
cm5lbC5kawAKCRD301j7KXHgpmGsD/0W7eNXJd/tFNPOdDwTr1/3yciqYXw5QO5Q
eb2SLyr34sAODOItTYoBrIZ5b1Mbgm0yhT1wJ3YrVKLNLVSvbDPNtx5qtnAGcKvm
09XsPmvlDcW8JLRsjd5dcsP+EDmgTNLuNGSeVycuTG91f5VD63vPHTKUhgKDabtC
InM1LbIs2rz0tojdV6n4MOOF2AwZAOHqFtac+cQUCwuJhNtwUFClSUHxqYoP+JzE
97ores3f+ArAtmOoVeH2wSCZTmwdB7MxOB8jmt8fdNSprW8nxTO3oT/eQzYXvlM9
7LRJV/6SGVsWjuoEHAfW8G0p+JOzGGFvFIXGWEBenjtNmlyXJqfxYhkcLMw826ob
pct3Rc5nheZbxKdCkHnY1AmEibS/c1kTZbDvSBXk9GLBKyQuI7B3yo163zMs3JjO
YSAlLllDjdzOR6gCPg5HHZlywBWtXveC/xVBzDq7b1q07ysHFNO1yQplMM3U8sC0
Eic4RcFU4ld+/L2GmbdgRZ9ataZsju+RFojSogA0NzR18HqVNQuZiVbY764GSop9
HVW28lzoYamgvg5fLWJPrzJmdFrj/p8pi+cw1dK8uMk9VnFwdA740Nfhz1NWFS0Y
TpvJtxc0f2ofrI1ilaa95vHC+wMyds1zxq9Bf4i9cgIhT17WqvE4SD0JMXmvza4k
Yi72jzTTfQ==
=zpCb
-----END PGP SIGNATURE-----
Merge tag 'io_uring-7.3-20260911' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux
Pull io_uring fixes from Jens Axboe:
- Fix a deadlock in the write path with superblock freezing
- Fix an issue where a provided buffer ring would overconsume when
using MSG_TRUNC
- Keep the CQE flags on iopoll requests when adding kbuf flags
* tag 'io_uring-7.3-20260911' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux:
io_uring/rw: keep CQE flags on iopoll requests when adding kbuf flags
io_uring/net: don't overconsume buffers when using MSG_TRUNC
io_uring/net: let io_recv_buf_select return the length of the buffer region
io_uring/rw: end write accounting from ->ki_complete
Currently, when cifs_oplock_break handles a break request from the server
it searches for the appropriate tlink to handle the request
but incorrectly uses the current fsuid as the search key, eventually
causing read errors for users with multiuser mounts on NetApp.
Fix this by using the tlink from the cfile struct instead to respond
through the correct session.
As breaks are handled in a worker thread, the current fsuid
isn't guaranteed to match the session that the break is intended for.
This means that cifs_sb_tlink may search the rbtree using the wrong fsuid,
and return a tlink with an incorrect session than
the lease break was intended for. As a result, the breaks
may be ACKed through an incorrect session.
While it seems that Samba/Windows Servers 2016-2025 ignore this as long as
the lease key is correct, we ran into a case where if you're using
NetApp ONTAP or Azure NetApp Files they will reject the ACK
and return `STATUS_LOCK_NOT_GRANTED` errors on any future read requests
a user may initiate through their still held open file handle,
and the server will eventually close the file.
In the dmesg logs, the user may see errors like these:
CIFS: Status code returned 0xc0000128 STATUS_FILE_CLOSED
CIFS: VFS: Send error in read = -9
With a multiuser mount using NetApp, this issue is really easy
for users to hit on a wide variety of kernel versions
by attempting to copy a file from the share
to the local machine through GNOME Files/Nautilus.
This copy will always result in Nautilus throwing
a `Bad File Descriptor` error to the user and fail.
With this fix, you can copy files through Nautilus without issue.
>From looking at the traces, it seems that glib will
open the file first, and call listxattr before actually attempting
to copy the file data. The listxattr call always triggers a break,
causing the copy to fail.
The proposed fix returns to the way the client grabbed the tlink before
commit e8f5f849ff ("cifs: fix potential oops in cifs_oplock_break").
The bulk of that commit (checking for list empty) remains untouched, and
I think the change to using cifs_sb_tlink was intended to avoid a
NULL/ERR deference on the tlink as well as update the reference count.
I believe this fix should preserve those safety properties, but of course
I'd appreciate any corrections here.
Fixes: e8f5f849ff ("cifs: fix potential oops in cifs_oplock_break")
Cc: stable@vger.kernel.org
Signed-off-by: April Cardenas <april.cardenas@canonical.com>
Reviewed-by: Namjae Jeon <linkinjeon@kernel.org>
Reviewed-by: Bharath S M <bharathsm@microsoft.com>
Signed-off-by: Paulo Alcantara <pc@manguebit.org>
-----BEGIN PGP SIGNATURE-----
iQFPBAABCAA5FiEEe7vIQRWZI0iWSE3xu+CwddJFiJoFAmqjuAUbFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMiwyAAoJELvgsHXSRYia070H/RpgbPlRT+YF5EceAqlz
gbCHYJa7ep52uCIZSgHd0DpMiE3jF8tRtLlpaF2l961hYXIr+NhEC9HKerJcD5tc
4LUpGu6Cs5/ruYz7fbAltYrAZ2YOAhaJwBBy0Buc2Xl37OpONR8hUWMYlqqXBSWM
bApp9mrRYzLmQBpYn5N1KyZU9gBespiouCnStEUzD2s06VjnHSUJ5tBplbXXPC0v
My/kjaUim9z0P91FHPFooFQtzhlLQI96obROsbKR18euePml+C+XPhhmDwAY0NVT
VtAPm2ov7oTvy0FvjDAVzAdrYGIIXVluonJqhgLFi6+Um1L3iBE39Q2OEMiQ/Lq3
044=
=B/eP
-----END PGP SIGNATURE-----
Merge tag 'slab-for-7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/mm/slab
Pull slab fixes from Vlastimil Babka:
- Stable fix for an ABA issue causing slab list corruption introduced
in 7.2 (Harry Yoo, with big thanks to Hyunwoo Kim for the thorough
report and initial version of the fix)
- Fix for 7.3 regression of kvfree_rcu() on PREEMPT_RT which can cause
a deadlock from the set_cpus_allowed_force() caller (Vlastimil Babka)
* tag 'slab-for-7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/mm/slab:
mm/slab: take n->list_lock in __slab_try_return_freelist() to avoid race
mm/slab: disallow kfree_rcu_sheaf() on PREEMPT_RT again
The a750 uses the GMU CX AO Counters instead of the GMU_ALWAYS_ON_COUNTER
register on A6xx and other A7xx GPUs, use it when running a A750 GPU.
The GMU_ALWAYS_ON_COUNTER at offset 0x1f888 doesn't seem to exist
on the SM8650 A750 GMU and returns 0, but the CX AO counter at offset
0x1f880 returns some proper timestamp data.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/752235/
Message-ID: <20260909-topic-sm8650-gmu-a750-timestamp-reg-v2-2-091d74958951@linaro.org>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
The a750 uses the CX AO Counters instead of the GMU_ALWAYS_ON_COUNTER
register on A6xx and other A7xx GPUs.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/752234/
Message-ID: <20260909-topic-sm8650-gmu-a750-timestamp-reg-v2-1-091d74958951@linaro.org>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
The adreno_perfcntrs macro already takes the XML file stem as its second
argument, allowing each perf counter JSON file to select the appropriate
register XML. The a2xx and a5xx entries already pass their respective
XML file stems.
Remove the stale TODO comment.
Signed-off-by: George Emmanuel Thomas <georgeemmanuelthomas@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/746745/
Message-ID: <20260815164335.158958-1-georgeemmanuelthomas@gmail.com>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
rb_wake_up_waiters() is a irq_work callback which is initialized with
init_irq_work(). As such it will be invoked in thread context on
PREEMPT_RT. Invoking the callback in IRQ context on PREEMPT_RT is not an
option due its usage of wake_up_all(). Since this callback may run in
thread context, it needs to acquire ring_buffer_per_cpu::reader_lock with
disabling interrupts and may not assume that they are disabled.
Use raw_spinlock_irqsave() to acquire ring_buffer_per_cpu::reader_lock.
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260911102152.YEtwkBj9@linutronix.de
Fixes: 68282dd930 ("ring-buffer: Fix resetting of shortest_full")
Reviewed-by: Vincent Donnefort <vdonnefort@google.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
With symlinkroot unset, an absolute target is copied without conversion
to an NT drive path. Later code still assumes an NT prefix is present
when modifying the target and calculating the print name length.
For "/ab", this causes two failures: sym[5] and path[5] are written
past their allocations, and plen -= 2 * poff subtracts an assumed
8-byte prefix from a 6-byte UTF-16 target, wrapping u16 plen to 65534.
That underflow causes another overflow: memcpy() copies 65534 bytes
into a 24-byte buffer. A user with write access to a mounted share
can trigger these bugs with default settings.
Validate the NT drive prefix, including an ASCII drive letter, before
accessing fixed offsets or subtracting the prefix length.
Fixes: 3363da82e0 ("smb: client: fix native SMB symlink traversal")
Assisted-by: Codex:gpt-5
Signed-off-by: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr>
Reviewed-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Paulo Alcantara <pc@manguebit.org>
When a tracer option file is opened, it is passed a descriptor that points
to an element on the trace_array's topts array. This element has
information to find the trace array and other information. It uses this
element to take a reference of the trace_array so that the trace_array
does not get removed while this file is opened.
Unfortunately, there's a race condition where the element itself could be
freed by the removal of the instance the trace_array represents causing a
use-after-free as this element that is used to find the trace_array to
increment its reference counter is also freed when the instance is
removed.
To solve this, add a trace_array_tracer_options_get() helper function that
will take the address of the element that is passed to the open function
by the inode->i_private pointer and search all the trace_arrays under a
lock to find the one that the element's address is in the range of the
trace_arrays topts array elements. When a match happens, that trace_array's
reference would be increased.
Note, there's a race where if an admin was deleting and creating trace
instances at the same time and the memory of the old trace_array's array
matched the memory of the new trace_array that it could in theory open the
option from the wrong trace array. But we do not care because it would be
stupid to perform that kind of action. As long as the only thing that can
happen is that the option from the wrong trace array is used and doesn't
crash the kernel it will only make the user confused. But if they are
doing something stupid like this, they are already confused, so no harm
done.
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260910221209.62dad8d3@robin
Fixes: 7e2cfbd2d3 ("tracing: Have option files inc the trace array ref count")
Reported-by: sashiko-bot@kernel.org
Closes: https://lore.kernel.org/linux-trace-kernel/20260902121918.5a9e9d1b@gandalf.local.home/
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
ring_buffer_read_page_size() takes a parameter named rpage, but its
kernel-doc describes page. As a result, kernel-doc reports rpage as
undescribed and page as an excess parameter description.
Rename the documentation entry to match the function.
Link: https://patch.msgid.link/20260909062917.89482-1-kmehltretter@gmail.com
Fixes: dae8dda341 ("tracing: Fix subbuf resize races with trace_pipe_raw readers")
Assisted-by: LLM
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Reviewed-by: Vincent Donnefort <vdonnefort@google.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
While ftrace_set_clr_event() modifies its input buffer during parsing,
before returning to the caller the buffer is supposed to be restored
to its original state.
This works correctly for the colon between the subsystem and event
but not the colon at the beginning of :mod:.
Restore the colon, so the :mod: trailer is not stripped after
ftrace_set_clr_event().
Cc: stable@vger.kernel.org
Fixes: 4c86bc531e ("tracing: Add :mod: command to enabled module events")
Link: https://patch.msgid.link/20260908-tracing-cli-event-filter-v2-1-05396a3fb663@linutronix.de
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
"cpu", "CPU", "stacktrace" and "STACKTRACE" are generic fields, defined
with an offset and a size of zero so that the filter code can match them
by name. parse_field() maps them onto their common_* equivalents for
backward compatibility, but unlike the common_* names it hands the
placeholder back to the caller instead of NULL.
create_hist_field() takes a non-NULL field as a promise that the record
carries a stacktrace and picks HIST_FIELD_FN_STACK, so the __data_loc
word is read from offset 0, that is from common_type, and its low 16
bits are followed as an offset into the record. What is found there
becomes the length of an unbounded memcpy. Pick an event whose id is
small enough that the offset stays inside its own record and the length
is a kernel text address:
# cd /sys/kernel/tracing
# echo 'hist:keys=STACKTRACE' > events/ftrace/print/trigger
# echo hello > trace_marker
Oops: general protection fault, probably for non-canonical address
RIP: 0010:rb_next+0x23/0x60
</IRQ>
RIP: 0010:memcpy+0xc/0x30
event_hist_trigger+0x2e7/0x12c0
Kernel panic - not syncing: Fatal exception in interrupt
Leave the field NULL, which is what the comment above the branch says
the code does and what common_stacktrace already does. FILTER_CPU and
FILTER_COMM are left alone, their create_hist_field() branches never
look at the field.
Cc: stable@vger.kernel.org
Fixes: 4b512860bd ("tracing: Rename stacktrace field to common_stacktrace")
Link: https://patch.msgid.link/20260907155045.692664-3-donggeunyoo.kernel@gmail.com
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
parse_field() sets HIST_FIELD_FL_STACKTRACE from the ".stacktrace"
modifier before it looks the field name up, and nothing afterwards
checks that the name resolved to a field which holds a stacktrace.
create_hist_field() picks HIST_FIELD_FN_STACK on the strength of the
field pointer alone, which reads a __data_loc word from the record and
follows its low 16 bits as an offset into the same record.
event_hist_trigger() takes the first word there as an entry count and
copies that many longs into a 31 entry array:
n_entries = *stack;
memcpy(entries, ++stack, n_entries * sizeof(unsigned long));
Neither end of that copy is bounded, and the count is whatever the event
holds at the offset, so any field will do:
# cd /sys/kernel/tracing/events/sched/sched_process_fork
# echo 'hist:keys=parent_pid.stacktrace' > trigger
# (true)
BUG: kernel NULL pointer dereference, address: 0000000000000008
RIP: 0010:rb_insert_color+0x18/0x130
timerqueue_linked_add+0x7e/0xd0
enqueue_hrtimer+0x39/0xb0
__hrtimer_run_queues+0x10f/0x1f0
</IRQ>
RIP: 0010:memcpy+0xc/0x30
event_hist_trigger+0x165/0x690
The timer interrupt landed on the rbtree the copy had already run over.
No debug options are needed for this; KASAN reports the same write as an
out-of-bounds read of 13835058055416381440 bytes.
Documentation/trace/histogram.rst already states the rule, "must be a
long[] type", so enforce it once the name has been resolved. Names which
resolve to no field at all, "hitcount.stacktrace" and the common_*
pseudo-fields, are refused for the same reason: they hold no stacktrace
to read.
Cc: stable@vger.kernel.org
Fixes: cc5fc8bfc9 ("tracing/histogram: Add stacktrace type")
Link: https://patch.msgid.link/20260907155045.692664-2-donggeunyoo.kernel@gmail.com
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Commit 6f86bdeab6 ("tracing: Fix bad hist from corrupting named_triggers
list") described how a trigger that is registered but not on file->triggers
ends up freed while still on the global named_triggers list, and moved the
registration down so that hist_trigger_enable() follows it immediately. One
path still gets there. hist_trigger_enable() adds the trigger and takes it
straight back out when the event cannot be enabled:
list_add_tail_rcu(&data->list, &file->triggers);
update_cond_flag(file);
if (trace_event_trigger_enable_disable(file, 1) < 0) {
list_del_rcu(&data->list);
update_cond_flag(file);
ret--;
}
so the list walk in hist_unregister_trigger() matches nothing, test stays
NULL, and the ->free() that would call del_named_trigger() is skipped.
out_unreg falls through to out_free, which frees the trigger anyway:
BUG: KASAN: slab-use-after-free in find_named_trigger+0xac/0xc0
Read of size 8 at addr ffff8880091d3160 by task init/1
find_named_trigger+0xac/0xc0
hist_register_trigger+0xc1/0xa00
event_hist_trigger_parse+0x3146/0x6af0
event_trigger_write+0xce/0x160
Freed by task 69:
kfree+0x154/0x420
trigger_kthread_fn+0xfd/0x160
Leave the trigger where hist_unregister_trigger() can find it and let that
undo the registration, which is the only code that knows all of what
cmd_ops->init() took: the named list entry, the hist_pad reference, the
reference on the trigger a named histogram is shared with, and the copied
cmd_ops. It also pairs the failed trace_event_trigger_enable_disable(),
whose sm_ref and buffered event reference are otherwise left behind.
Since ->free() releases trigger_data and, for a trigger that does not share
its histogram, hist_data with it, out_unreg can no longer fall through to
out_free. For a trigger that does share, hist_register_trigger() has
already destroyed the caller's hist_data, so the fall-through was reading
freed memory there as well.
Move the enable_timestamps check in hist_unregister_trigger() above the
->free() call for the same reason: hist_data does not outlive it once the
trigger being removed is the one that owns it.
Cc: stable@vger.kernel.org
Fixes: 067fe038e7 ("tracing: Add variable reference handling to hist triggers")
Reported-by: Sashiko AI <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/linux-trace-kernel/20260907092944.3950E1F00A3D@smtp.kernel.org/
Link: https://patch.msgid.link/20260907124420.607097-3-donggeunyoo.kernel@gmail.com
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
event_hist_trigger_named_init() puts the trigger on the global
named_triggers list and only then takes the reference on the trigger it
shares its histogram with:
data->ref++;
save_named_trigger(data->named_data->name, data);
ret = event_hist_trigger_init(data->named_data);
if (ret < 0) {
kfree(data->cmd_ops);
data->cmd_ops = &trigger_hist_cmd;
}
return ret;
event_hist_trigger_init() fails when alloc_hist_pad() cannot allocate, and
nothing takes the trigger back off the list on the way out.
event_hist_trigger_parse() frees it, and the next lookup by name reads the
freed object:
BUG: KASAN: slab-use-after-free in find_named_trigger+0xac/0xc0
Read of size 8 at addr ffff888009346860 by task init/1
find_named_trigger+0xac/0xc0
hist_register_trigger+0xc1/0xa00
event_hist_trigger_parse+0x3146/0x6af0
event_trigger_write+0xce/0x160
Freed by task 67:
kfree+0x154/0x420
trigger_kthread_fn+0xfd/0x160
Do the reference first and publish once it has succeeded, so that nothing
which can fail runs after the trigger becomes findable.
Cc: stable@vger.kernel.org
Fixes: 7ab0fc61ce ("tracing: Move histogram trigger variables from stack to per CPU structure")
Reported-by: Sashiko AI <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/linux-trace-kernel/20260907092944.3950E1F00A3D@smtp.kernel.org/
Link: https://patch.msgid.link/20260907124420.607097-2-donggeunyoo.kernel@gmail.com
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Acked-by: Tom Zanussi <zanussi@kernel.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
hist_register_trigger() puts the trigger on the global named_triggers
list in cmd_ops->init(), and only then sets the trace clock:
if (data->cmd_ops->init) {
ret = data->cmd_ops->init(data);
if (ret < 0)
goto out;
}
if (hist_data->enable_timestamps) {
ret = tracing_set_clock(file->tr, hist_data->attrs->clock);
if (ret) {
hist_err(tr, HIST_ERR_SET_CLOCK_FAIL, errpos(clock));
goto out;
}
The clock string is not checked anywhere before that call, so a named
trigger using common_timestamp with an unknown clock fails after it has
already become findable. event_hist_trigger_parse() then frees it
without taking it off the list, and the next lookup by name reads the
freed object:
~# cd /sys/kernel/tracing/events/sched/sched_switch
~# echo 'hist:name=foo:keys=common_pid:ts=common_timestamp:clock=bogus' > trigger
bash: echo: write error: Invalid argument
~# echo 'hist:name=foo:keys=common_pid' > trigger
BUG: KASAN: slab-use-after-free in find_named_trigger+0xac/0xc0
Read of size 8 at addr ffff88800915d760 by task init/1
find_named_trigger+0xac/0xc0
hist_register_trigger+0xc1/0x900
event_hist_trigger_parse+0x3146/0x6af0
event_trigger_write+0xce/0x160
Freed by task 63:
kfree+0x154/0x420
trigger_kthread_fn+0xfd/0x160
Set the clock before the trigger is registered, so that nothing which
can fail runs after it is published, the way commit 6f86bdeab6
("tracing: Fix bad hist from corrupting named_triggers list") moved the
registration below the rest of the setup.
tracing_set_filter_buffering() is reference counted, so the init failure
path has to drop the reference that the clock block now takes first.
Cc: stable@vger.kernel.org
Fixes: a4072fe85b ("tracing: Add a clock attribute for hist triggers")
Link: https://patch.msgid.link/20260907091415.554535-1-donggeunyoo.kernel@gmail.com
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Correct "preceeded" to "Preceded", reported by scripts/checkpatch.pl using
the misspelling list in scripts/spelling.txt. Only touches comments, no
code changes.
Link: https://patch.msgid.link/20260907065607.36615-1-hemanth.selam@gmail.com
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Correct "availabe" to "available", reported by scripts/checkpatch.pl using
the misspelling list in scripts/spelling.txt. Only touches comments, no
code changes.
Link: https://patch.msgid.link/20260907062608.13924-1-hemanth.selam@gmail.com
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
The .percent and .graph modifiers exist only for histogram values, but a
value carrying either of them has been rejected since v6.3. The example
in Documentation/trace/histogram.rst,
# echo 'hist:keys=prev_comm:vals=hitcount.percent:nohitcount' > \
events/sched/sched_switch/trigger
returns -EINVAL.
parse_field() sets the two flags only when the field is neither a key nor
a variable, that is, only on a value:
} else if (strncmp(modifier, "percent", 7) == 0) {
if (*flags & (HIST_FIELD_FL_VAR | HIST_FIELD_FL_KEY))
goto error;
*flags |= HIST_FIELD_FL_PERCENT;
__create_val_field() then rejects a value for carrying them, so no field
can reach hist_trigger_print_val(), where both are implemented.
commit e0213434fe ("tracing: Do not let histogram values have some
modifiers") added the check after a value with .buckets oopsed in
hist_field_name(). That happens because .buckets and .log2 make
create_hist_field() build a nested field in operands[0] which
hist_field_name() then walks into. The percent and graph flags do not
create an operand and are not read by hist_field_name(); they are only
used when printing a value.
Stop rejecting the two flags on a value. The check for variables is left
alone, where they are unreachable anyway because parse_field() rejects a
variable carrying them first.
With the two flags removed, the trigger above installs and prints as
documented:
{ prev_comm: rcu_preempt } hitcount (%): 0.00
{ prev_comm: init } hitcount (%): 99.98
Totals:
Hits: 237896
Cc: stable@vger.kernel.org
Fixes: e0213434fe ("tracing: Do not let histogram values have some modifiers")
Link: https://patch.msgid.link/20260907052113.430818-1-donggeunyoo.kernel@gmail.com
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
print_entries() uses n_entries both as the number of sort entries and as
its own return value, so the -ENOMEM it stores when the stats allocation
fails overwrites the count that the cleanup still needs:
n_entries = tracing_map_sort_entries(map, ...);
if (n_entries < 0)
return n_entries;
...
if (!stats) {
n_entries = -ENOMEM;
goto out;
}
...
out:
tracing_map_destroy_sort_entries(sort_entries, n_entries);
tracing_map_destroy_sort_entries() takes an unsigned int and loops up to
it, so -ENOMEM arrives as 4294967284. It walks an array of at most
map->max_elts pointers and calls destroy_sort_entry(), which dereferences
and frees, on whatever lies past the end.
Reading the hist file of a trigger with a .percent value, with that
allocation forced to fail:
BUG: KASAN: vmalloc-out-of-bounds in tracing_map_destroy_sort_entries+0xa0/0xb0
Read of size 8 at addr ffffc90000045000 by task init/1
tracing_map_destroy_sort_entries+0xa0/0xb0
hist_show+0x6f7/0x1df0
seq_read_iter+0x2b8/0x1190
vfs_read+0x176/0xa40
The buggy address belongs to a 4-page vmalloc region starting at
ffffc90000041000 allocated at tracing_map_sort_entries+0x5c/0xd50
A few pages further the fault is fatal. The registers at the oops confirm
the bound: the loop's end pointer less the array start, over the pointer
size, is 4294967284.
Return the error in a separate variable and leave n_entries holding the
count, the way tracing_map_sort_entries() does on its own error path.
The stats block is only entered for a value carrying .percent or .graph,
which __create_val_field() has rejected since v6.3, so this cannot be
reached in mainline as it stands. It becomes reachable again with
"tracing: hist: let values keep the percent and graph modifiers", so it
should be applied first.
Cc: stable@vger.kernel.org
Fixes: abaa5258ce ("tracing: Add .percent suffix option to histogram values")
Link: https://patch.msgid.link/20260907060323.480728-1-donggeunyoo.kernel@gmail.com
Reported-by: sashiko-bot@kernel.org
Closes: https://lore.kernel.org/all/20260907053113.1CED91F00A3A@smtp.kernel.org/
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Writing a hist trigger whose value or variable carries a modifier that is
not allowed there leaks the fields that were built for it.
__create_val_field() takes the field from parse_expr() and stores it in
hist_data->fields[] only after the modifier checks have run:
hist_field = parse_expr(hist_data, file, field_str, flags, var_name,
&n_subexprs);
...
if (hist_field->flags & HIST_FIELD_FL_VAR) {
if (hist_field->flags & (...))
goto err;
} else {
if (hist_field->flags & (...))
goto err;
}
hist_data->fields[val_idx] = hist_field;
Both checks jump past that store, and the err label returns without
freeing anything. The error unwinds to create_hist_data(), which calls
destroy_hist_data() -> destroy_hist_fields(), and that reaches a field
only by walking fields[]. A field that never got there is unreachable.
commit e0213434fe ("tracing: Do not let histogram values have some
modifiers") set ret to -EINVAL and fell through to the store, which left
the field owned by fields[] and freed along with the rest of hist_data.
Splitting the check into a value case and a variable case replaced that
fall-through with a goto that skips it.
With CONFIG_DEBUG_KMEMLEAK, 200 writes of
# echo 'hist:keys=prev_pid:vals=next_pid.log2' > \
events/sched/sched_switch/trigger
each correctly rejected with -EINVAL, leave 332 unreferenced objects
(63744 bytes) reported at create_hist_field(); 200 install and remove
cycles of a valid trigger leave none. A '.log2' field is two
allocations, since create_hist_field() puts the plain field in
operands[0] of the log2 field, and both are reported.
Use destroy_hist_field() rather than __destroy_hist_field() so that
operands[0] is freed as well. It returns early for HIST_FIELD_FL_VAR_REF,
which is what an operand owned by hist_data->var_refs[] needs; the
rejected field itself is never a var ref, because a var ref never carries
a modifier flag.
Cc: stable@vger.kernel.org
Fixes: e30fbc618e ("tracing/histograms: Allow variables to have some modifiers")
Link: https://patch.msgid.link/20260907034948.240387-1-donggeunyoo.kernel@gmail.com
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
create_var_ref() allocates a VAR_REF hist_field and then calls
init_var_ref() to fill it in. When that fails the field is leaked.
commit 656fe2ba85 ("tracing: Use hist trigger's var_ref array to destroy
var_refs") made destroy_hist_field() return early for
HIST_FIELD_FL_VAR_REF, since var refs are freed by walking the trigger's
var_refs[] array instead. create_var_ref() adds the field to that array
only after init_var_ref() has succeeded, so on this path the field is in
neither place and nothing frees it. The call was correct when it was
written, before var refs were taken out of destroy_hist_field().
init_var_ref() cannot free it either. The caller owns the field, so
init_var_ref() undoes only its own string allocations and leaves the
field alone. Freeing it there would leave create_var_ref() passing freed
memory to destroy_hist_field(), which reads its flags.
Call __destroy_hist_field(), which frees the field without consulting
the flag.
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260906133352.3815019-1-donggeunyoo.kernel@gmail.com
Fixes: 656fe2ba85 ("tracing: Use hist trigger's var_ref array to destroy var_refs")
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Using the same variable three or more times in one hist trigger leaks the
variable reference and its strings when the trigger is removed.
commit 656fe2ba85 ("tracing: Use hist trigger's var_ref array to destroy
var_refs") made a trigger's var_refs[] array the only owner of a var ref:
destroy_hist_field() returns early for HIST_FIELD_FL_VAR_REF, so the field
expressions never destroy one. One entry, freed once, no count needed.
commit 8bcebc77e8 ("tracing: Fix histogram code when expression has same
var as value") then made repeated references share one object and added a
count of them. Only the increment side exists, since those expressions
still return early and never drop a reference, so __destroy_hist_field()
sees how many references were created rather than how many are left. It
frees when the decremented count is 0 or 1, so two references work and
three or more leak.
Sharing kept one array entry per object, and create_var_ref() searches and
appends within a single trigger, so nothing outside it holds the object.
Removing a trigger whose variables are still referenced is already refused
by check_var_refs() with -EBUSY. Drop the count and free unconditionally.
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260906124025.3550596-1-donggeunyoo.kernel@gmail.com
Fixes: 8bcebc77e8 ("tracing: Fix histogram code when expression has same var as value")
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
