VF recovery is a per-GT operation, so it makes sense to isolate it to a
per-GT queue. Scheduling this operation on the same worker as the GT
reset and TDR not only aligns with this design but also helps avoid race
conditions, as those operations can also modify the queue state.
v2:
- Fix lockdep splat (Adam)
- Use xe_sriov_vf_migration_supported helper
v3:
- Drop xe_gt_sriov_ prefix for private functions (Michal)
- Drop message in xe_gt_sriov_vf_migration_init_early (Michal)
- Logic rework in vf_post_migration_notify_resfix_done (Michal)
- Rework init sequence layering (Michal)
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Tomasz Lis <tomasz.lis@intel.com>
Link: https://lore.kernel.org/r/20251008214532.3442967-10-matthew.brost@intel.com
Add xe_gt_recovery_pending helper.
This helper serves as the singular point to determine whether a GT
recovery is currently in progress. Expected callers include the GuC CT
layer and the GuC submission layer. Atomically visable as soon as vCPU
are unhalted until VF recovery completes.
v3:
- Add GT layer xe_gt_recovery_inprogress (Michal)
- Don't blow up in memirq not enabled (CI)
- Add __memirq_received with clear argument (Michal)
- xe_memirq_sw_int_0_irq_pending rename (Michal)
- Use offset in xe_memirq_sw_int_0_irq_pending (Michal)
v4:
- Refactor xe_gt_recovery_inprogress logic around memirq (Michal)
v5:
- s/inprogress/pending (Michal)
v7:
- Fix typos, adjust comment (Michal)
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Tomasz Lis <tomasz.lis@intel.com>
Link: https://lore.kernel.org/r/20251008214532.3442967-9-matthew.brost@intel.com
The LRC W/A currently checks for LRC being iomem in some places, while
in others it checks if the scratch buffer is non-NULL. This
inconsistency causes issues with the VF post-migration recovery code,
which blindly passes in a scratch buffer.
This patch standardizes the check by consistently verifying whether the
LRC is iomem to determine if the scratch buffer should be used.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Tomasz Lis <tomasz.lis@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://lore.kernel.org/r/20251008214532.3442967-8-matthew.brost@intel.com
Now that we save the job's head during submission, it's no longer
necessary to adjust the LRC ring head during resubmission. Instead, a
software-based adjustment of the tail will overwrite the old jobs in
place. For some odd reason, adjusting the LRC ring head didn't work on
parallel queues, which was causing issues in our CI.
v5:
- Add comment in guc_exec_queue_start explaning why the function works
(Auld)
v7:
- Only adjust first state on first unsignaled job (Auld)
v8:
- Break unsignaled job handling to separate patch (Auld)
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Tomasz Lis <tomasz.lis@intel.com>
Link: https://lore.kernel.org/r/20251008214532.3442967-7-matthew.brost@intel.com
In all cases where the first pending job helper is called, we only want
to retrieve the first unsignaled pending job, as this helper is used
exclusively in recovery flows. It is possible for signaled jobs to
remain in the pending list as the scheduler is stopped, so those should
be skipped.
Also, add kernel documentation to clarify this behavior.
v8:
- Split out into own patch (Auld)
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://lore.kernel.org/r/20251008214532.3442967-6-matthew.brost@intel.com
VF migration requires jobs to remain pending so they can be replayed
after the VF comes back. Previously, LR job fences were intentionally
signaled immediately after submission to avoid the risk of exporting
them, as these fences do not naturally signal in a timely manner and
could break dma-fence contracts. A side effect of this approach was that
LR jobs were never added to the DRM scheduler’s pending list, preventing
them from being tracked for later resubmission.
We now avoid signaling LR job fences and ensure they are never exported;
Xe already guards against exporting these internal fences. With that
guarantee in place, we can safely track LR jobs in the scheduler’s
pending list so they are eligible for resubmission during VF
post-migration recovery (and similar recovery paths).
An added benefit is that LR queues now gain the DRM scheduler’s built-in
flow control over ring usage rather than rejecting new jobs in the exec
IOCTL if the ring is full.
v2:
- Ensure DRM scheduler TDR doesn't run for LR jobs
- Stack variable for killed_or_banned_or_wedged
v4:
- Clarify commit message (Tomasz)
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Tomasz Lis <tomasz.lis@intel.com>
Link: https://lore.kernel.org/r/20251008214532.3442967-5-matthew.brost@intel.com
Add explicit tracking in the GuC submission state to record the source
of a pending enable (TDR vs. queue resume path vs. submission).
Disambiguating the origin lets the GuC submission state machine apply
the correct recovery/replay behavior.
This helps VF restore: when the device comes back, the state machine knows
whether the pending enable stems from timeout recovery, from a queue resume
sequence, or submission and can gate sequencing and fixups accordingly.
v4:
- Clarify commit message (Tomasz)
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Tomasz Lis <tomasz.lis@intel.com>
Link: https://lore.kernel.org/r/20251008214532.3442967-4-matthew.brost@intel.com
VF post-migration recovery needs to modify the ring with updated GGTT
addresses for pending jobs. Save off position in ring in which a job was
programmed to facilitate.
v4:
- s/VF resume/VF post-migration recovery (Tomasz)
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Tomasz Lis <tomasz.lis@intel.com>
Link: https://lore.kernel.org/r/20251008214532.3442967-3-matthew.brost@intel.com
kmalloc can fail, the returned value must have a NULL check. This should
be immediately after kmalloc for clarity.
v5:
- Assert state->buffer in setup_bo if buffer is iomem (Tomasz)
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Tomasz Lis <tomasz.lis@intel.com>
Link: https://lore.kernel.org/r/20251008214532.3442967-2-matthew.brost@intel.com
Add "INTC10D1" ACPI device-id for MTL-CVF devices, like the Dell Latitude
7450.
Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2368506
Signed-off-by: Hans de Goede <hansg@kernel.org>
Acked-by: Israel Cepeda <israel.a.cepeda.lopez@intel.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Add missing configuration for loopback mode in airhoha_set_gdm2_loopback
routine.
Fixes: 9cd451d414 ("net: airoha: Add loopback support for GDM2")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://patch.msgid.link/20251008-airoha-loopback-mode-fix-v2-1-045694fe7f60@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Jakub Kicinski says:
====================
eth: fbnic: fix XDP_TX and XDP vs qstats
Fix XDP_TX hangs and adjust the XDP statistics to match the definition
of qstats. The three problems are somewhat distinct.
XDP_TX hangs is a simple coding bug (patch 1).
The accounting of XDP packets is all over the place. Fix it to obey
qstat rules (packets seen by XDP always counted as Rx packets).
Patch 2 fixes the basic accounting, patch 3 touches up saving
the stats when rings are freed.
Patch 6 corrects reporting of alloc_fail stats which prevented
the pp_alloc_fail test from passing.
Patches 4, 5, 7, 8, 9 add or fix related test cases.
v2:
- [patch 2] remove now unnecessary byte adjustment
- [patch 8] use seen_fails more
v1: https://lore.kernel.org/20251003233025.1157158-1-kuba@kernel.org
Testing on fbnic below:
$ ./tools/testing/selftests/drivers/net/hw/pp_alloc_fail.py
TAP version 13
1..1
fbnic-err: bad MMIO read address 0x80074
fbnic-err: bad MMIO read address 0x80074
# Seen: pkts:20605 fails:40 (pass thrs:12)
# ethtool -G change retval: success
ok 1 pp_alloc_fail.test_pp_alloc
# Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0
$ ./tools/testing/selftests/drivers/net/xdp.py
TAP version 13
1..13
ok 1 xdp.test_xdp_native_pass_sb
ok 2 xdp.test_xdp_native_pass_mb
ok 3 xdp.test_xdp_native_drop_sb
ok 4 xdp.test_xdp_native_drop_mb
ok 5 xdp.test_xdp_native_tx_sb
ok 6 xdp.test_xdp_native_tx_mb
# Failed run: pkt_sz 2048, offset 1. Last successful run: pkt_sz 1024, offset 256. Reason: Adjustment failed
ok 7 xdp.test_xdp_native_adjst_tail_grow_data
ok 8 xdp.test_xdp_native_adjst_tail_shrnk_data
# Failed run: pkt_sz 512, offset -256. Last successful run: pkt_sz 512, offset -128. Reason: Adjustment failed
ok 9 xdp.test_xdp_native_adjst_head_grow_data
# Failed run: pkt_sz (2048) > HDS threshold (1536) and offset 64 > 48
ok 10 xdp.test_xdp_native_adjst_head_shrnk_data
ok 11 xdp.test_xdp_native_qstats_pass
ok 12 xdp.test_xdp_native_qstats_drop
ok 13 xdp.test_xdp_native_qstats_tx
# Totals: pass:13 fail:0 xfail:0 xpass:0 skip:0 error:0
====================
Link: https://patch.msgid.link/20251007232653.2099376-1-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add kernel config for error injection as needed by pp_alloc_fail.py
Reviewed-by: Simon Horman <horms@kernel.org>
Fixes: 9da271f825 ("selftests: drv-net-hw: add test for memory allocation failures with page pool")
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://patch.msgid.link/20251007232653.2099376-10-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Lower the expected level of traffic in the pp_alloc_fail test
and calculate failure counter thresholds based on the traffic
rather than using a fixed constant.
We only have "QEMU HW" in NIPA right now, and the test (due to
debug dependencies) only works on debug kernels in the first place.
We need some place for it to pass otherwise it seems to be bit
rotting. So lower the traffic threshold so that it passes on QEMU
and with a debug kernel...
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://patch.msgid.link/20251007232653.2099376-9-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Fix linter warnings, it's a bit hard to check for new ones otherwise.
W0311: Bad indentation. Found 16 spaces, expected 12 (bad-indentation)
C0114: Missing module docstring (missing-module-docstring)
W1514: Using open without explicitly specifying an encoding (unspecified-encoding)
C0116: Missing function or method docstring (missing-function-docstring)
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://patch.msgid.link/20251007232653.2099376-8-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Rx processing under normal circumstances has 3 rings - 2 buffer
rings (heads, payloads) and a completion ring. All the rings
have a struct fbnic_ring. Make sure we expose alloc_failed
counter from the buffer rings, previously only the alloc_failed
from the completion ring was reported, even tho all ring types
may increment this counter (buffer rings in __fbnic_fill_bdq()).
This makes the pp_alloc_fail.py test pass, it expects the qstat
to be incrementing as page pool injections happen.
Reviewed-by: Simon Horman <horms@kernel.org>
Fixes: 67dc4eb5fc ("eth: fbnic: report software Rx queue stats")
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://patch.msgid.link/20251007232653.2099376-7-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Send a non-trivial number of packets and make sure that they
are counted correctly in qstats. Per qstats specification
XDP is the first layer of the stack so we should see Rx and Tx
counters go up for packets which went thru XDP.
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://patch.msgid.link/20251007232653.2099376-6-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Test uses "netnl" for the ethtool family which is quite confusing
(one would expect netdev family would use this name).
No functional changes.
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://patch.msgid.link/20251007232653.2099376-5-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
When rings are freed - stats get added to the device level stat
structs. Save the stats from the XDP_TX ring just as Tx stats.
Previously they would be saved to Rx and Tx stats. So we'd not
see XDP_TX packets as Rx during runtime but after an down/up cycle
the packets would appear in stats.
Correct the helper used by ethtool code which does a runtime
config switch.
Reviewed-by: Simon Horman <horms@kernel.org>
Fixes: 5213ff0863 ("eth: fbnic: Collect packet statistics for XDP")
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://patch.msgid.link/20251007232653.2099376-4-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Make XDP-handled packets appear in the Rx stats. The driver has been
counting XDP_TX packets on the Tx ring, but there wasn't much accounting
on the Rx side (the Rx bytes appear to be incremented on XDP_TX but
XDP_DROP / XDP_ABORT are only counted as Rx drops).
Counting XDP_TX packets (not just bytes) in Rx stats looks like
a simple bug of omission.
The XDP_DROP handling appears to be intentional. Whether XDP_DROP
packets should be counted in interface-level Rx stats is a bit
unclear historically. When we were defining qstats, however,
we clarified based on operational experience that in this context:
name: rx-packets
doc: |
Number of wire packets successfully received and passed to the stack.
For drivers supporting XDP, XDP is considered the first layer
of the stack, so packets consumed by XDP are still counted here.
fbnic does not obey this requirement. Since XDP support has been added
in current release cycle, instead of splitting interface and qstat
handling - make them both follow the qstat definition.
Another small tweak here is that we count bytes as received on the wire
rather than post-XDP bytes (xdp_get_buff_len() vs skb->len).
Reviewed-by: Simon Horman <horms@kernel.org>
Fixes: 5213ff0863 ("eth: fbnic: Collect packet statistics for XDP")
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://patch.msgid.link/20251007232653.2099376-3-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
XDP_TX typically uses no offloads. To optimize XDP we added a "default
descriptor" feature to the chip, which allows us to send XDP frames with
just the buffer descriptors (DMA address + length). All the metadata
descriptors are derived from the queue config.
Commit under Fixes missed adding setting the defaults up when transplanting
the code from the prototype driver. Importantly after reset the "request
completion" bit is not set. Packets still get sent but there's no
completion, so ring is not cleaned up. We can send one ring's worth
of packets and then will start dropping all frames that got the XDP_TX
action from the XDP prog.
Reviewed-by: Simon Horman <horms@kernel.org>
Fixes: 168deb7b31 ("eth: fbnic: Add support for XDP_TX action")
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://patch.msgid.link/20251007232653.2099376-2-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
-----BEGIN PGP SIGNATURE-----
iQJBBAABCAArFiEEgKkgxbID4Gn1hq6fcJGo2a1f9gAFAmjmXroNHGZ3QHN0cmxl
bi5kZQAKCRBwkajZrV/2AEPmD/wJVaVNhEgmqY0abipD7Sx59ygRIVn6JSLGtimS
UO8G9S3cr3nT4i2wr1MYNiUQyjs18u4Q73kr8tKalXV99E05OVW1tWAeAztQDeZM
UNDf44Of1XwwlthIuQa7vyt4aqxmGhQDXKcj1cx2ZHjYQbJ3GshoMAZq90iKKqXN
Qlbpy216P71KzaN214bKDSgx8ffoWDRxcQwnbY4EWzMErKJqr5I6zLoJo9hMms0X
JpEqkUaY4PdackQJmBEoOaMphiG9H0u16PtEycfu++YrM/Xf5CJpiCFkp9mjZs+E
iNpLNF70phCA2ih3mwZFzfgPjYCXNSElOt0lGJFZVTVlGb8HLfBRNxKRMKsaCeZc
THZSPo2KMPI+UZle5Cyj9WNLWoVeTNtc2BlmMbSiTRRV5BWp1z20zgfymS++t0F7
hul2wWT7EH0cD87lJ/YUaGcM60nTZuNz7dKchTICwVyWpvCh0W/IhHM1JavfdPg2
gGCyPPsy1NKwXLCBym/DpKfIIwjR3bqH4s9miZRHt1a2PVX+JWxK72D0RasWPISz
cNs6bzQhfi6Q2l6gFJ8iGWWVr+L7J5+JmLdp8G4yQaJ+Fa7LggCIVMGOpl4QD7oA
lILvaXdfi402Oqkcho02gbtC0iDgVA8Grs28r/6KBsVFseejClvh7LQe9YLoFNZT
Fp7oAQ==
=u19C
-----END PGP SIGNATURE-----
Merge tag 'nf-25-10-08' of https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf
Florian Westphal says:
====================
netfilter: updates for net
The following patchset contains Netfilter fixes for *net*:
1) Fix crash (call recursion) when nftables synproxy extension is used
in an object map. When this feature was added in v5.4 the required
hook call validation was forgotten.
Fix from Fernando Fernandez Mancera.
2) bridge br_vlan_fill_forward_path_pvid uses incorrect
rcu_dereference_protected(); we only have rcu read lock but not
RTNL. Fix from Eric Woudstra.
Last two patches address flakes in two existing selftests.
netfilter pull request nf-25-10-08
* tag 'nf-25-10-08' of https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf:
selftests: netfilter: query conntrack state to check for port clash resolution
selftests: netfilter: nft_fib.sh: fix spurious test failures
bridge: br_vlan_fill_forward_path_pvid: use br_vlan_group_rcu()
netfilter: nft_objref: validate objref and objrefmap expressions
====================
Link: https://patch.msgid.link/20251008125942.25056-1-fw@strlen.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Move the ssize check to the start in essiv_aead_crypt so that
it's also checked for decryption and in-place encryption.
Reported-by: Muhammad Alifa Ramdhan <ramdhan@starlabs.sg>
Fixes: be1eb7f78a ("crypto: essiv - create wrapper template for ESSIV generation")
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Use a vblank timer to simulate the vblank interrupt. The DRM vblank
helpers provide an implementation on top of Linux' hrtimer. Virtgpu
enables and disables the timer as part of the CRTC. The atomic_flush
callback sets up the event. Like vblank interrupts, the vblank timer
fires at the rate of the display refresh.
Most userspace limits its page flip rate according to the DRM vblank
event. Virtgpu's virtual hardware does not provide vblank interrupts, so
DRM sends each event ASAP. With the fast access times of virtual display
memory, the event rate is much higher than the display mode's refresh
rate; creating the next page flip almost immediately. This leads to
excessive CPU overhead from even small display updates, such as moving
the mouse pointer.
This problem affects virtgpu and all other virtual displays. See [1] for
a discussion in the context of hypervdrm.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://lore.kernel.org/dri-devel/SN6PR02MB415702B00D6D52B0EE962C98D46CA@SN6PR02MB4157.namprd02.prod.outlook.com/ # [1]
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Link: https://lore.kernel.org/r/20251008130701.246988-1-tzimmermann@suse.de
Return value of function drm_crtc_init_with_planes(),
called by vgdev_output_init(), is not checked,
but it is usually checked for this function.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Alexandr Sapozhnikov <alsp705@gmail.com>
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
[dmitry.osipenko@collabora.com: coding style fix, edit commit message]
Link: https://lore.kernel.org/r/20250922144418.41-1-alsp705@gmail.com
- Extended 'perf annotate' with DWARF type information (--code-with-type)
integration in the TUI, including a 'T' hotkey to toggle it.
- Enhanced 'perf bench mem' with new mmap() workloads and control over
page/chunk sizes.
- Fix 'perf stat' error handling to correctly display unsupported events.
- Improved support for Clang cross-compilation.
- Refactored LLVM and Capstone disasm for modularity.
- Introduced the :X modifier to exclude an event from automatic regrouping.
- Adjusted KVM sampling defaults to use the "cycles" event to prevent failures.
- Added comprehensive support for decoding PowerPC Dispatch Trace Log (DTL).
- Updated Arm SPE tracing logic for better analysis of memory and snoop
details.
- Synchronized Intel PMU events and metrics with TMA 5.1 across multiple
processor generations.
- Converted dependencies like libperl and libtracefs to be opt-in.
- Handle more Rust symbols in kallsyms ('N', debugging).
- Improve the python binding to allow for python based tools to use more
of the libraries, add a 'ilist' utility to test those new bindings.
- Various 'perf test' fixes.
- Kan Liang no longer a perf tools reviewer.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQR2GiIUctdOfX2qHhGyPKLppCJ+JwUCaObIdAAKCRCyPKLppCJ+
JyM+AQCWCqdMdiOrJfsqwBAthJmLA2j+haprucR9b2XAi0CLTAD8DGaax3XQbIxM
3D6PUd6/qschIy0f77eYqCYjVQXJkQM=
=ibgu
-----END PGP SIGNATURE-----
Merge tag 'perf-tools-for-v6.18-1-2025-10-08' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools
Pull perf tools updates from Arnaldo Carvalho de Melo:
- Extended 'perf annotate' with DWARF type information
(--code-with-type) integration in the TUI, including a 'T'
hotkey to toggle it
- Enhanced 'perf bench mem' with new mmap() workloads and control
over page/chunk sizes
- Fix 'perf stat' error handling to correctly display unsupported
events
- Improved support for Clang cross-compilation
- Refactored LLVM and Capstone disasm for modularity
- Introduced the :X modifier to exclude an event from automatic
regrouping
- Adjusted KVM sampling defaults to use the "cycles" event to prevent
failures
- Added comprehensive support for decoding PowerPC Dispatch Trace Log
(DTL)
- Updated Arm SPE tracing logic for better analysis of memory and snoop
details
- Synchronized Intel PMU events and metrics with TMA 5.1 across
multiple processor generations
- Converted dependencies like libperl and libtracefs to be opt-in
- Handle more Rust symbols in kallsyms ('N', debugging)
- Improve the python binding to allow for python based tools to use
more of the libraries, add a 'ilist' utility to test those new
bindings
- Various 'perf test' fixes
- Kan Liang no longer a perf tools reviewer
* tag 'perf-tools-for-v6.18-1-2025-10-08' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools: (192 commits)
perf tools: Fix arm64 libjvmti build by generating unistd_64.h
perf tests: Don't retest sections in "Object code reading"
perf docs: Document building with Clang
perf build: Support build with clang
perf test coresight: Dismiss clang warning for unroll loop thread
perf test coresight: Dismiss clang warning for thread loop
perf test coresight: Dismiss clang warning for memcpy thread
perf build: Disable thread safety analysis for perl header
perf build: Correct CROSS_ARCH for clang
perf python: split Clang options when invoking Popen
tools build: Align warning options with perf
perf disasm: Remove unused evsel from 'struct annotate_args'
perf srcline: Fallback between addr2line implementations
perf disasm: Make ins__scnprintf() and ins__is_nop() static
perf dso: Clean up read_symbol() error handling
perf dso: Support BPF programs in dso__read_symbol()
perf dso: Move read_symbol() from llvm/capstone to dso
perf llvm: Reduce LLVM initialization
perf check: Add libLLVM feature
perf parse-events: Fix parsing of >30kb event strings
...
It was reported that using __copy_from_user_inatomic() can actually
schedule. Which is bad when preemption is disabled. Even though there's
logic to check in_atomic() is set, but this is a nop when the kernel is
configured with PREEMPT_NONE. This is due to page faulting and the code
could schedule with preemption disabled.
Link: https://lore.kernel.org/all/20250819105152.2766363-1-luogengkun@huaweicloud.com/
The solution was to change the __copy_from_user_inatomic() to
copy_from_user_nofault(). But then it was reported that this caused a
regression in Android. There's several applications writing into
trace_marker() in Android, but now instead of showing the expected data,
it is showing:
tracing_mark_write: <faulted>
After reverting the conversion to copy_from_user_nofault(), Android was
able to get the data again.
Writes to the trace_marker is a way to efficiently and quickly enter data
into the Linux tracing buffer. It takes no locks and was designed to be as
non-intrusive as possible. This means it cannot allocate memory, and must
use pre-allocated data.
A method that is actively being worked on to have faultable system call
tracepoints read user space data is to allocate per CPU buffers, and use
them in the callback. The method uses a technique similar to seqcount.
That is something like this:
preempt_disable();
cpu = smp_processor_id();
buffer = this_cpu_ptr(&pre_allocated_cpu_buffers, cpu);
do {
cnt = nr_context_switches_cpu(cpu);
migrate_disable();
preempt_enable();
ret = copy_from_user(buffer, ptr, size);
preempt_disable();
migrate_enable();
} while (!ret && cnt != nr_context_switches_cpu(cpu));
if (!ret)
ring_buffer_write(buffer);
preempt_enable();
It's a little more involved than that, but the above is the basic logic.
The idea is to acquire the current CPU buffer, disable migration, and then
enable preemption. At this moment, it can safely use copy_from_user().
After reading the data from user space, it disables preemption again. It
then checks to see if there was any new scheduling on this CPU. If there
was, it must assume that the buffer was corrupted by another task. If
there wasn't, then the buffer is still valid as only tasks in preemptable
context can write to this buffer and only those that are running on the
CPU.
By using this method, where trace_marker open allocates the per CPU
buffers, trace_marker writes can access user space and even fault it in,
without having to allocate or take any locks of its own.
Cc: stable@vger.kernel.org
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Luo Gengkun <luogengkun@huaweicloud.com>
Cc: Wattson CI <wattson-external@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://lore.kernel.org/20251008124510.6dba541a@gandalf.local.home
Fixes: 3d62ab32df ("tracing: Fix tracing_marker may trigger page fault during preempt_disable")
Reported-by: Runping Lai <runpinglai@google.com>
Tested-by: Runping Lai <runpinglai@google.com>
Closes: https://lore.kernel.org/linux-trace-kernel/20251007003417.3470979-2-runpinglai@google.com/
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
This patch adds information about Ceph bug tracking system.
[ idryomov: add the same for RBD, don't mention include/linux/ceph/
again ]
Signed-off-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
The refactoring in 4292a1e45f ("PCI: Refactor distributing available
memory to use loops") switched pci_bus_distribute_available_resources() to
operate on an array of bridge windows. That accidentally looked up bus
resources via pci_bus_resource_n() and then passed those pointers to helper
routines that expect the resource to belong to the device. As soon as we
execute that code, pci_resource_num() warned because the resource wasn't in
the bridge's resource array.
This happens on my AMD Strix Halo machine with Thunderbolt device; the
error message is shown below:
WARNING: CPU: 6 PID: 272 at drivers/pci/pci.h:471 pci_bus_distribute_available_resources+0x6ad/0x6d0
CPU: 6 UID: 0 PID: 272 Comm: irq/33-pciehp Not tainted 6.17.0+ #1 PREEMPT(voluntary)
Hardware name: PELADN YO Series/YO1, BIOS 1.04 05/15/2025
RIP: 0010:pci_bus_distribute_available_resources+0x6ad/0x6d0
Call Trace:
pci_bus_distribute_available_resources+0x590/0x6d0
pci_bridge_distribute_available_resources+0x62/0xb0
pci_assign_unassigned_bridge_resources+0x65/0x1b0
pciehp_configure_device+0x92/0x160
pciehp_handle_presence_or_link_change+0x1b5/0x350
pciehp_ist+0x147/0x1c0
Fix the regression by always fetching the resource directly from the bridge
with pci_resource_n(bridge, PCI_BRIDGE_RESOURCES + i). This restores the
original behaviour while keeping the refactored structure. Then we can
successfully assign resources to the Thunderbolt device.
Fixes: 4292a1e45f ("PCI: Refactor distributing available memory to use loops")
Reported-by: Kenneth R. Crudup <kenny@panix.com>
Closes: https://lore.kernel.org/r/dd551b81-9e81-480b-aab3-7cf8b8bbc1d0@panix.com
Signed-off-by: Yangyu Chen <cyy@cyyself.name>
[bhelgaas: trim timestamps, etc from commit log]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-By: Kenneth R. Crudup <kenny@panix.com>
Link: https://lore.kernel.org/r/F833CC81-7C60-48FC-A31C-B9999DCC6FA2@icloud.com
Link: https://patch.msgid.link/tencent_8C54420E1B0FF8D804C1B4651DF970716309@qq.com
The mds auth caps check should also validate the
fsname along with the associated caps. Not doing
so would result in applying the mds auth caps of
one fs on to the other fs in a multifs ceph cluster.
The bug causes multiple issues w.r.t user
authentication, following is one such example.
Steps to Reproduce (on vstart cluster):
1. Create two file systems in a cluster, say 'fsname1' and 'fsname2'
2. Authorize read only permission to the user 'client.usr' on fs 'fsname1'
$ceph fs authorize fsname1 client.usr / r
3. Authorize read and write permission to the same user 'client.usr' on fs 'fsname2'
$ceph fs authorize fsname2 client.usr / rw
4. Update the keyring
$ceph auth get client.usr >> ./keyring
With above permssions for the user 'client.usr', following is the
expectation.
a. The 'client.usr' should be able to only read the contents
and not allowed to create or delete files on file system 'fsname1'.
b. The 'client.usr' should be able to read/write on file system 'fsname2'.
But, with this bug, the 'client.usr' is allowed to read/write on file
system 'fsname1'. See below.
5. Mount the file system 'fsname1' with the user 'client.usr'
$sudo bin/mount.ceph usr@.fsname1=/ /kmnt_fsname1_usr/
6. Try creating a file on file system 'fsname1' with user 'client.usr'. This
should fail but passes with this bug.
$touch /kmnt_fsname1_usr/file1
7. Mount the file system 'fsname1' with the user 'client.admin' and create a
file.
$sudo bin/mount.ceph admin@.fsname1=/ /kmnt_fsname1_admin
$echo "data" > /kmnt_fsname1_admin/admin_file1
8. Try removing an existing file on file system 'fsname1' with the user
'client.usr'. This shoudn't succeed but succeeds with the bug.
$rm -f /kmnt_fsname1_usr/admin_file1
For more information, please take a look at the corresponding mds/fuse patch
and tests added by looking into the tracker mentioned below.
v2: Fix a possible null dereference in doutc
v3: Don't store fsname from mdsmap, validate against
ceph_mount_options's fsname and use it
v4: Code refactor, better warning message and
fix possible compiler warning
[ Slava.Dubeyko: "fsname check failed" -> "fsname mismatch" ]
Link: https://tracker.ceph.com/issues/72167
Signed-off-by: Kotresh HR <khiremat@redhat.com>
Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
The Coverity Scan service has reported potential issue
in ceph_alloc_readdir_reply_buffer() [1]. If order could
be negative one, then it expects the issue in the logic:
num_entries = (PAGE_SIZE << order) / size;
Technically speaking, this logic [2] should prevent from
making the order variable negative:
if (!rinfo->dir_entries)
return -ENOMEM;
However, the allocation logic requires some cleanup.
This patch makes sure that calculated bytes count
will never exceed ULONG_MAX before get_order()
calculation. And it adds the checking of order
variable on negative value to guarantee that second
half of the function's code will never operate by
negative value of order variable even if something
will be wrong or to be changed in the first half of
the function's logic.
v2
Alex Markuze suggested to add unlikely() macro
for introduced condition checks.
[1] https://scan5.scan.coverity.com/#/project-view/64304/10063?selectedIssue=1198252
[2] https://elixir.bootlin.com/linux/v6.17-rc3/source/fs/ceph/mds_client.c#L2553
Signed-off-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
Reviewed-by: Alex Markuze <amarkuze@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
The Coverity Scan service has detected a potential dereference of
an explicit NULL value in ceph_fill_trace() [1].
The variable in is declared in the beggining of
ceph_fill_trace() [2]:
struct inode *in = NULL;
However, the initialization of the variable is happening under
condition [3]:
if (rinfo->head->is_target) {
<skipped>
in = req->r_target_inode;
<skipped>
}
Potentially, if rinfo->head->is_target == FALSE, then
in variable continues to be NULL and later the dereference of
NULL value could happen in ceph_fill_trace() logic [4,5]:
else if ((req->r_op == CEPH_MDS_OP_LOOKUPSNAP ||
req->r_op == CEPH_MDS_OP_MKSNAP) &&
test_bit(CEPH_MDS_R_PARENT_LOCKED, &req->r_req_flags) &&
!test_bit(CEPH_MDS_R_ABORTED, &req->r_req_flags)) {
<skipped>
ihold(in);
err = splice_dentry(&req->r_dentry, in);
if (err < 0)
goto done;
}
This patch adds the checking of in variable for NULL value
and it returns -EINVAL error code if it has NULL value.
v2
Alex Markuze suggested to add unlikely macro
in the checking condition.
[1] https://scan5.scan.coverity.com/#/project-view/64304/10063?selectedIssue=1141197
[2] https://elixir.bootlin.com/linux/v6.17-rc3/source/fs/ceph/inode.c#L1522
[3] https://elixir.bootlin.com/linux/v6.17-rc3/source/fs/ceph/inode.c#L1629
[4] https://elixir.bootlin.com/linux/v6.17-rc3/source/fs/ceph/inode.c#L1745
[5] https://elixir.bootlin.com/linux/v6.17-rc3/source/fs/ceph/inode.c#L1777
Signed-off-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
Reviewed-by: Alex Markuze <amarkuze@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
This moves the list_empty() checks from the two callers (v1 and v2)
into the base messenger.c library. Now the v1/v2 specializations do
not need to know about con->out_queue; that implementation detail is
now hidden behind the ceph_con_get_out_msg() function.
[ idryomov: instead of changing prepare_write_message() to return
a bool, move ceph_con_get_out_msg() call out to arrive to the same
pattern as in messenger_v2.c ]
Signed-off-by: Max Kellermann <max.kellermann@ionos.com>
Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
This pointer is in a register anyway, so let's use that instead of
reloading from memory everywhere.
[ idryomov: formatting ]
Signed-off-by: Max Kellermann <max.kellermann@ionos.com>
Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
The caller in messenger_v1.c loads it anyway, so let's keep the
pointer in the register instead of reloading it from memory. This
eliminates a tiny bit of unnecessary overhead.
Signed-off-by: Max Kellermann <max.kellermann@ionos.com>
Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
The Coverity Scan service has detected potential
race conditions in ceph_block_o_direct(), ceph_start_io_read(),
ceph_block_buffered(), and ceph_start_io_direct() [1 - 4].
The CID 1590942, 1590665, 1589664, 1590377 contain explanation:
"The value of the shared data will be determined by
the interleaving of thread execution. Thread shared data is accessed
without holding an appropriate lock, possibly causing
a race condition (CWE-366)".
This patch reworks the pattern of accessing/modification of
CEPH_I_ODIRECT flag by means of adding smp_mb__before_atomic()
before reading the status of CEPH_I_ODIRECT flag and
smp_mb__after_atomic() after clearing set/clear this flag.
Also, it was reworked the pattern of using of ci->i_ceph_lock
in ceph_block_o_direct(), ceph_start_io_read(),
ceph_block_buffered(), and ceph_start_io_direct() methods.
[1] https://scan5.scan.coverity.com/#/project-view/64304/10063?selectedIssue=1590942
[2] https://scan5.scan.coverity.com/#/project-view/64304/10063?selectedIssue=1590665
[3] https://scan5.scan.coverity.com/#/project-view/64304/10063?selectedIssue=1589664
[4] https://scan5.scan.coverity.com/#/project-view/64304/10063?selectedIssue=1590377
Signed-off-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
Reviewed-by: Alex Markuze <amarkuze@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
The wake_up_bit() is called in ceph_async_unlink_cb(),
wake_async_create_waiters(), and ceph_finish_async_create().
It makes sense to switch on clear_bit() function, because
it makes the code much cleaner and easier to understand.
More important rework is the adding of smp_mb__after_atomic()
memory barrier after the bit modification and before
wake_up_bit() call. It can prevent potential race condition
of accessing the modified bit in other threads. Luckily,
clear_and_wake_up_bit() already implements the required
functionality pattern:
static inline void clear_and_wake_up_bit(int bit, unsigned long *word)
{
clear_bit_unlock(bit, word);
/* See wake_up_bit() for which memory barrier you need to use. */
smp_mb__after_atomic();
wake_up_bit(word, bit);
}
Signed-off-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
Reviewed-by: Alex Markuze <amarkuze@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
The Coverity Scan service has detected potential
race condition in ceph_ioctl_lazyio() [1].
The CID 1591046 contains explanation: "Check of thread-shared
field evades lock acquisition (LOCK_EVASION). Thread1 sets
fmode to a new value. Now the two threads have an inconsistent
view of fmode and updates to fields correlated with fmode
may be lost. The data guarded by this critical section may
be read while in an inconsistent state or modified by multiple
racing threads. In ceph_ioctl_lazyio: Checking the value of
a thread-shared field outside of a locked region to determine
if a locked operation involving that thread shared field
has completed. (CWE-543)".
The patch places fi->fmode field access under ci->i_ceph_lock
protection. Also, it introduces the is_file_already_lazy
variable that is set under the lock and it is checked later
out of scope of critical section.
[1] https://scan5.scan.coverity.com/#/project-view/64304/10063?selectedIssue=1591046
Signed-off-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
Reviewed-by: Alex Markuze <amarkuze@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
The Coverity Scan service has detected overflowed constant
issue in ceph_do_objects_copy() [1]. The CID 1624308
defect contains explanation: "The overflowed value due to
arithmetic on constants is too small or unexpectedly
negative, causing incorrect computations. Expression bytes,
which is equal to -95, where ret is known to be equal to -95,
underflows the type that receives it, an unsigned integer
64 bits wide. In ceph_do_objects_copy: Integer overflow occurs
in arithmetic on constant operands (CWE-190)".
The patch changes the type of bytes variable from size_t
to ssize_t with the goal of to be capable to receive
negative values.
[1] https://scan5.scan.coverity.com/#/project-view/64304/10063?selectedIssue=1624308
Signed-off-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
Reviewed-by: Alex Markuze <amarkuze@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
The Coverity Scan service has detected the wrong sizeof
argument in register_session() [1]. The CID 1598909 defect
contains explanation: "The wrong sizeof value is used in
an expression or as argument to a function. The result is
an incorrect value that may cause unexpected program behaviors.
In register_session: The sizeof operator is invoked on
the wrong argument (CWE-569)".
The patch introduces a ptr_size variable that is initialized
by sizeof(struct ceph_mds_session *). And this variable is used
instead of sizeof(void *) in the code.
[1] https://scan5.scan.coverity.com/#/project-view/64304/10063?selectedIssue=1598909
Signed-off-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
Reviewed-by: Alex Markuze <amarkuze@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
The Coverity Scan service has detected the calling of
wait_for_completion_killable() without checking the return
value in ceph_lock_wait_for_completion() [1]. The CID 1636232
defect contains explanation: "If the function returns an error
value, the error value may be mistaken for a normal value.
In ceph_lock_wait_for_completion(): Value returned from
a function is not checked for errors before being used. (CWE-252)".
The patch adds the checking of wait_for_completion_killable()
return value and return the error code from
ceph_lock_wait_for_completion().
[1] https://scan5.scan.coverity.com/#/project-view/64304/10063?selectedIssue=1636232
Signed-off-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
Reviewed-by: Alex Markuze <amarkuze@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
This allows killing processes that wait for a lock when one process is
stuck waiting for the Ceph server. This is similar to the NFS commit
38a125b315 ("fs/nfs/io: make nfs_start_io_*() killable").
[ idryomov: drop comment on include, formatting ]
Signed-off-by: Max Kellermann <max.kellermann@ionos.com>
Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Use the HMAC-SHA256 library functions instead of crypto_shash. This is
simpler and faster.
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
- Optimizations for DMA map and unmap opertions through the type1
vfio IOMMU backend. This uses various means of batching and hints
from the mm structures to improve efficiency and therefore
performance, resulting in a significant speedup for huge page
use cases. (Li Zhe)
- Expose supported device migration features through debugfs.
(Cédric Le Goater)
-----BEGIN PGP SIGNATURE-----
iQJPBAABCAA5FiEEQvbATlQL0amee4qQI5ubbjuwiyIFAmjmgowbHGFsZXgud2ls
bGlhbXNvbkByZWRoYXQuY29tAAoJECObm247sIsiUUAQAJyY7ykBiqbCJjflw3/P
ZdE8hZZDx3vyuq7OY/JLjM0BQllSiBuJbOsB2EM5j8qr5K4Al9SrXBZ7crSyfqjN
+/d/WI7/ndNapUT0+Q4zcb1W6bu/o1YnaklTpl+UV6zeX5ZjvgdVmKY0Ox+GKgqB
oGcfMCK6+dSBUP7I27dpRBBcNs8NLA9lPNtqB8YC7GhXbfmhioXb//Ucpb570M40
P20KnCnZywq/7AcEE2TcLWkMgUEMsPpPVH1IK0K+XtP2awrpxJ4/HY4G86UOMvPS
DlH+yqqQSCze5etvvTS8Sao6G1SeuQL+wgUE0PYxgnZOO1nQ3L2Pw868gfFXKTrb
N6uFKY2Gz6WMJWygDjv4RthKnQ7ChZmL7JjcL9W7/0mVZChVCVEGpZn2EiLUSk8Q
gvNO2paKZeWO9jzLIqOE9/suNagDytV0Lu/AkHg7XZdiu86aI+lkmLgfj48e4ZXK
KspNnUOJzRlJrHsHtIOhptBVjGd6Qn2dDW+HFtdEdSaDMvbA76QQQL+lQ8IwwvNy
KVaknhqHrtXGo5yiIefDNV3333mfy65jIoFaLWozAjeX4U+FmuHPdD+uwgvB84T6
3MkIPy27wuQtIO96r/UGR87smm3scFErK2IjHTGxFU2r9Mh42oVt9ahIJN34he1b
x5UCfKCtx59o7fZRJgGPlFUT
=nPnW
-----END PGP SIGNATURE-----
Merge tag 'vfio-v6.18-rc1-pt2' of https://github.com/awilliam/linux-vfio
Pull more VFIO updates from Alex Williamson:
- Optimizations for DMA map and unmap opertions through the type1 vfio
IOMMU backend.
This uses various means of batching and hints from the mm structures
to improve efficiency and therefore performance, resulting in a
significant speedup for huge page use cases (Li Zhe)
- Expose supported device migration features through debugfs (Cédric Le
Goater)
* tag 'vfio-v6.18-rc1-pt2' of https://github.com/awilliam/linux-vfio:
vfio: Dump migration features under debugfs
vfio/type1: optimize vfio_unpin_pages_remote()
vfio/type1: introduce a new member has_rsvd for struct vfio_dma
vfio/type1: batch vfio_find_vpfn() in function vfio_unpin_pages_remote()
vfio/type1: optimize vfio_pin_pages_remote()
mm: introduce num_pages_contiguous()
- a number of conversions to yaml/json schema and fixes for
input-related device tree bindings
- a new driver for Awinic AW86927 haptic chip
- a new driver for Hynitron CST816x series controller
- a new driver for add Himax HX852x(ES) touchscreen controller
- a fix to uinput to not leak kernel memory via a gap in
uinput_ff_upload_compat structure
- a fix to prevent overflow in pressure calculation in tsc2007 driver
causing phantom touches
- a change to Atmel maxTouch driver to support generic touchscreen
configuration (flip, rotate, etc.)
- support for platform data was dropped in tca8418_keypad,
pxa27x-keypad, spear-keyboard and twl4030_keypad drivers, they all
now rely on generic device properties for configuration
- other assorted changes and fixes.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQST2eWILY88ieB2DOtAj56VGEWXnAUCaOX1HQAKCRBAj56VGEWX
nC29AQCsDm6HBKXJZl6nAI8WHQiSvASFvyFlF6scVnfueX54mQEA6eE428+Cr1Sn
mDiwL38Es+PlZbdsi0J2q0vYzpr4yQU=
=JZIn
-----END PGP SIGNATURE-----
Merge tag 'input-for-v6.18-rc0' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
Pull input updates from Dmitry Torokhov:
- Conversions to yaml/json schema and fixes for input-related device
tree bindings
- New drivers:
- Awinic AW86927 haptic chip
- Hynitron CST816x series controller
- Himax HX852x(ES) touchscreen controller
- Fix uinput to not leak kernel memory via a gap in
uinput_ff_upload_compat structure
- Prevent overflow in pressure calculation in tsc2007 driver causing
phantom touches
- Make the Atmel maxTouch driver support generic touchscreen
configuration (flip, rotate, etc)
- Drop support for platform data in tca8418_keypad, pxa27x-keypad,
spear-keyboard and twl4030_keypad drivers, they all now rely on
generic device properties for configuration
- Other assorted changes and fixes
* tag 'input-for-v6.18-rc0' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: (50 commits)
Input: atmel_mxt_ts - allow reset GPIO to sleep
Input: aw86927 - fix error code in probe()
Input: psxpad-spi - add a check for the return value of spi_setup()
Input: uinput - zero-initialize uinput_ff_upload_compat to avoid info leak
Input: aw86927 - add driver for Awinic AW86927
dt-bindings: input: Add Awinic AW86927
dt-bindings: touchscreen: remove touchscreen.txt
dt-bindings: arm: bcm: raspberrypi,bcm2835-firmware: Add touchscreen child node
dt-bindings: touchscreen: convert eeti bindings to json schema
Input: pm8941-pwrkey - disable wakeup for resin by default
dt-bindings: input: pm8941-pwrkey: Document wakeup-source property
Input: add driver for Hynitron CST816x series
dt-bindings: input: touchscreen: add hynitron cst816x series
Input: imx6ul_tsc - set glitch threshold by DTS property
dt-bindings: touchscreen: fsl,imx6ul-tsc: support glitch thresold
dt-bindings: touchscreen: add debounce-delay-us property
Input: ps2-gpio - fix typo
Input: atmel_mxt_ts - add support for generic touchscreen configurations
dt-bindings: input: maxtouch: add common touchscreen properties
dt-bindings: touchscreen: convert zet6223 bindings to json schema
...
- Fix zstd regression.
- Ensure ti driver algorithm are set as async.
- Revert patch disabling SHA1 in FIPS mode.
- Fix RNG set_ent null-pointer dereference.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEn51F/lCuNhUwmDeSxycdCkmxi6cFAmjjJ2oACgkQxycdCkmx
i6fU6g//Ytvo52VNiaQneYadbikIh6NrqeA4ykjic4LllcqaWdH4hOLeBWS0srR3
SgjgCnmuchTzlzDMvAlYZn3o7owpe0GvS2Mil7orS00N58gU6h/TqiE2V6UUqjKN
MNdNEtHD7QhHAamunXMG7NRGyT/mLeSA6fmiW5jrlBeQpw2D+Aso54clxHeKHDkZ
Rrx4qbmhjZQyahp2CmO+rmTA9W/xpnsGrWDmbLvRk6eTrSonRu43IbKngyYdnOZr
mAeWvABi2Izq/VyVoEpLPTzEiHvF9dX1yMm2njFe0Q09OkVGNeTd0zuevH0kayb6
KmevkHJ8mxLs8Q5R8tSUzR265DLzQ0SrghDNB3gDPLBcO5tsg2CBLMOMup0LjY7E
uvglFKFc0VQYximaz41aWW3+luikAwW0LJr1bchKaVes41hcHLu/77FJ9A3ANObe
x/dZ46CQ2w2B8DIavQcKAM/uKpkL8bk50QRuLQq20ZElbv4RYjmA3GE2QZyZ6alm
kJ5a7RNnujKAsxhp/xg3nBWVtgCeE8hEec4Piwue23+qpAS5KW7WMK8GW6EW9FMs
xxmAQFvXk4rfmKlQX1EMt601QZx0TA3yBDu/aTneL+mS4+dlB3H9JqFw4LuhKjGS
RcpXv2wz/baBxeKE/knSe+RUCEtgTYrTSSlv2ZP+3toOwMNKgO0=
=IFdl
-----END PGP SIGNATURE-----
Merge tag 'v6.18-p2' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
Pull crypto fixes from Herbert Xu:
- Fix zstd regression
- Ensure ti driver algorithm are set as async
- Revert patch disabling SHA1 in FIPS mode
- Fix RNG set_ent null-pointer dereference
* tag 'v6.18-p2' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
crypto: rng - Ensure set_ent is always present
Revert "crypto: testmgr - desupport SHA-1 for FIPS 140"
crypto: ti - Add CRYPTO_ALG_ASYNC flag to DTHEv2 AES algos
crypto: zstd - Fix compression bug caused by truncation
