summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-06-05MAINTAINERS: BPF: Add self as reviewer and run parse_maintainers.plEmil Tsalapatis
Add myself as a reviewer for the BPF subsystem. While at it, run ./scripts/parse_maintainers.pl --order and reorder the BPF-related entries in the file accordingly. Signed-off-by: Emil Tsalapatis <emil@etsalapatis.com> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Acked-by: Jiri Olsa <jolsa@kernel.org> Link: https://lore.kernel.org/r/20260604184252.9917-1-emil@etsalapatis.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-06-05Merge branch 'bpf-introduce-resizable-hash-map'Alexei Starovoitov
Mykyta Yatsenko says: ==================== bpf: Introduce resizable hash map This patch series introduces BPF_MAP_TYPE_RHASH, a new hash map type that leverages the kernel's rhashtable to provide resizable hash map for BPF. The existing BPF_MAP_TYPE_HASH uses a fixed number of buckets determined at map creation time. While this works well for many use cases, it presents challenges when: 1. The number of elements is unknown at creation time 2. The element count varies significantly during runtime 3. Memory efficiency is important (over-provisioning wastes memory, under-provisioning hurts performance) BPF_MAP_TYPE_RHASH addresses these issues by using rhashtable, which automatically grows and shrinks based on load factor. The implementation wraps the kernel's rhashtable with BPF map operations: - Uses bpf_mem_alloc for RCU-safe memory management - Supports all standard map operations (lookup, update, delete, get_next_key) - Supports batch operations (lookup_batch, lookup_and_delete_batch) - Supports BPF iterators for traversal - Supports BPF_F_LOCK for spin locks in values - Requires BPF_F_NO_PREALLOC flag (elements allocated on demand) - In-place updates for improved performance. - max_entries serves as a hard limit, not bucket count - Uses bit_spin_lock() + local_irq_save() for bucket locking, similar to existing BPF hashmap's raw_spin_lock_irqsave(), insertions and deletes may fail. - Iterations are best-effort, if resize, insertions, deletions take place concurrently, iterations may visit same elements multiple times or skip elements. - Lock out insertions, when running special fields destructor to guarantee its completion. The series includes comprehensive tests: - Basic operations in test_maps (lookup, update, delete, get_next_key) - BPF program tests for lookup/update/delete semantics - Seq file tests Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com> --- Update implementation --------------------- Current implementation of the BPF_MAP_TYPE_RHASH does not provide the same strong guarantees on the values consistency under concurrent reads/writes as BPF_MAP_TYPE_HASH. BPF_MAP_TYPE_HASH allocates a new element and atomically swaps the pointer. BPF_MAP_TYPE_RHASH does memcpy in place with no lock held. rhash trades consistency for speed, concurrent readers can observe partially updated data. Two concurrent writers to the same key can also interleave, producing mixed values. This is similar to arraymap update implementation, including handling of the special fields. As a solution, user may use BPF_F_LOCK to guarantee consistent reads and write serialization. Summary of the read consistency guarantees: map type | write mechanism | read consistency -------------+------------------+-------------------------- htab | alloc, swap ptr | always consistent (RCU) htab F_LOCK | in-place + lock | consistent if reader locks -------------+------------------+-------------------------- rhtab | in-place memcpy | torn reads rhtab F_LOCK | in-place + lock | consistent if reader locks Benchmarks ---------- 1. LOOKUP (single producer, M events/sec) key | max | nr | htab | rhtab | ratio | delta ----+-----+-------+---------+---------+-------+------- 8 | 1K | 750 | 99.85 | 81.92 | 0.82x | -18 % 8 | 1K | 1K | 100.71 | 80.19 | 0.80x | -20 % 8 | 1M | 750K | 23.37 | 72.09 | 3.08x | +208 % 8 | 1M | 1M | 13.39 | 53.72 | 4.01x | +301 % 32 | 1K | 750 | 51.57 | 42.78 | 0.83x | -17 % 32 | 1K | 1K | 50.81 | 45.83 | 0.90x | -10 % 32 | 1M | 750K | 11.27 | 15.29 | 1.36x | +36 % 32 | 1M | 1M | 7.32 | 8.75 | 1.19x | +19 % 256 | 1K | 750 | 7.58 | 7.88 | 1.04x | +4 % 256 | 1K | 1K | 7.43 | 7.81 | 1.05x | +5 % 256 | 1M | 750K | 3.69 | 4.27 | 1.16x | +16 % 256 | 1M | 1M | 2.60 | 3.12 | 1.20x | +20 % Pattern: * Small map (1K): htab wins for 8 / 32 byte keys by 10-20 % because the preallocated bucket array fits in L1. Equalises at 256 byte keys. * Large map (1M): rhtab wins everywhere, up to 4x at high load factor with 8 byte keys. * Higher load factor amplifies rhtab's lead: rhtab grows the bucket array; htab stays at user-declared max. 2. FULL UPDATE (M events/sec per producer, -p 7) htab per-producer: 20.33 22.02 19.27 23.61 24.18 23.17 21.07 mean 21.94 range 19.27 - 24.18 rhtab per-producer: 133.51 129.47 74.52 129.29 102.26 129.98 107.64 mean 115.24 range 74.52 - 133.51 speedup (mean): 5.25x (+425 %) In-place memcpy avoids the per-update alloc + RCU pointer swap that htab pays. 3. MEMORY (overwrite, -p 8, no --preallocated) value_size | htab ops/s | rhtab ops/s | htab mem | rhtab mem -----------+-------------+-------------+----------+---------- 32 B | 122.87 k/s | 133.04 k/s | 2.47 MiB | 2.49 MiB 4096 B | 64.43 k/s | 65.38 k/s | 6.74 MiB | 6.44 MiB rhtab/htab : +8 % ops, +0.8 % mem (32 B) +1 % ops, -4 % mem (4096 B) SUMMARY * Small / well-fitting map: htab is faster (cache-friendly fixed bucket array), but only by ~10-20 %. * Large / high-load-factor map: rhtab is dramatically faster (1.2x to 4x) because rhashtable resizes to keep the load factor sane while htab stays stuck at user-declared max. * Update-heavy workloads: rhtab is ~5x faster per producer via in-place memcpy. * Memory benchmark: effectively on par --- Changes in v7: - rhashtable_next_key: move into lib/rhashtable.c, drop params argument (Herbert). - rhashtable_next_key: kdoc clarifies that behavior on tables with duplicate keys is undefined (sashiko). - rhashtable: include Herbert's "Use irq work for shrinking" patch so __rhashtable_remove_fast_one() can fire the shrink path from NMI context (Herbert). - hashtab: fix u32 multiply overflow in __rhtab_map_lookup_and_delete_batch copy_to_user; cast total to size_t before multiplying by key_size / value_size (sashiko, bot+bpf-ci). - hashtab: allow kptr/refcount fields in rhtab values (same model as array map). - Link to v6: https://patch.msgid.link/20260602-rhash-v6-0-1bfd35a4184f@meta.com Changes in v6: - rhashtable_next_key: advance past duplicate keys in the main bucket chain to avoid an infinite loop when there are duplicate keys (sashiko). - rhashtable_next_key: return ERR_PTR(-EOPNOTSUPP) on rhltable (sashiko). - rhashtable: selftest pre-sizes the table to avoid concurrent rehash triggering spurious failures (sashiko). - hashtab: real rhtab_map_mem_usage in the basic commit; move bpf_map_free_internal_structs from rhtab_free_elem into the special-fields commit where it does meaningful work (bot+bpf-ci). - bpf_iter (seq_file): switch to rhashtable_walk_* for stronger coverage under concurrent rehash; get_next_key and batch keep rhashtable_next_key (sashiko). - iter ops: rhtab_map_get_next_key adds IS_ERR check before dereferencing the element pointer (sashiko). - iter ops: bpf_each_rhash_elem removes cond_resched() (sashiko). - iter ops: batch returns -EAGAIN (not -ENOENT) on cursor delete, so userspace can distinguish lost cursor from end-of-iteration and restart from NULL (sashiko). - Link to v5: https://patch.msgid.link/20260528-rhash-v5-0-7205191b6c57@meta.com Changes in v5: - rhashtable_next_key: add kdoc WARNING to highlight lack of rehash detection and unbounded iteration (Herbert). - rhashtable: selftest now checks IS_ERR() before PTR_ERR comparison on the missing-key path (bot+bpf-ci). - hashtab: drop dead stub bodies and unused map_ops registrations from the basic commit; iteration commit adds bodies, structs, and registrations together. .map_get_next_key keeps a stub registration in the basic commit because the syscall dispatcher does not NULL-check it; iteration commit replaces the stub body with the real implementation (bot+bpf-ci). - hashtab: fix batch cursor advancement. v4 stashed the lookahead element key but then resumed via next_key(cursor), skipping that element across batch boundaries and orphaning it on lookup_and_delete_batch. v5 stashes the lookahead key and looks it up directly on the next batch entry (bot+bpf-ci, sashiko v3). - hashtab: document torn-read race in rhtab_map_update_existing, matching arraymap semantics (bot+bpf-ci). - Link to v4: https://patch.msgid.link/20260513-rhash-v4-0-dd3d541ccb0b@meta.com Changes in v4: - rhashtable: introduce rhashtable_next_key(), drop walker-based iteration for BPF (also drops earlier rhashtable_walk_enter_from() proposal). - map_extra: presize hint via lower 32 bits (nelem_hint), capped at U16_MAX. - Automatic shrinking enabled (was missing despite being advertised). - Reject key_size > U16_MAX (rhashtable_params.key_len is u16). - Replace irqs_disabled() guard with bpf_disable_instrumentation around bucket-lock paths: closes same-CPU NMI tracing recursion without rejecting legitimate IRQ-context callers. - lookup_and_delete reordered: unlink before copy to avoid populating user buffer on concurrent-unlink -ENOENT. - update_existing reordered: copy then free_fields, matching arraymap. - Word-sized key fast path (sizeof(long) bytes), inlined hashfn/cmpfn via static-const rhashtable_params; works on both 32-bit and 64-bit. - check_and_init_map_value() on insert (zero special-field bytes from recycled bpf_mem_alloc memory; previously bpf_spin_lock could read garbage and qspinlock would deadlock). - BPF_SPIN_LOCK / BPF_RES_SPIN_LOCK allowlist moved to the special- fields commit so each commit is bisect-safe. - Link to v3: https://patch.msgid.link/20260424-rhash-v3-0-d0fa0ce4379b@meta.com Changes in v3: - Squash all commits implementing basic functions into one (Alexei) - Remove selftests that were not necessary (Alexei) - Resize detection for kernel full iterations, error out on resize (Alexei) - Remove second lookup in get_next_key() (Emil) - __acquires(RCU)/__releases(RCU) on seq_start/seq_stop (Emil) - Use bpf_map_check_op_flags() where it makes sense (Leon) - Benchmarks refresh, experiment with alternative hash functions - Rely on iterator invalidation during rehash to handle table resizes: fail on resize where we fully iterate on table inside kernel, dont fail on resize where iteration goes through userspace. Exception - rhtab_map_free_internal_structs() should be just safe to iterate fully in kernel, no risk of infinite loop, because no user holding reference. - Handle special fields during in-place updates (Emil, sashiko) - Link to v2: https://lore.kernel.org/all/20260408-rhash-v2-0-3b3675da1f6e@meta.com/ Changes in v2: - Added benchmarks - Reworked all functions that walk the rhashtable, use walk API, instead of directly accessing tbl and future_tbl - Added rhashtable_walk_enter_from() into rhashtable to support O(1) iteration continuations - Link to v1: https://lore.kernel.org/r/20260205-rhash-v1-0-30dd6d63c462@meta.com --- ==================== Link: https://patch.msgid.link/20260605-rhash-v7-0-5b8e05f8630d@meta.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-06-05selftests/bpf: Add resizable hashmap to benchmarksMykyta Yatsenko
Support resizable hashmap in BPF map benchmarks. 1. LOOKUP (single producer, M events/sec) key | max | nr | htab | rhtab | ratio | delta ----+-----+-------+---------+---------+-------+------- 8 | 1K | 750 | 99.85 | 81.92 | 0.82x | -18 % 8 | 1K | 1K | 100.71 | 80.19 | 0.80x | -20 % 8 | 1M | 750K | 23.37 | 72.09 | 3.08x | +208 % 8 | 1M | 1M | 13.39 | 53.72 | 4.01x | +301 % 32 | 1K | 750 | 51.57 | 42.78 | 0.83x | -17 % 32 | 1K | 1K | 50.81 | 45.83 | 0.90x | -10 % 32 | 1M | 750K | 11.27 | 15.29 | 1.36x | +36 % 32 | 1M | 1M | 7.32 | 8.75 | 1.19x | +19 % 256 | 1K | 750 | 7.58 | 7.88 | 1.04x | +4 % 256 | 1K | 1K | 7.43 | 7.81 | 1.05x | +5 % 256 | 1M | 750K | 3.69 | 4.27 | 1.16x | +16 % 256 | 1M | 1M | 2.60 | 3.12 | 1.20x | +20 % Pattern: * Small map (1K): htab wins for 8 / 32 byte keys by 10-20% * Large map (1M): rhtab wins everywhere, up to 4x at high load factor with 8 byte keys. * Higher load factor amplifies rhtab's lead: rhtab grows the bucket array; htab stays at user-declared max. 2. FULL UPDATE (M events/sec per producer) htab per-producer: 20.33 22.02 19.27 23.61 24.18 23.17 21.07 mean 21.94 range 19.27 - 24.18 rhtab per-producer: 133.51 129.47 74.52 129.29 102.26 129.98 107.64 mean 115.24 range 74.52 - 133.51 speedup (mean): 5.25x (+425 %) In-place memcpy avoids the per-update alloc + RCU pointer swap that htab pays. 3. MEMORY value_size | htab ops/s | rhtab ops/s | htab mem | rhtab mem -----------+-------------+-------------+----------+---------- 32 B | 122.87 k/s | 133.04 k/s | 2.47 MiB | 2.49 MiB 4096 B | 64.43 k/s | 65.38 k/s | 6.74 MiB | 6.44 MiB rhtab/htab : +8 % ops, +0.8 % mem (32 B) +1 % ops, -4 % mem (4096 B) Throughput effectively tied SUMMARY * Small / well-fitting map: htab is faster (cache-friendly fixed bucket array), but only by ~10-20 %. * Large / high-load-factor map: rhtab is dramatically faster (1.2x to 4x) because rhashtable resizes to keep the load factor sane while htab stays stuck at user-declared max. * Update-heavy workloads: rhtab is ~5x faster per producer via in-place memcpy. * Memory benchmark: effectively on par. Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com> Link: https://lore.kernel.org/r/20260605-rhash-v7-12-5b8e05f8630d@meta.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-06-05bpftool: Add rhash map documentationMykyta Yatsenko
Make bpftool documentation aware of the resizable hash map. Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Link: https://lore.kernel.org/r/20260605-rhash-v7-11-5b8e05f8630d@meta.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-06-05selftests/bpf: Add BPF iterator tests for resizable hash mapMykyta Yatsenko
Test basic BPF iterator functionality for BPF_MAP_TYPE_RHASH, verifying all elements are visited. Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com> Link: https://lore.kernel.org/r/20260605-rhash-v7-10-5b8e05f8630d@meta.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-06-05selftests/bpf: Add basic tests for resizable hash mapMykyta Yatsenko
Test basic map operations (lookup, update, delete) for BPF_MAP_TYPE_RHASH including boundary conditions like duplicate key insertion and deletion of nonexistent keys. Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com> Link: https://lore.kernel.org/r/20260605-rhash-v7-9-5b8e05f8630d@meta.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-06-05libbpf: Support resizable hashtableMykyta Yatsenko
Add BPF_MAP_TYPE_RHASH to libbpf's map type name table and feature probing so that libbpf-based tools can create and identify resizable hash maps. Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Link: https://lore.kernel.org/r/20260605-rhash-v7-8-5b8e05f8630d@meta.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-06-05bpf: Optimize word-sized keys for resizable hashtableMykyta Yatsenko
Specialize the lookup/update/delete paths for keys whose size matches sizeof(long) (4 bytes on 32-bit, 8 bytes on 64-bit). A static-const rhashtable_params lets the compiler inline a custom XOR-fold hashfn and a single-word equality cmpfn, eliminating the indirect jhash dispatch. The same hashfn and cmpfn are installed into rhashtable's stored params at rhashtable_init time, so the rehash worker, slow-path inserts, and rhashtable_next_key() all agree with the inlined fast paths. The seq_file BPF iterator uses rhashtable_walk_* and is unaffected. Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com> Link: https://lore.kernel.org/r/20260605-rhash-v7-7-5b8e05f8630d@meta.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-06-05bpf: Allow special fields in resizable hashtabMykyta Yatsenko
Add support for timers, workqueues, task work, spin locks and kptrs. Without this, users needing deferred callbacks, BPF_F_LOCK, or refcounted kernel pointers in a dynamically-sized map have no option - fixed-size htab is the only map supporting these field types. Resizable hashtab should offer the same capability. kptr semantics under in-place updates are identical to array map. Properly clean up BTF record fields on element delete and map teardown by wiring up bpf_obj_free_fields through a memory allocator destructor, matching the pattern used by htab for non-prealloc maps. Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com> Link: https://lore.kernel.org/r/20260605-rhash-v7-6-5b8e05f8630d@meta.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-06-05bpf: Implement iteration ops for resizable hashtabMykyta Yatsenko
Implement get_next_key, batch lookup/lookup-and-delete, for_each_map_elem callback, and the seq_file BPF iterator for BPF_MAP_TYPE_RHASH. get_next_key() and batch use rhashtable_next_key() — stateless, matches the syscall UAPI shape (no kernel-side iterator state). get_next_key falls back to the first key when prev_key was concurrently deleted (matches htab semantics). Batch reports cursor loss as -EAGAIN so userspace can distinguish it from end-of-iteration (-ENOENT) and restart from NULL. The seq_file BPF iterator uses rhashtable_walk_* instead. It runs only from read() syscall context, so the walker's spin_lock is safe, and seq_file's per-fd state lets the walker handle rehash correctly (retry on -EAGAIN) for stronger coverage than the stateless API can provide. Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com> Link: https://lore.kernel.org/r/20260605-rhash-v7-5-5b8e05f8630d@meta.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-06-05bpf: Implement resizable hashmap basic functionsMykyta Yatsenko
Use rhashtable_lookup_likely() for lookups, rhashtable_remove_fast() for deletes, and rhashtable_lookup_get_insert_fast() for inserts. Updates modify values in place under RCU rather than allocating a new element and swapping the pointer (as regular htab does). This trades read consistency for performance: concurrent readers may see partial updates. BPF_F_LOCK support and special-field handling (timers, kptrs, etc.) follow in a later commit. Initialize rhashtable with bpf_mem_alloc element cache. Require BPF_F_NO_PREALLOC. Limit max_entries to 2^31. Free elements via rhashtable_free_and_destroy(). Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com> Link: https://lore.kernel.org/r/20260605-rhash-v7-4-5b8e05f8630d@meta.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-06-05rhashtable: Use irq work for shrinkingHerbert Xu
Use irq work for automatic shrinking so that this may be called in NMI context. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com> Link: https://lore.kernel.org/r/20260605-rhash-v7-3-5b8e05f8630d@meta.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-06-05rhashtable: Add selftest for rhashtable_next_key()Mykyta Yatsenko
Insert n elements, then verify: - NULL prev_key walks from the beginning, visiting all n - non-existing prev_key returns ERR_PTR(-ENOENT) Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Link: https://lore.kernel.org/r/20260605-rhash-v7-2-5b8e05f8630d@meta.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-06-05rhashtable: Add rhashtable_next_key() APIMykyta Yatsenko
Introduce a simpler iteration mechanism for rhashtable that lets the caller continue from an arbitrary position by supplying the previous key, without the per-iterator state of the rhashtable_walk_* API. void *rhashtable_next_key(struct rhashtable *ht, const void *prev_key); Caller holds RCU; passes NULL prev_key for the first element or the previously returned key to advance. Walks tbl->future_tbl chain so in-flight rehashes are observed. Best-effort: in case of concurrent resize, provides no guarantees: - may produce duplicate elements - may skip any amount of elements - termination of the loop is not guaranteed in case of sustained rehash. Callers are advised to bound loop externally or avoid inserting new elements during such loop. Returns ERR_PTR(-ENOENT) if prev_key is not found. Behavior on tables with duplicate keys is undefined. rhltable is not supported — returns ERR_PTR(-EOPNOTSUPP). Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Link: https://lore.kernel.org/r/20260605-rhash-v7-1-5b8e05f8630d@meta.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-06-05RISC-V: KVM: Enhance the logging check for mmu mappingInochi Amaoto
When enabling dirty ring, the dirty bitmap is disable, and the logging check is always false as the RISC-V architecture does not select "NEED_KVM_DIRTY_RING_WITH_BITMAP". Although the dirty log is recorded since the write path already trying to add the dirty log, the logic for logging check is broken and some side effect will occurs. Enhance the logging check for mmu mapping so it can check both the dirty ring and the dirty bitmap. Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260528113840.2629186-1-inochiama@gmail.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-06-05netfilter: conntrack: call nf_ct_gre_keymap_destroy() if master helper is pptpPablo Neira Ayuso
For GRE flows, validate that the ct master helper (if any) is pptp before calling nf_ct_gre_keymap_destroy(), so the helper data area can be accessed safely. Note that only the pptp helper provides a .destroy callback. Fixes: e56894356f60 ("netfilter: conntrack: remove l4proto destroy hook") Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2026-06-05netfilter: conntrack: revert ct extension genid infrastructurePablo Neira Ayuso
This infrastructure is not used anymore after moving ct timeout and helper to use datapath refcount to track object use. Revert commit c56716c69ce1 ("netfilter: extensions: introduce extension genid count") this patch disables all ct extensions (leading to NULL) for unconfirmed conntracks, when this is only targeted at ct helper and ct timeout. There is also codebase that dereferences the ct extension without checking for NULL which could lead to crash. Fixes: c56716c69ce1 ("netfilter: extensions: introduce extension genid count") Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2026-06-05netfilter: nf_conntrack_helper: add refcounting from datapathPablo Neira Ayuso
This patch adds a new ->ct_refcnt field to struct nf_conntrack_helper which is bumped when the helper is used by the ct helper extension. Drop this reference count when the conntrack entry is released. This is a packet path refcount which ensures that struct nf_conntrack_helper remains in place for tricky scenarios where a packet sits in nfqueue, or elsewhere, with a conntrack that refers to this helper. For simplicity, this leaves a single refcount for helper objects in place, remove the existing refcount for control plane that ensures that the helper does not go away if it is used by ruleset. On helper removal, the help callback is set to NULL to disable it from packet path and, after rcu grace period, existing expectations are removed. Update ctnetlink to disable access to .to_nlattr and .from_nlattr if the helper is going away. Remove nf_queue_nf_hook_drop() since it has proven not to be effective because packets with unconfirmed conntracks which are still flying to sit in nfqueue. Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2026-06-05netfilter: nf_conntrack_pptp: move GRE specific cleanup to GRE trackerPablo Neira Ayuso
Move the GRE specific cleanup to nf_conntrack_proto_gre.c to ensure that the .destroy callback for the pptp helper is still reachable by existing conntrack entries while pptp module is being removed. This is a preparation patch, no functional changes are intended. Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2026-06-05wifi: mac80211: Add 802.3 multicast encapsulation offload supportTamizh Chelvam Raja
mac80211 converts 802.3 multicast packets to 802.11 format before driver TX, even when Ethernet encapsulation offload is enabled. This prevents drivers that support multicast Ethernet encapsulation offload from receiving frames in native 802.3 format. Introduce the IEEE80211_OFFLOAD_ENCAP_MCAST flag to bypass the 802.11 encapsulation step and pass the multicast packet to the driver in 802.3 format. Drivers that support multicast Ethernet encapsulation offload can advertise this flag. Disable multicast encapsulation offload in MLO case for drivers not advertising MLO_MCAST_MULTI_LINK_TX support for AP mode and for 3-address AP_VLAN multicast packets. Signed-off-by: Tamizh Chelvam Raja <tamizh.raja@oss.qualcomm.com> Link: https://patch.msgid.link/20260604162403.1563729-4-tamizh.raja@oss.qualcomm.com [fix unlikely(), indentation] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-05wifi: mac80211: Add multicast to unicast support for 802.3 pathTamizh Chelvam Raja
mac80211 already supports multicast-to-unicast conversion for native 802.11 TX paths, but this handling is missing for the 802.3 transmit path. Due to that the packet never converted to unicast and directly pass it to 802.11 Tx path by checking the destination address as multicast. Extend ieee80211_subif_start_xmit_8023() to honor the multicast_to_unicast setting by cloning and converting multicast Ethernet frames into per-station unicast transmissions, following the same behavior of the native 802.11 TX path and allow it to take 802.3 path. Signed-off-by: Tamizh Chelvam Raja <tamizh.raja@oss.qualcomm.com> Link: https://patch.msgid.link/20260604162403.1563729-3-tamizh.raja@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-05wifi: mac80211: Add sta pointer sanity check in ieee80211_8023_xmit()Tamizh Chelvam Raja
Currently ieee80211_8023_xmit() accesses the sta pointer without any sanity check, assuming that only unicast packets for an authorized station are processed. But the sta pointer could become NULL when a framework to support 802.3 offload for the multicast packets is added in the follow-up patches. Add the valid sta pointer sanity check to avoid the invalid pointer access. This aligns with some of the subordinate functions called by ieee80211_8023_xmit() that already NULL-check 'sta' such as ieee80211_select_queue() and ieee80211_aggr_check(). Signed-off-by: Tamizh Chelvam Raja <tamizh.raja@oss.qualcomm.com> Link: https://patch.msgid.link/20260604162403.1563729-2-tamizh.raja@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-05iommufd/selftest: Cover invalid read counts on vEVENTQ FDNicolin Chen
The vEVENTQ file descriptor must reject reads whose buffer cannot hold even one event record. Add selftest coverage that exercises both the empty-queue path (the upfront size check) and the non-empty path (the in-loop check that fires only after an event is fetched). For iommufd_veventq_fops_read(): - count == 0 and count < sizeof(header) on an empty vEVENTQ both return -EINVAL. - count == 0 and count == sizeof(header) on a non-empty vEVENTQ (event has trailing payload) both return -EINVAL. Link: https://patch.msgid.link/r/7bcd153d306f2cf04c094c728c0ebe146855072a.1780343944.git.nicolinc@nvidia.com Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Pranjal Shrivastava <praan@google.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-05iommufd: Avoid partial fault group delivery in iommufd_fault_fops_read()Nicolin Chen
The cookie returned by xa_alloc() in iommufd_fault_fops_read() is per fault group, but the inner copy_to_user() runs per fault inside the group. If a copy fails mid-group, xa_erase clears the cookie and the group is restored to the deliver list, yet done is not rolled back. The function returns the partial byte count, with the successfully copied faults sitting at offsets below done carrying the now-erased cookie. The next read() then re-fetches the group, allocates a fresh cookie, and re-delivers every fault including the ones already copied; userspace sees duplicates carrying the new cookie, and a stale cookie that can never be responded to. Use a local group_done variable that tracks the per-group progress inside the inner loop, and only commit done = group_done after the inner loop has finished successfully. On a copy_to_user failure the outer break skips the commit, so done remains at its prior start-of-group baseline; the partial bytes already written past done are undefined to userspace per the read(2) contract, and the next read re-delivers the whole group atomically. Fixes: 07838f7fd529 ("iommufd: Add iommufd fault object") Link: https://patch.msgid.link/r/360cab4d4aeccb0bae275a970e2b3c340a71e0e0.1780343944.git.nicolinc@nvidia.com Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Pranjal Shrivastava <praan@google.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-05iommufd: Break the loop on failure in iommufd_fault_fops_read()Nicolin Chen
On a copy_to_user() failure inside the inner list_for_each_entry, only the inner loop breaks; the outer while re-fetches the just-restored fault group and retries the failing copy_to_user() forever, spinning the reader at 100% CPU with fault->mutex held. Check rc after the inner loop and break the outer while as well. Fixes: 07838f7fd529 ("iommufd: Add iommufd fault object") Link: https://patch.msgid.link/r/336a9b6e44fe66a24199d3be777c405c85c98622.1780343944.git.nicolinc@nvidia.com Cc: stable@vger.kernel.org Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Pranjal Shrivastava <praan@google.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-05iommufd: Reject invalid read count in iommufd_fault_fops_read()Nicolin Chen
The read count must be large enough to hold one fault or a group's faults. iommufd_fault_fops_read() does not validate the count, but returns 0 as if the read had succeeded while leaving the pending fault in the queue. Return -EINVAL in the undersize cases. Fixes: 07838f7fd529 ("iommufd: Add iommufd fault object") Link: https://patch.msgid.link/r/85c118a606fbedc5c132a1f5ec223a5ba23b92d2.1780343944.git.nicolinc@nvidia.com Cc: stable@vger.kernel.org Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Pranjal Shrivastava <praan@google.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-05iommufd: Propagate allocation failure in iommufd_veventq_deliver_fetch()Nicolin Chen
When the kzalloc_obj() fails in iommufd_veventq_deliver_fetch(), it returns NULL, falsely advertising to userspace that the queue is empty. Propagate the -ENOMEM properly to the caller. Fixes: e36ba5ab808e ("iommufd: Add IOMMUFD_OBJ_VEVENTQ and IOMMUFD_CMD_VEVENTQ_ALLOC") Link: https://patch.msgid.link/r/25d29feac909e36f78c145fa99ef2d4cb7a415da.1780343944.git.nicolinc@nvidia.com Cc: stable@vger.kernel.org Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Pranjal Shrivastava <praan@google.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-05iommufd: Reject invalid read count in iommufd_veventq_fops_read()Nicolin Chen
The read count must be large enough to hold a vEVENT header. For a normal vEVENT, it must also hold the trailing data following the header. iommufd_veventq_fops_read() does not validate the count, but returns 0 as if the read had succeeded while leaving the pending event in the queue. Return -EINVAL in both undersize cases. Fixes: e36ba5ab808e ("iommufd: Add IOMMUFD_OBJ_VEVENTQ and IOMMUFD_CMD_VEVENTQ_ALLOC") Link: https://patch.msgid.link/r/e1111adcc8a8882fbfd84accd6674dc846dc5689.1780343944.git.nicolinc@nvidia.com Cc: stable@vger.kernel.org Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Pranjal Shrivastava <praan@google.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-05iommufd: Rewind header length in done if iommufd_veventq_fops_read() failsNicolin Chen
When the first event copy fails, rc = -EFAULT will not be reported as done is set to the length of the copied header. Rewind it to report rc correctly. Fixes: e36ba5ab808e ("iommufd: Add IOMMUFD_OBJ_VEVENTQ and IOMMUFD_CMD_VEVENTQ_ALLOC") Link: https://patch.msgid.link/r/78f8caeb6a5d667a26b870e3068cec47dd4b5be1.1780343944.git.nicolinc@nvidia.com Cc: stable@vger.kernel.org Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Pranjal Shrivastava <praan@google.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-05x86/cpu: Remove obsolete aperfmperf_get_khz() declarationJunxiao Chang
aperfmperf_get_khz() was replaced by arch_freq_get_on_cpu(). The remaining declaration in the header file is no longer used and should be removed. Fixes: f3eca381bd49 ("x86/aperfmperf: Replace arch_freq_get_on_cpu()") Signed-off-by: Junxiao Chang <junxiao.chang@intel.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Nikolay Borisov <nik.borisov@suse.com> Link: https://patch.msgid.link/20260606021514.1433619-1-junxiao.chang@intel.com
2026-06-05KVM: arm64: Correctly identify executable PTEs at stage-2Oliver Upton
KVM invalidates the I-cache before installing an executable PTE on implementations without DIC. Unfortunately, support for FEAT_XNX broke this check as KVM_PTE_LEAF_ATTR_HI_S2_XN was expanded to a bitfield. Fix it by reusing kvm_pgtable_stage2_pte_prot() and testing the abstract permission bits instead. Fixes: 2608563b466b ("KVM: arm64: Add support for FEAT_XNX stage-2 permissions") Reported-by: Sashiko (gemini/gemini-3.1-pro-preview) Signed-off-by: Oliver Upton <oupton@kernel.org> Reviewed-by: Wei-Lin Chang <weilin.chang@arm.com> Link: https://patch.msgid.link/20260602165901.52800-3-oupton@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: stable@vger.kernel.org
2026-06-05KVM: arm64: nv: Fix handling of XN[0] when !FEAT_XNXOliver Upton
XN has already been extracted from its bitfield position so using FIELD_PREP() on the mask that clears XN[0] is completely broken, having the effect of unconditionally granting execute permissions... Fix the obvious mistake by manipulating the right bit. Cc: stable@vger.kernel.org Fixes: d93febe2ed2e ("KVM: arm64: nv: Forward FEAT_XNX permissions to the shadow stage-2") Reviewed-by: Wei-Lin Chang <weilin.chang@arm.com> Signed-off-by: Oliver Upton <oupton@kernel.org> Link: https://patch.msgid.link/20260602165901.52800-2-oupton@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-06-05cleanup: Specify nonnull argument indexDmitry Ilvokhin
The guard constructors were annotated with an empty __nonnull_args(), relying on __nonnull__() marking every pointer parameter as non-NULL. Sparse cannot parse the empty argument list. Both constructors take the lock pointer as their first parameter, so specify the index explicitly: __nonnull_args(1). Reported-by: Dan Carpenter <error27@gmail.com> Closes: https://lore.kernel.org/all/aiJi0WcYE8FZt-jO@stanley.mountain/ Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/aiKpH3cLBEj3TF2Q@shell.ilvokhin.com
2026-06-05fs/read_write: Do not export __kernel_write() to the entire worldAndy Shevchenko
Since we have EXPORT_SYMBOL_FOR_MODULES(), we may narrow the __kernel_write() export to the only which really needs it. With that being done, update the respective comment. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20260604095233.284067-1-andriy.shevchenko@linux.intel.com Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-06-05ptp: vmclock: Use hw_cycles from snapshot for precise TSC pairingDavid Woodhouse
When the system clocksource is kvmclock or Hyper-V (not the TSC directly), vmclock_get_crosststamp() falls through to a separate get_cycles() call, losing the atomic pairing between the system time snapshot and the TSC reading. Now that ktime_get_snapshot_id() populates hw_cycles with the underlying TSC value for derived clocksources, use it when available. This gives a perfect (system_time, tsc) pairing for the device time calculation. The SUPPORT_KVMCLOCK wrapper is still needed to convert the TSC into kvmclock nanoseconds for system_counter->cycles, because otherwise get_device_system_crosststamp() can't interpret the result against the system clock. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Assisted-by: Kiro:claude-opus-4.6-1m Link: https://patch.msgid.link/20260604095755.64849-4-dwmw2@infradead.org
2026-06-05x86/kvmclock: Implement read_snapshot() for kvmclock clocksourceDavid Woodhouse
Implement the read_snapshot() callback for the kvmclock clocksource. This returns the kvmclock nanosecond value (for timekeeping) while also providing the raw TSC value that was used to compute it. The TSC is read inside the pvclock seqlock-protected region, ensuring the raw TSC and derived kvmclock value are atomically paired. This enables ktime_get_snapshot_id() to provide the raw TSC to consumers like the vmclock PTP driver, which currently has to do a separate call to get_cycles() to obtain a value at *approximately* the same time, to feed through the vmclock calculation. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Assisted-by: Kiro:claude-opus-4.6-1m Link: https://patch.msgid.link/20260604095755.64849-3-dwmw2@infradead.org
2026-06-05clocksource/hyperv: Implement read_snapshot() for TSC page clocksourceDavid Woodhouse
Implement the read_snapshot() callback for the Hyper-V TSC page clock- source. This returns the derived 10MHz reference time (for timekeeping) while also providing the raw TSC value that was used to compute it. When the TSC page is valid, hv_read_tsc_page_tsc() atomically captures both values from a single RDTSC inside the sequence-counter protected read. When the TSC page is invalid (sequence == 0), the hw_csid and hw_cycles are set to zero indicating no value is available. This enables ktime_get_snapshot_id() to provide the raw TSC to consumers like KVM's master clock when running nested guests under Hyper-V. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Assisted-by: Kiro:claude-opus-4.6-1m Reviewed-by: Michael Kelley <mhklinux@outlook.com> Link: https://patch.msgid.link/20260604095755.64849-2-dwmw2@infradead.org
2026-06-05pwm: th1520: Remove requirement for mul_u64_u64_div_u64_roundupMaurice Hieronymus
The cycle register is always u32, so cycles_to_ns() can take a u32 instead of a u64. With that narrowing, cycles * NSEC_PER_SEC is at most u32::MAX * 1e9 (~4.3e18), which fits in u64 without overflow. The saturating arithmetic is therefore no longer needed, and the ceiling division can use Rust's u64::div_ceil() directly instead of the open-coded numerator/denominator form. This also drops the TODO referring to a future mul_u64_u64_div_u64_roundup kernel helper, which is no longer required. Reviewed-by: Michal Wilczynski <m.wilczynski@samsung.com> Signed-off-by: Maurice Hieronymus <mhi@mailbox.org> Link: https://patch.msgid.link/20260605-pwm-th1520-fix-v2-1-5921e3a595f7@mailbox.org Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2026-06-05mm/slub: preserve original size in _kmalloc_nolock_noprof retry pathShengming Hu
_kmalloc_nolock_noprof() retries from the next kmalloc bucket when the initial allocation fails. The retry currently reuses `size` as the bucket selector and overwrites it with s->object_size + 1. That value is later passed as the original allocation size to __slab_alloc_node(), slab_post_alloc_hook() and kasan_kmalloc(). On a successful retry this makes KASAN/slub-debug observe the retry bucket selector rather than the caller requested size, potentially widening the valid kmalloc range and hiding overflows. Keep the caller requested size separately as orig_size and pass it to the allocation/debug/KASAN paths. Continue using `size` as the retry cache selector. Fixes: af92793e52c3 ("slab: Introduce kmalloc_nolock() and kfree_nolock()") Signed-off-by: Shengming Hu <hu.shengming@zte.com.cn> Reviewed-by: Harry Yoo (Oracle) <harry@kernel.org> Reviewed-by: Hao Li <hao.li@linux.dev> Link: https://patch.msgid.link/202606042027323804pk3MRY42Jy7y42OHAhQZ@zte.com.cn Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
2026-06-05iomap: Add IOMAP_F_ZERO_TAIL flag to trace event stringsNamjae Jeon
Add IOMAP_F_ZERO_TAIL to the flag string mapping in iomap trace events. This allows the new flag to be properly displayed in ftrace output when iomap operations use it. Signed-off-by: Namjae Jeon <linkinjeon@kernel.org> Link: https://patch.msgid.link/20260603144031.7370-1-linkinjeon@kernel.org Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-06-05crypto: qat - simplify adf_service_mask_to_string helperThorsten Blum
Use a single scnprintf() for each set bit and drop the offset in the else branch to simplify adf_service_mask_to_string(). Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Acked-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-06-05crypto: powerpc/aes - use min in ppc_{ecb,cbc,ctr,xts}_cryptThorsten Blum
Replace min_t() with the simpler min() macro since the values are unsigned and compatible. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-06-05crypto: chacha20poly1305 - validate poly1305 template argumentXiaonan Zhao
chachapoly_create() still accepts the compatibility poly1305 parameter in the template name, but it assumes the second template argument is always present and immediately passes it to strcmp(). When the argument is missing, crypto_attr_alg_name() returns an error pointer. Check for that before comparing the name so malformed template instantiations fail with an error instead of dereferencing the error pointer in strcmp(). This matches the surrounding Crypto API template pattern where crypto_attr_alg_name() results are validated before string-specific use. Fixes: a298765e28ad ("crypto: chacha20poly1305 - Use lib/crypto poly1305") Cc: stable@kernel.org Reported-by: Yuan Tan <yuantan098@gmail.com> Reported-by: Zhengchuan Liang <zcliangcn@gmail.com> Reported-by: Xin Liu <bird@lzu.edu.cn> Co-developed-by: Luxing Yin <tr0jan@lzu.edu.cn> Signed-off-by: Luxing Yin <tr0jan@lzu.edu.cn> Signed-off-by: Xiaonan Zhao <ngochuongbui67@gmail.com> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-06-05crypto: qat - add KPT support for GEN6 devicesJunyuan Wang
Add support for Intel Key Protection Technology (KPT) on QAT GEN6 devices. KPT protects private keys from exposure by keeping them wrapped (encrypted) while in use, in-flight, and at rest. Keys remain in wrapped form and are not exposed in plaintext in host memory. This feature operates outside of the Linux crypto framework and kernel keyring. Extend the firmware admin interface to enable and configure KPT. During device initialisation, if KPT is enabled, the driver sends an admin message to firmware to enable KPT mode and configure parameters such as the maximum number of SWK (Symmetric Wrapping Key) slots and the SWK time-to-live (TTL). Expose KPT configuration via a new sysfs attribute group, "qat_kpt", and add ABI documentation. Co-developed-by: Nitesh Venkatesh <nitesh.venkatesh@intel.com> Signed-off-by: Nitesh Venkatesh <nitesh.venkatesh@intel.com> Signed-off-by: Junyuan Wang <junyuan.wang@intel.com> Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Reviewed-by: Ahsan Atta <ahsan.atta@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-06-05crypto: pcrypt - restore callback for non-parallel fallbackRuijie Li
pcrypt installs pcrypt_aead_done() on the child AEAD request before trying to submit it through padata. If padata_do_parallel() returns -EBUSY, pcrypt falls back to calling the child AEAD directly. That fallback must not keep the padata completion callback. Otherwise an asynchronous completion runs pcrypt_aead_done() even though the request was never enrolled in padata. Restore the original request callback and callback data before calling the child AEAD directly. This keeps the fallback path aligned with a direct AEAD request while leaving the parallel path unchanged. Fixes: 662f2f13e66d ("crypto: pcrypt - Call crypto layer directly when padata_do_parallel() return -EBUSY") Cc: stable@kernel.org Reported-by: Yuan Tan <yuantan098@gmail.com> Reported-by: Yifan Wu <yifanwucs@gmail.com> Reported-by: Juefei Pu <tomapufckgml@gmail.com> Reported-by: Zhengchuan Liang <zcliangcn@gmail.com> Reported-by: Xin Liu <bird@lzu.edu.cn> Assisted-by: Codex:gpt-5.4 Signed-off-by: Ruijie Li <ruijieli51@gmail.com> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-06-05crypto: nx - fix nx_crypto_ctx_exit argumentSam James
nx_crypto_ctx_shash_exit calls nx_crypto_ctx_exit with crypto_shash_ctx(...) but crypto_shash_ctx gives a nx_crypto_ctx *, not a crypto_tfm *. Fix the type in nx_crypto_ctx_exit and drop the bogus crypto_tfm_ctx call. This fixes the following oops: BUG: Unable to handle kernel data access at 0xc0403effffffffc8 Faulting instruction address: 0xc000000000396cb4 Oops: Kernel access of bad area, sig: 11 [#15] Call Trace: nx_crypto_ctx_shash_exit+0x24/0x60 crypto_shash_exit_tfm+0x28/0x40 crypto_destroy_tfm+0x98/0x140 crypto_exit_ahash_using_shash+0x20/0x40 crypto_destroy_tfm+0x98/0x140 hash_release+0x1c/0x30 alg_sock_destruct+0x38/0x60 __sk_destruct+0x48/0x2b0 af_alg_release+0x58/0xb0 __sock_release+0x68/0x150 sock_close+0x20/0x40 __fput+0x110/0x3a0 sys_close+0x48/0xa0 system_call_exception+0x140/0x2d0 system_call_common+0xf4/0x258 .. which came from hardlink(1) opportunistically using AF_ALG. The same problem exists with nx_crypto_ctx_skcipher_exit getting a context it wasn't expecting, but apparently nobody hit that for years. Cc: Eric Biggers <ebiggers@kernel.org> Cc: stable@vger.kernel.org Fixes: bfd9efddf990 ("crypto: nx - convert AES-ECB to skcipher API") Fixes: 9420e628e7d8 ("crypto: nx - Use API partial block handling") Acked-by: Breno Leitao <leitao@debian.org> Reviewed-by: Eric Biggers <ebiggers@kernel.org> Reported-by: Calvin Buckley <calvin@cmpct.info> Tested-by: Calvin Buckley <calvin@cmpct.info> Suggested-by: Brad Spengler <brad.spengler@opensrcsec.com> Signed-off-by: Sam James <sam@gentoo.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-06-05dt-bindings: crypto: qcom,inline-crypto-engine: Document Hawi ICEManivannan Sadhasivam
The Inline Crypto Engine found in Hawi SoC is compatible with the common baseline IP 'qcom,inline-crypto-engine'. Hence, document the compatible as such. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-06-05dt-bindings: crypto: qcom,prng: Document Hawi TRNGManivannan Sadhasivam
Hawi SoC has the True Random Number Generator (TRNG) which is compatible with the baseline IP "qcom,trng". Hence, document the compatible as such. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-06-05Merge patch series "vfs infrastructure for fs-verity support for XFS with ↵Christian Brauner
post EOF merkle tree" Christian Brauner <brauner@kernel.org> says: This brings in the vfs infrastructure required to implement fs-verity support for XFS. * patches from https://patch.msgid.link/20260520123722.405752-1-aalbersh@kernel.org: iomap: introduce iomap_fsverity_write() for writing fsverity metadata iomap: teach iomap to read files with fsverity iomap: introduce IOMAP_F_FSVERITY and teach writeback to handle fsverity fsverity: generate and store zero-block hash Link: https://patch.msgid.link/20260520123722.405752-1-aalbersh@kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-06-05iomap: introduce iomap_fsverity_write() for writing fsverity metadataAndrey Albershteyn
This is just a wrapper around iomap_file_buffered_write() to create necessary iterator over metadata. Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Andrey Albershteyn <aalbersh@kernel.org> Link: https://patch.msgid.link/20260520123722.405752-10-aalbersh@kernel.org Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2026-08-10 23:45:43 +0000