summaryrefslogtreecommitdiff
path: root/include/linux
AgeCommit message (Collapse)AuthorFilesLines
2026-07-15bpf, sockmap: Account for receive queue in FIONREAD without a verdict programMattia Meleleo1-14/+0
tcp_bpf_ioctl() answers SIOCINQ from psock->msg_tot_len, which only counts bytes in ingress_msg. Without a stream/skb verdict program nothing is diverted there: data stays in sk_receive_queue, so FIONREAD returns 0 even though read() returns data. Add tcp_inq() to the reported value when the psock has no verdict program. The two queues are disjoint, so bytes redirected into ingress_msg from other sockets stay correctly accounted through msg_tot_len. Remove unused sk_psock_msg_inq(). Fixes: 929e30f93125 ("bpf, sockmap: Fix FIONREAD for sockmap") Signed-off-by: Mattia Meleleo <mattia.meleleo@coralogix.com> Reviewed-by: Jiayuan Chen <jiayuan.chen@linux.dev> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Reviewed-by: John Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/bpf/20260708-fionread-no-verdict-v3-1-b4ee31b3af53@coralogix.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-15bpf: Unify helper and kfunc call argument metaAmery Hung1-15/+23
Helper and kfunc argument checking carried two separate meta structs: the verifier-local struct bpf_call_arg_meta and bpf_kfunc_call_arg_meta. Merge them into a single struct bpf_call_arg_meta. This is groundwork for sharing argument checking between helpers and kfuncs. While merging, drop the btf_id field from the helper meta since it is never used. No functional change. Signed-off-by: Amery Hung <ameryhung@gmail.com> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/bpf/20260715064047.1793790-8-ameryhung@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-15bpf: Unify helper and kfunc allocation-size argument handlingAmery Hung1-2/+7
The constant "size of the PTR_TO_MEM returned in R0" argument is handled by both helpers (ARG_CONST_ALLOC_SIZE_OR_ZERO) and kfuncs (__rdonly_buf_size / __rdwr_buf_size), each with its own meta field (meta->mem_size, meta->r0_size) and duplicated validation. Add struct arg_alloc_mem_desc and a shared process_const_alloc_mem_size(), and replace both fields with meta->arg_alloc_mem. The desc records presence with a 'found' flag instead of using a non-zero size as the sentinel. This also fixes a pre-existing bug on the kfunc return path: "no size argument" was tested as r0_size == 0, so an explicit __rdonly_buf_size/__rdwr_buf_size of 0 was treated as absent and fell through to btf_resolve_size(), giving R0 the size of the pointed-to return type instead of 0. With 'found', an explicit zero size is honored and btf_resolve_size() is used only when no size argument was passed. The size is stored in a u32, matching regs[R0].mem_size. The U32_MAX check now apply to both helper and kfunc through process_const_alloc_mem_size(). Fold bpf_session_cookie return size assignment into current kfunc return size resolution path. Note that verifier saves kfunc return size through r0_size instead of mem_size. The later has no active readers so remove it. Signed-off-by: Amery Hung <ameryhung@gmail.com> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/bpf/20260715064047.1793790-5-ameryhung@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-15bpf: Factor out raw_mode-related fields in bpf_call_arg_metaAmery Hung1-0/+9
To prepare for unifying the helper and kfunc call_arg_meta, group the scattered MEM_UNINIT ("raw") memory argument fields (raw_mode, regno and access_size) into a new struct arg_raw_mem_desc. The intention is to make it clear about when these are set and used instead of fields with overly generic names. Identify the raw argument once, up front, in check_raw_mode_ok() (like check_proto_release_reg() does for release_regno), recording its regno. check_stack_range_initialized() now recognizes the raw buffer by matching that regno, so the separate raw_mode flag is no longer needed, and the per-argument "meta->raw_mode = arg_type & MEM_UNINIT" assignments in check_func_arg() go away with it. A raw memory argument can be tagged either ARG_PTR_TO_MEM | MEM_UNINIT or ARG_PTR_TO_MAP_VALUE | MEM_UNINIT (the output buffer of bpf_map_pop_elem() and bpf_map_peek_elem()). Either may be passed as a PTR_TO_STACK, which reaches check_stack_range_initialized() through check_helper_mem_access(), so both must be treated as raw. Extend arg_type_is_raw_mem() to match the map value case as well; otherwise check_raw_mode_ok() would not record the regno for it and an uninitialized stack buffer passed to those helpers would be wrongly rejected for programs without CAP_PERFMON. No functional change intended. This patch does not enable raw_mode memory access for kfunc (i.e., uninit stack will not be allowed to be passed to kfunc for unprivileged programs). Existing kfuncs with arguments tagged with __uninit are either priviledged or dynptr kfuncs, which take another path to make sure the access is checked by check_mem_access(). Signed-off-by: Amery Hung <ameryhung@gmail.com> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/bpf/20260715064047.1793790-3-ameryhung@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-15vdso: Rename HAVE_GENERIC_VDSO to VDSO_DATASTOREThomas Weißschuh1-3/+3
Over time the meaning of HAVE_GENERIC_VDSO has become off. Today it only controls the availability of the vDSO datastore. Rename the symbol to match its function. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Vincenzo Frascino <vincenzo.frascino@arm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Link: https://patch.msgid.link/20260709-vdso-have_generic_vdso-v1-6-d2e1061f268b@linutronix.de
2026-07-15gpiolib: remove trailing comma from sentinel in GPIO_LOOKUP_SINGLEDmitry Torokhov1-1/+1
The GPIO_LOOKUP_SINGLE() macro defines a lookup table with a single entry followed by an empty sentinel entry. The sentinel entry has a trailing comma which is unnecessary. Remove it. Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/alV0wIgZAY_InGYV@google.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-07-15container_of: remove local __mptr variableVincent Mailhol1-2/+1
container_of() can be called in a nested manner to retrieve the grand parent structure as illustrated below: struct foo { int a; }; struct bar { struct foo foo; }; #define to_foo(a_ptr) container_of(a_ptr, struct foo, a) #define to_bar(a_ptr) container_of(to_foo(a_ptr), struct bar, foo) The issue is that the above construct will cause __mptr, the local variable of container_of(), to shadow itself because of the nested call. This then triggers a warning in sparse and W=2 builds. While this warning is benign, it still causes some overhead as proven by below list of commits in which people made local workarounds: - commit 7eab14de73a8 ("mdio, phy: fix -Wshadow warnings triggered by nested container_of()") - commit 8d8c3131248d ("clk: define to_clk_regmap() as inline function") - commit bfb972c5e1cb ("IB/verbs: avoid nested container_of()") - commit 093adbcedf12 ("btrfs: switch helper macros to static inlines in sysfs.h") - commit c1d35dfa0f7d ("rt2x00: Fix sparse warning on nested container_of()") (the list is probably not exhaustive). As a matter of fact, the local variable __mptr is only used once in container_of(). As such, it is not strictly needed. Inline that local __mptr variable to remove once and for all the risk of variable shadowing when nesting container_of() and prevent people from writing further local fixes. Signed-off-by: Vincent Mailhol <mailhol@kernel.org> Link: https://patch.msgid.link/20260714-containerof_refactor-v1-3-b5c31164d2ad@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-15container_of: remove useless pair of parenthesesVincent Mailhol1-1/+1
The last expression in container_of() doesn't need an extra pair of parenthesis. Remove it. Signed-off-by: Vincent Mailhol <mailhol@kernel.org> Link: https://patch.msgid.link/20260714-containerof_refactor-v1-2-b5c31164d2ad@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-15container_of: apply typeof_member() to container_of()Vincent Mailhol1-1/+1
container_of() uses the construct below: ((type *)0)->member to retrieve the type of the structure's member and then ensure that it matches the type of the given pointer. This construct being rather difficult to understand, the typeof_member() macro was created to encapsulate it and give it a descriptive name. Apply typeof_member() to container_of() to make it easier to read and understand what this macro does. Signed-off-by: Vincent Mailhol <mailhol@kernel.org> Link: https://patch.msgid.link/20260714-containerof_refactor-v1-1-b5c31164d2ad@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-14firmware: stratix10-svc: handle NO_RESPONSE in async pollAdrian Ng Ho Yin1-0/+4
Define INTEL_SIP_SMC_STATUS_NO_RESPONSE (0x3) and handle it in stratix10_svc_async_poll() the same way as INTEL_SIP_SMC_STATUS_BUSY, returning -EAGAIN so callers can retry instead of treating the poll as a hard failure. When the Secure Device Manager has not yet produced a response for an asynchronous transaction, ATF is expected to return INTEL_SIP_SMC_STATUS_NO_RESPONSE. Without this handling, the service layer maps the status to -EINVAL and async clients cannot distinguish "not ready yet" from a real error. Fixes: bcb9f4f07061 ("firmware: stratix10-svc: Add support for async communication") Cc: stable@vger.kernel.org Signed-off-by: Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2026-07-14mm/slab: prevent unbounded recursion in free path with new kmalloc typeHarry Yoo (Oracle)1-0/+6
Commit 280ea9c3154b ("mm/slab: avoid allocating slabobj_ext array from its own slab") avoided recursive allocation of obj_exts from kmalloc caches of the same size, by bumping the obj_exts array's allocation size whenever the array size equals the size of the object being allocated. However, as reported by Danielle Costantino and Shakeel Butt, even slabs from kmalloc caches of different sizes can form a cycle by allocating obj_exts arrays from each other [1]: What happened: a KMALLOC_NORMAL slab's obj_exts array (used by allocation profiling / memcg accounting) is itself kmalloc()'d from a KMALLOC_NORMAL cache, so the "slab holds another slab's obj_exts array" relation can form cycles. With sizeof(struct slabobj_ext) == 16 and the host's geometry: - kmalloc-512 has 64 objects/slab -> array is 64*16 == 1024 bytes, served from kmalloc-1k; - kmalloc-1k has 32 objects/slab -> array is 32*16 == 512 bytes, served from kmalloc-512. A kmalloc-512 slab and a kmalloc-1k slab therefore hold each other's obj_exts array. Discarding one frees the other's array, which empties and discards that slab, which frees the first's array, and so on: __free_slab() -> free_slab_obj_exts() -> kfree() -> discard_slab() -> __free_slab() recurses along the cycle until the stack is exhausted. With memory allocation profiling, this allows unbounded recursion in the free path and led to a stack overflow on a production host in the Meta fleet [1]: BUG: TASK stack guard page was hit Oops: stack guard page RIP: 0010:kfree+0x8/0x5d0 Call Trace: __free_slab+0x66/0xc0 kfree+0x3f0/0x5d0 ... ( ~125x __free_slab <-> kfree ) ... <kernel driver freeing a resource> do_syscall_64 It is proposed [1] to resolve this issue by always serving the obj_exts array allocation from kmalloc caches (or large kmalloc) of sizes larger than the object size. However, as pointed out by Vlastimil Babka [2], this can waste an excessive amount of memory as slabs from large kmalloc sizes (e.g. kmalloc-8k) generally need obj_exts arrays much smaller than the object size. Therefore, rather than bumping the size, let us take a different approach; disallow formation of cycles between kmalloc types when allocating obj_exts arrays. Currently, all obj_exts arrays are served from normal kmalloc caches. Cycles cannot be created if obj_exts arrays of normal kmalloc caches are served from a special kmalloc type that can never have obj_exts arrays. To achieve this, create a new kmalloc type called KMALLOC_NO_OBJ_EXT. KMALLOC_NO_OBJ_EXT caches are created with SLAB_NO_OBJ_EXT flag when either 1) memory allocation profiling is not permanently disabled, or 2) kmalloc types with a priority higher than KMALLOC_CGROUP are aliased with KMALLOC_NORMAL. Sheaf bootstrapping for KMALLOC_NO_OBJ_EXT caches now must be deferred because allocation of a barn can trigger obj_exts array allocation of normal kmalloc caches when the KMALLOC_NO_OBJ_EXT cache for that size is not ready yet. For simplicity, perform bootstrapping of sheaves for all kmalloc caches later. Introduce a new slab alloc flag, SLAB_ALLOC_NO_OBJ_EXT, to prevent allocation of obj_exts arrays, and let kmalloc_slab() override the type to KMALLOC_NO_OBJ_EXT when specified. Note that kmalloc_type() remains unchanged because kmalloc_flags() bypasses the kmalloc fastpath. Do not pass SLAB_ALLOC_NO_RECURSE to kmalloc_flags() in alloc_slab_obj_exts() and instead use SLAB_ALLOC_NO_OBJ_EXT only when the objects are allocated from normal kmalloc caches. While this prevents unbounded recursive allocation of obj_exts, it allows KMALLOC_NO_OBJ_EXT caches to have sheaves. Since sheaf allocations specify SLAB_ALLOC_NO_RECURSE that prevents allocation of both sheaves and obj_exts arrays, the recursion depth is bounded. obj_exts arrays for non-kmalloc-normal caches can now have a valid tag. Do not call mark_obj_codetag_empty() when freeing an obj_exts array to avoid false warnings. KMALLOC_NO_OBJ_EXT don't need this as they never allocate those arrays. Reported-by: Danielle Costantino <dcostantino@meta.com> Reported-by: Shakeel Butt <shakeel.butt@linux.dev> Closes: https://lore.kernel.org/linux-mm/20260625230029.703750-1-shakeel.butt@linux.dev [1] Fixes: 4b8736964640 ("mm/slab: add allocation accounting into slab allocation and free paths") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-mm/c5c4208d-a6f0-413e-bad9-49be12f12d55@kernel.org [2] Signed-off-by: Harry Yoo (Oracle) <harry@kernel.org> Reviewed-by: Suren Baghdasaryan <surenb@google.com> Link: https://patch.msgid.link/20260713-kmalloc-no-objext-v3-4-47c7bd138de7@kernel.org Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
2026-07-14vfio: Enable cdev noiommu mode under iommufdJacob Pan1-0/+1
Now that devices under noiommu mode can bind with IOMMUFD and perform IOAS operations, lift restrictions on cdev from VFIO side. Use cases are documented in Documentation/driver-api/vfio.rst Link: https://patch.msgid.link/r/fdac3395ecc52f87b722b54a055ced66733dc48f.1783360051.git.jacob.pan@linux.microsoft.com Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Pranjal Shrivastava <praan@google.com> Reviewed-by: Yi Liu <yi.l.liu@intel.com> Reviewed-by: Alex Williamson <alex@shazbot.org> Signed-off-by: Jacob Pan <jacob.pan@linux.microsoft.com> Fixes: 2c6cf6ab1564 ("iommufd: Allow binding to a noiommu device") Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-07-14lib/alloc_tag: introduce mem_alloc_profiling_permanently_disabled()Harry Yoo (Oracle)1-0/+3
mem_alloc_profiling_enabled() tells whether memalloc profiling is currently enabled. However, even when this function returns false, it can be enabled later. However, this is not enough. Some optimizations can be applied only when memalloc profiling is permanently disabled. For example, to skip the creation of KMALLOC_NO_OBJ_EXT caches at boot time, mem_profiling must be set to "never", "0" w/ debugging on, or have been shutdown so that it can no longer be enabled. Introduce mem_alloc_profiling_permanently_disabled() for this purpose. Signed-off-by: Harry Yoo (Oracle) <harry@kernel.org> Acked-by: Suren Baghdasaryan <surenb@google.com> Link: https://patch.msgid.link/20260713-kmalloc-no-objext-v3-3-47c7bd138de7@kernel.org Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
2026-07-14mm/slab: decouple SLAB_NO_SHEAVES from SLAB_NO_OBJ_EXTHarry Yoo (Oracle)1-2/+11
Bootstrap caches are created with SLAB_NO_OBJ_EXT to disallow sheaves and obj_exts. To allow disabling obj_exts while allowing sheaves, decouple SLAB_NO_SHEAVES from SLAB_NO_OBJ_EXT. Bootstrap caches now have both SLAB_NO_SHEAVES and SLAB_NO_OBJ_EXT. No functional change intended. Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> Signed-off-by: Harry Yoo (Oracle) <harry@kernel.org> Reviewed-by: Suren Baghdasaryan <surenb@google.com> Link: https://patch.msgid.link/20260713-kmalloc-no-objext-v3-2-47c7bd138de7@kernel.org Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
2026-07-14entry: Fix seccomp bypass after ptrace with TSYNCJinjie Ruan1-0/+3
Sashiko review pointed out the following issue. If a thread is stopped in syscall_trace_enter() for ptrace, another thread can install a seccomp filter with SECCOMP_FILTER_FLAG_TSYNC (e.g., via seccomp_attach_filter()). This will successfully set SYSCALL_WORK_SECCOMP on the stopped thread, but syscall_trace_enter() evaluates a cached 'work' variable sampled on entry. Consequently, the subsequent check for SYSCALL_WORK_SECCOMP misses the newly assigned flag, and the filter is silently bypassed. This race condition could allow an unprivileged process to execute a prohibited system call (e.g., execve) that the newly installed filter was intended to block, especially since the tracer might have modified the system call number during the ptrace stop. Fix this by re-reading the syscall_work flags after ptrace handling, so that any new SYSCALL_WORK_SECCOMP flag set by another thread via TSYNC during the ptrace stop is observed before the subsequent seccomp check. Fixes: 142781e108b1 ("entry: Provide generic syscall entry functionality") Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20260629132914.1135C1F000E9@smtp.kernel.org/ Link: https://patch.msgid.link/20260713025712.416366-1-ruanjinjie@huawei.com
2026-07-13sched_ext: Tie cpu occupancy to SCX_CAP_BASE through the task sliceTejun Heo1-4/+13
A task's slice grants it cpu occupancy - how long it holds its cpu. In a sub-scheduler hierarchy cpu access is delegated through revocable capabilities, so a task's occupancy must follow them. Only its own scheduler sets its slice, and extending the slice is allowed only while that scheduler holds baseline cpu access (SCX_CAP_BASE) on the cpu. Otherwise a scheduler could keep occupying a cpu it has been denied simply by handing out long slices. The cap check reads effective caps, which are coherent only under the task's rq lock, and the kernel decrements the slice under that lock as the task runs, so a running task's slice can be changed only there while a queued task's can be set directly. Make scx_bpf_task_set_slice() apply the slice under the rq lock. Synchronously when the caller already holds it, otherwise by stashing it in the new p->scx.slice_oob, tagged with the scheduler's id so a request that outlived a reassignment is dropped. Whether the caller holds @p's current rq lock is tested with p->scx.runnable_cpu. Revocation is enforced through the same grant. When a cpu's effective caps lose SCX_CAP_BASE, the cap-revoke reenq scan also checks the running task and zeroes its slice to evict it. The scan runs as a balance callback after the pick, so this catches both the task that was running when the revoke landed and a capless task the pick just promoted off the local DSQ. The paths that keep a task on its cpu - holding on to the last runnable task in balance, the ENQ_LAST reinsertion and the slice refill on pick - skip tasks lacking baseline access. A migration-disabled task is exempt, mirroring its capless admission on insert. v4: Test rq ownership with p->scx.runnable_cpu, closing a remote-wakeup TOCTOU. (sashiko AI) v3: Keep a pending out-of-band slice request across refill and preserve. (sashiko AI) v2: Only write slice directly when @p is queued on the held rq. (sashiko AI) Signed-off-by: Tejun Heo <tj@kernel.org> Reviewed-by: Andrea Righi <arighi@nvidia.com>
2026-07-13sched_ext: Track the cpu a task is runnable onTejun Heo1-0/+1
Add p->scx.runnable_cpu, the cpu @p is runnable on, or -1 when it is not. It is stamped as @p joins the runnable_list (set_task_runnable()) and cleared as it leaves (clr_task_runnable()), both under the rq lock. task_cpu() can't answer "is @p on this rq" reliably: a remote wakeup changes it under @p's pi_lock alone, without the source rq lock, so it can read as the locked rq while @p is really elsewhere. runnable_cpu changes only under the rq lock, so a caller holding an rq lock can compare against it to know whether that is @p's current rq. Signed-off-by: Tejun Heo <tj@kernel.org> Reviewed-by: Andrea Righi <arighi@nvidia.com>
2026-07-13sched_ext: Add reject DSQ for cap-rejected dispatchesTejun Heo1-2/+13
When a sub-scheduler dispatches a task to a CPU it lacks the required capability on, the task must be rejected rather than allowed to run. Add the machinery for that. Each rq gets a reject DSQ, a kernel-internal holding queue that is never run and that the BPF scheduler cannot reach. An insert that must be refused is diverted there instead of the local DSQ, and a deferred requeue then hands the parked tasks back to the BPF scheduler to re-decide. A cap revoke extends this to already-queued tasks. When the revoke reaches the cpu's effective caps, the cpu scans its local DSQ and reenqueues the tasks that no longer qualify. A migration-disabled task must run on its cpu, so a capless one is admitted anyway and counted in the new SCX_EV_SUB_FORCED_ADMIT event. This is preparation for the actual sub-sched cap enforcement. The divert is wired but inert here. v2: Admit offline-rq and migration_pending inserts to local, not reject. (sashiko AI) Signed-off-by: Tejun Heo <tj@kernel.org> Reviewed-by: Andrea Righi <arighi@nvidia.com>
2026-07-13misc: rtsx_usb: avoid USB I/O in runtime autosuspendSean Rhodes1-0/+3
The runtime autosuspend callback currently queries card status and clears OCP by issuing USB register accesses. This can run from the USB runtime-PM path itself, which is the wrong place to start more device I/O. Keep a cached copy of the card-status bits from normal status reads instead. During runtime autosuspend, use that cached value only to preserve the existing Memory Stick autosuspend deferral. Do not treat raw SD_CD as an autosuspend blocker, because tray-based SD readers can assert SD_CD with an empty tray. A real SD card is protected by the SD/MMC child runtime-PM usage once powered. Also stop clearing OCP from the runtime autosuspend callback, so the callback does not issue USB commands. Fixes: bb400d2120bd ("mfd: rtsx_usb: Defer autosuspend while card exists") Signed-off-by: Sean Rhodes <sean@starlabs.systems> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-07-13Merge 7.2-rc3 into tty-nextGreg Kroah-Hartman121-1029/+1686
We need the tty/serial fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-13Merge 7.2-rc3 into usb-nextGreg Kroah-Hartman121-1029/+1686
We need the USB fixes in here as well to build on top of. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-12Merge tag 'char-misc-7.2-rc3' of ↵Linus Torvalds1-0/+25
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull Android/IIO fixes from Greg KH: "Here is a set of bugfixes for 7.2-rc3 that resolve a bunch of reported issues in just the binder and iio codebases. Included in here are: - binder driver bugfixes for both the rust and c versions for reported problems - lots and lots of iio driver bugfixes for lots of reported issues (including a hid sensor driver bugfix) Full details are in the shortlog, all of these have been in linux-next with no reported issues" * tag 'char-misc-7.2-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (36 commits) iio: event: Fix event FIFO reset race iio: imu: inv_icm42600: fix timestamp clock period by using lower value iio: light: al3010: fix incorrect scale for the highest gain range iio: adc: nxp-sar-adc: Fix the delay calculation in nxp_sar_adc_wait_for() iio: light: tsl2591: return actual error from probe IRQ failure iio: imu: inv_icm42600: fix timestamping by limiting FIFO reading iio: imu: st_lsm6dsx: deselect shub page before reading whoami rust_binder: clear freeze listener on node removal rust_binder: reject context manager self-transaction rust_binder: use a u64 stride when cleaning up the offsets array binder: fix UAF in binder_free_transaction() binder: fix UAF in binder_thread_release() rust_binder: synchronize Rust Binder stats with freeze commands binder: cache secctx size before release zeroes it rust_binder: fix BINDER_GET_EXTENDED_ERROR iio: adc: ad7779: add missing 'select IIO_TRIGGERED_BUFFER' to Kconfig iio: adc: ad4130: add missing `select IIO_TRIGGERED_BUFFER` to Kconfig iio: adc: ti-ads124s08: Return reset GPIO lookup errors iio: temperature: Build mlx90635 with CONFIG_MLX90635 iio: light: al3320a: add missing REGMAP_I2C to Kconfig ...
2026-07-12Merge tag 'trace-v7.2-rc2' of ↵Linus Torvalds2-1/+12
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull tracing fixes from Steven Rostedt: - Free field in error path of synthetic event parse In __create_synth_event() the field was allocated but was not freed in the error path - Fix ring_buffer_event_length() on 8 byte aligned architectures On architectures with CONFIG_HAVE_64BIT_ALIGNED_ACCESS set to y, the ring_buffer_event_length() may return the wrong size. This is because archs with that config set will always use the "big event meta header" as that is 8 bytes keeping the payload 8 bytes aligned, even when a 4 byte header could hold the size of the event But ring_buffer_event_length() doesn't take this into account and only subtracts 4 bytes for the meta header in the length when it should have subtracted 8 bytes - Have osnoise wait for a full rcu synchronization on unregister osnoise_unregister_instance() used to call synchronize_rcu() before freeing its copy of the instance but was switched to kfree_rcu(). The osniose tracer has code that traverses the instances that it uses, and inst is just a pointer to that instance. By using kfree_rcu() instead of synchronize_rcu(), the instance that the inst pointer is pointing to can be freed while the osnoise code is still referencing it That is, a rmdir on an instance first unregisters the tracer. When the unregister finishes, the rmdir expects that the tracer is finished with the instance that it is using. By putting back the synchronize_rcu() in osnoise_unregister_instance() the unregistering of osnoise will now return when all the users of the instance have finished - Remove an unused setting of "ret" in tracing_set_tracer() - Fix ring_buffer_read_page() copying events The commit that changed ring_buffer_read_page() to show dropped events from the buffer itself, split the "commit" variable between the commit value (with flags) and "size" that holds the size of the sub-buffer. A cut and paste error changed the test of the reading from checking the size of the buffer to the size of the event causing reads to only read one event at a time - Make tracepoint_printk a static variable When the tracing sysctl knobs were move from sysctl.c to trace.c, the variable tracepoint_printk no longer needed to be global. Make it static - Fix some typos - Fix NULL pointer dereference in func_set_flag() The flags update of the function tracer first checks if the value of the flag is the same and exits if they are, and then it checks if the current tracer is the function tracer and exits if it isn't. The problem is that these checks need to be in a reversed order, as if the tracer isn't the function tracer, then the flag being checked may not exist. Reverse the order of these checks - Fix ufs core trace events to not dereference a pointer in TP_printk() The TP_printk() part of the TRACE_EVENT() macro is called when the user reads the "trace" file. This can be seconds, minutes, hours, days, weeks, and even months after the data was recorded into the ring buffer. Thus, saving a pointer to an object into the ring buffer and then dereferencing it from TP_printk() can cause harm as the object the pointer is pointing to may no longer exist Fix all the trace events in ufs core to save the device name in the ring buffer instead of dereferencing the device descriptor from TP_printk() - Prevent out-of-bound reads in glob matching of trace events The filter logic of events allows simple glob logic to add wild cards to filter on strings. But some events have fields that may not have a terminating 'nul' character. This may cause the glob matching to go beyond the string. Change the logic to always pass in the length of the field that is being matched - Add no-rcu-check version of trace_##event##_enabled() The trace_##event##_enabled() usually wraps trace events to do extra work that is only needed when the trace event is enabled. But this can hide events that are placed in locations where RCU is not watching, and can make lockdep not see these bugs when the event is not enabled The trace_##event##_enabled() was updated to always test to make sure RCU is watching to catch locations that may call events without RCU being active This caused a false positive for the irq_disabled() and related events. As that use trace_irq_disabled_enabled() to force RCU to be watching when the event is enabled via the ct_irq_enter() function, calls the event, and then calls ct_irq_exit() to put RCU back to its original state The trace_irq_disabled_enabled() should not trigger a warning when RCU is not watching because the code within its block handles the case properly. Make a __trace_##event##_enabled() version for this event to use that doesn't check RCU is watching as it handles the case when it isn't - Fix use-after-free in user_event_mm_dup() When the enabler is removed from the link list, it is freed immediately. But it is protected via RCU and needs to be freed after an RCU grace period. Use queue_rcu_work() so that the event_mutex can also be taken as user_event_put() takes the mutex on the last reference is released - Free type string in error path of parse_synth_field() There's an error path in parse_synth_field() where the allocated type string is not freed - Add selftest that tests deferred event teardown - Fix leak in error path of trace_remote_alloc_buffer() If page allocation fails, the desc->nr_cpus is not incremented for the current CPU and the allocations done for it are not freed - Fix allocation length in trace_remote_alloc_buffer() The logic to calculate the struct_len was doing a double count and setting the value too large. Calculate the size upfront to fix the error and simplify the logic - Fix sparse CPU masks in ring_buffer_desc() If there are sparse CPUs (gaps in the numbering), the ring_buffer_desc() will fail as it tests the CPU number against the number of CPUs that are used * tag 'trace-v7.2-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: ring-buffer: Allow sparse CPU masks in ring_buffer_desc() tracing/remotes: Fix struct_len in trace_remote_alloc_buffer() tracing/remotes: Fix leak in trace_remote_alloc_buffer() error path selftests/user_events: Wait for deferred event teardown after unregister tracing/synthetic: Free type string on error path tracing/user_events: Fix use-after-free in user_event_mm_dup() tracing: Add a no-rcu-check version of trace_##event##_enabled() tracing: Prevent out-of-bounds read in glob matching ufs: core: tracing: Do not dereference pointers in TP_printk() tracing: Fix NULL pointer dereference in func_set_flag() samples: ftrace: Fix typos in benchmark comment tracing: Make tracepoint_printk static as not exported ring-buffer: Fix ring_buffer_read_page() copying only one event per page tracing: Remove unused ret assignment in tracing_set_tracer() tracing/osnoise: Call synchronize_rcu() when unregistering ring-buffer: Fix event length with forced 8-byte alignment tracing/synthetic: Free pending field on error path
2026-07-12ptrace, treewide: Rename ptrace_report_syscall_entry() to ↵Thomas Gleixner2-20/+18
ptrace_report_syscall_permit_entry() The return value of that function is boolean and tells the caller whether to permit the syscall processing or not. Rename the function so the purpose is clear and make the return type bool. Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras@gmail.com> Reviewed-by: Jinjie Ruan <ruanjinjie@huawei.com> Reviewed-by: Radu Rendec <radu@rendec.net> Reviewed-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras@gmail.com> Acked-by: Oleg Nesterov <oleg@redhat.com> Acked-by: Magnus Lindholm <linmag7@gmail.com> Link: https://patch.msgid.link/20260707190254.280015701@kernel.org
2026-07-12seccomp, treewide: Rename and convert __secure_computing() to return booleanJinjie Ruan2-11/+10
The return value of __secure_computing() currently uses 0 to indicate that a system call should be allowed, and -1 to indicate that it should be blocked/killed. This 0/-1 pattern is non-intuitive for a security check function and makes the control flow at the call sites less readable. Furthermore, any potential future changes to these return values would require a high-risk, error-prone audit of all its users across different architectures. Sanitize this logic by converting the return type of __secure_computing() to a proper boolean, where 'true' explicitly means 'allow' and 'false' means 'fail/deny'. Update all the two dozen or so call sites across the tree to align with this new boolean semantic. No functional changes are intended, as the callers still return -1 to the lower-level assembly entry code upon seccomp denial. Rename the function to __seccomp_permit_syscall() so that the purpose is entirely clear. [ tglx: Rename the function ] Suggested-by: Thomas Gleixner <tglx@kernel.org> Suggested-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras@gmail.com> Reviewed-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras@gmail.com> Acked-by: Oleg Nesterov <oleg@redhat.com> Link: https://patch.msgid.link/20260707190254.230735780@kernel.org
2026-07-12entry: Use syscall number instead of rereading itThomas Gleixner1-4/+5
rseq_syscall_enter_work() is invoked before the syscall number can be modified. So there is no point in rereading it from pt_regs. Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras@gmail.com> Reviewed-by: Radu Rendec <radu@rendec.net> Reviewed-by: Jinjie Ruan <ruanjinjie@huawei.com> Reviewed-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Link: https://patch.msgid.link/20260707190254.181086755@kernel.org
2026-07-12entry: Remove syscall_enter_from_user_mode()Thomas Gleixner2-39/+7
All architecture use either: nr = syscall_enter_from_user_mode_randomize_stack(regs, nr); or enter_from_user_mode_randomize_stack(regs); nr = syscall_enter_from_user_mode_work(regs, nr); Remove the now unused function. Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras@gmail.com> Reviewed-by: Jinjie Ruan <ruanjinjie@huawei.com> Reviewed-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras@gmail.com> Link: https://patch.msgid.link/20260707190254.132654198@kernel.org
2026-07-12entry: Provide [syscall_]enter_from_user_mode_randomize_stack()Thomas Gleixner1-0/+56
Randomizing the syscall stack can only happen after state is established via enter_from_user_mode() or syscall_enter_from_user_mode(). The earlier it happens the better. Provide two new macros to consolidate that: - enter_from_user_mode_randomize_stack() enter_from_user_mode(); add_random_kstack_offset_irqsoff(); - syscall_enter_from_user_mode_randomize_stack() enter_from_user_mode_randomize_stack(); syscall_enter_from_user_mode_work(); to reduce boiler plate code. Those are macros and not inline functions as the latter would limit the stack randomization scope to the inline function itself. Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras@gmail.com> Reviewed-by: Radu Rendec <radu@rendec.net> Reviewed-by: Jinjie Ruan <ruanjinjie@huawei.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Reviewed-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras@gmail.com> Link: https://patch.msgid.link/20260707190253.816918647@kernel.org
2026-07-12randomize_kstack: Provide add_random_kstack_offset_irqsoff()Thomas Gleixner1-0/+19
add_random_kstack_offset() uses get/put_cpu_var() which is pointless overhead when it is invoked from low level entry code with interrupts disabled. Provide a irqsoff() variant, which avoids that. Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Radu Rendec <radu@rendec.net> Reviewed-by: Kees Cook <kees@kernel.org> Reviewed-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras@gmail.com> Link: https://patch.msgid.link/20260707190253.768842729@kernel.org
2026-07-12RDMA: Change capability fields in ib_device_attr from int to u32Erni Sri Satya Vennela1-2/+2
The capability counter fields in struct ib_device_attr are declared as signed int, but these values are inherently non-negative. Drivers maintain their cached caps as u32 and assign them directly into these int fields; if a cap exceeds INT_MAX the implicit narrowing yields a negative value visible to the IB core. Change the signed int capability fields to u32 to match the underlying nature of the data. Also update consumers across the IB core, ULPs, NVMe-oF target, RDS, and NFS/RDMA so the new u32 values are not forced back through signed int or u8 via min()/min_t() or narrowing local variables. The nvmet-rdma consumer of max_srq clamps it against ib_device.num_comp_vectors, which stays a signed int, so that site uses min_t() instead of min() to handle the signed/unsigned mismatch. Suggested-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Erni Sri Satya Vennela <ernis@linux.microsoft.com> Link: https://patch.msgid.link/20260709055211.2498307-1-ernis@linux.microsoft.com Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Stefan Metzmacher <metze@samba.org> # smbdirect Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-11kobject: Allow the constification of kobject attributesThomas Weißschuh1-6/+51
Allow kobject attribute to reside in read-only memory. Both const and non-const attributes are handled by the utility macros and attributes can be migrated one-by-one. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://patch.msgid.link/20260707-sysfs-const-attr-kobj-attr-prep-v2-3-35ae1bc0f9ef@weissschuh.net Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-07-11kobject: Provide macros to initialize 'struct kobj_attribute'Thomas Weißschuh1-0/+22
Currently the generic __ATTR*() macros are used to initialize kobject attributes. These are not able to handle the upcoming piece-by-piece constification of the attribute callback handlers. Add dedicated macros of kobject attributes. For now these are the same as the generic macros, but they will change soon. Users will be converted to these macros as part of the constification, but it is expected that they will be used generally in the future. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://patch.msgid.link/20260707-sysfs-const-attr-kobj-attr-prep-v2-1-35ae1bc0f9ef@weissschuh.net Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-07-11net: Call unregister_netdevice_many() per netns.Kuniyuki Iwashima1-0/+6
For per-netns device unregistration, the list passed to unregister_netdevice_many() must contain devices from a single netns only (once all callers are converted). Let's move collected devices in the following functions to net->dev_unreg_head and let __rtnl_net_unlock() pass them to unregister_netdevice_many(). * default_device_exit_batch() * ops_exit_rtnl_list() * __rtnl_kill_links() This allows incremental conversion of each driver to support per-netns device unregistration without affecting the normal kernel where CONFIG_DEBUG_NET_SMALL_RTNL is disabled. Note that this change unbatches synchronize_rcu() etc in unregister_netdevice_many(), but we can later split it into multiple stages to batch them again. Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260703001009.1572444-8-kuniyu@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-11net: Add per-netns netdev unregistration infra.Kuniyuki Iwashima1-0/+18
When we need to unregister a netdev in a different netns, we will delegate its unregistration to per-netns work. There are three types of such cross-netns devices: 1. Paired devices (e.g., netkit, veth, vxcan) -> Unregistering one device also deletes its peer, which may reside in another netns. 2. Tunnel devices (e.g., bareudp, geneve, etc) -> Destroying a netns removes devices in another netns if their backend sockets reside in the dying netns 3. Stacked devices (e.g., ipvlan, macvlan, etc) -> Removing the lower device also removes multiple upper devices, each of which may reside in different namespaces. In these cases, we will use unregister_netdevice_queue_net() to queue such potential cross-netns devices for destruction. Each driver must not call both unregister_netdevice_queue_net() and unregister_netdevice_queue() for the same device. See the subsequent veth/bareudp/ipvlan patches for how they avoid double queueing. unregister_netdevice_queue_net() takes net and dev. If dev resides in the net, it simply calls unregister_netdevice_queue(). If dev_net(dev) is different from the net, it enqueues the device to dev_net(dev)->dev_unreg_head and schedules the per-netns work. When __rtnl_net_unlock() is called from the per-netns work (or another thread already holding the lock), unregister_netdevice_many_net() collects the queued devices and calls unregister_netdevice_many() to perform the actual unregistration. During netns dismantle, rtnl_net_flush_workqueue() is called at the end of default_device_exit_batch() to ensure that cross-netns devices in the other alive netns are unregistered. Once RTNL is removed, a device could be moved to another netns while being queued to net->dev_unreg_head. __dev_change_net_namespace() handles this race by acquiring net->dev_unreg_lock of both the old and new netns after dev_set_net() and moving the device between their dev_unreg_head lists. Since dev_set_net() and unregister_netdevice_queue_net() are synchronised by netdev_lock(), the device is either queued to the old netns's dev_unreg_head and then moved, or queued directly to the new netns. Note that unregister_netdevice_move_net() does not need to call rtnl_net_queue_work() because __dev_change_net_namespace() is (supposed to be) called with rtnl_net_lock(). (Not all callers hold it yet, but the race does not happen until all callers are converted and RTNL is removed.) Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260703001009.1572444-7-kuniyu@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-11rtnetlink: Add per-netns rtnl_work.Kuniyuki Iwashima1-0/+8
The biggest blocker to per-netns RTNL is netdev unregistration. It starts within a single netns (e.g., during a device lookup or netns dismantle), but it can eventually involve multiple namespaces, such as when upper ipvlan devices reside in different netns. This prevents us from acquiring multiple rtnl_net_lock()s beforehand. When we encounter such a cross-netns device, we must delegate the unregistration to the work of the netns where the device actually resides. Let's add per-netns rtnl_work to support the deferred netdev unregistration. Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260703001009.1572444-4-kuniyu@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-10Merge tag 'nfs-for-7.2-2' of git://git.linux-nfs.org/projects/anna/linux-nfsLinus Torvalds1-0/+1
Pull NFS client fixes from Anna Schumaker: - SUNRPC: - Release lower rpc_clnt if killed waiting for XPRT_LOCKED - Pin upper rpc_clnt across the TLS connect_worker - NFS: - Include MAY_WRITE in open permission mask for O_TRUNC - Charge unstable writes by request size, not folio size * tag 'nfs-for-7.2-2' of git://git.linux-nfs.org/projects/anna/linux-nfs: NFS: Charge unstable writes by request size, not folio size NFSv4: include MAY_WRITE in open permission mask for O_TRUNC SUNRPC: pin upper rpc_clnt across the TLS connect_worker SUNRPC: release lower rpc_clnt if killed waiting for XPRT_LOCKED
2026-07-10KVM: SEV: Forcefully invalidate SNP VMSA if its backing gmem page is zappedSean Christopherson1-0/+1
Wire up a gmem_invalidate_range() call for SNP VMs, and use it to force vCPUs to reload/recheck their guest-provided VMSA if the backing gmem page is being invalidated, e.g. is being PUNCH_HOLE'd. Use the same core logic to handle invalidations as VMX does for the APIC-access page, as the two concepts are nearly identical: shove the physical address of a page into the vCPU's control structure: 1. Snapshot the invalidation sequence counter 2. Grab the pfn (from guest_memfd in this case) 3. Acquire mmu_lock for read 4. Re-request reload if retry is needed, otherwise commit the change. Note, the re-request action in #4 is necessary as KVM's retry logic is fuzzy, i.e. can get false positives. If the guest_memfd page has been dropped, at some point a subsequent reload will fail to get a PFN from guest_memfd, and KVM will fail KVM_RUN. If the retry was due to a false positive, KVM will retry until there are no relevant MMU notifier events (and will retry in the "outer" loop, i.e. will drop locks and resched as needed). Note #2! Take care to invalidate the VMSA when a relevant memslot is DELETED or MOVED, as invalidations in response to PUNCH_HOLE are predicated on memslot bindings (KVM doesn't know what GFN range(s) to invalidate without a binding). And more importantly, the VMSA mapping requires a memslot, i.e. must be invalidated if its memslots disappears, regardless of the state of the underlying guest_memfd inode. Failure to invalidate the vCPU's control.vmsa_pa (which is checked by pre_sev_run()) can prevent KVM from properly freeing the page as firmware will reject the RMPUPDATE to reclaim the page with FAIL_INUSE if the vCPU is actively running, i.e. if VMSA page is in-use. That in turn leads to an RMP #PF on the next use, as the page will still be assigned to the SNP VM. SEV-SNP: RMPUPDATE failed for PFN 78d198, pg_level: 1, ret: 3 SEV-SNP: PFN 0x78d198, RMP entry: [0xfff0000000144001 - 0x000000000000000f] CPU: 3 UID: 0 PID: 31345 Comm: sev_snp_vmsa_pu Tainted: G U O Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026 Call Trace: <TASK> dump_stack_lvl+0x54/0x70 rmpupdate+0x12c/0x140 rmp_make_shared+0x3b/0x60 sev_gmem_invalidate+0xe0/0x170 [kvm_amd] delete_from_page_cache_batch+0x1d8/0x220 truncate_inode_pages_range+0x120/0x3d0 kvm_gmem_fallocate+0x19a/0x270 [kvm] vfs_fallocate+0x1bc/0x1f0 __x64_sys_fallocate+0x48/0x70 do_syscall_64+0x10a/0x480 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x496c7e </TASK> ------------[ cut here ]------------ SEV: Failed to update RMP entry for PFN 0x78d198 error -14 WARNING: arch/x86/kvm/svm/sev.c:5160 at sev_gmem_invalidate+0x126/0x170 [kvm_amd], CPU#3: sev_snp_vmsa_pu/31345 CPU: 3 UID: 0 PID: 31345 Comm: sev_snp_vmsa_pu Tainted: G U O Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026 RIP: 0010:sev_gmem_invalidate+0x12b/0x170 [kvm_amd] Call Trace: <TASK> delete_from_page_cache_batch+0x1d8/0x220 truncate_inode_pages_range+0x120/0x3d0 kvm_gmem_fallocate+0x19a/0x270 [kvm] vfs_fallocate+0x1bc/0x1f0 __x64_sys_fallocate+0x48/0x70 do_syscall_64+0x10a/0x480 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x496c7e </TASK> irq event stamp: 20689 hardirqs last enabled at (20699): [<ffffffff8e76092c>] __console_unlock+0x5c/0x60 hardirqs last disabled at (20708): [<ffffffff8e760911>] __console_unlock+0x41/0x60 softirqs last enabled at (20722): [<ffffffff8e6cd74e>] __irq_exit_rcu+0x7e/0x140 softirqs last disabled at (20717): [<ffffffff8e6cd74e>] __irq_exit_rcu+0x7e/0x140 ---[ end trace 0000000000000000 ]--- BUG: unable to handle page fault for address: ffff99a64d198000 #PF: supervisor write access in kernel mode #PF: error_code(0x80000003) - RMP violation PGD 13eb001067 P4D 13eb001067 PUD 78d1d1063 PMD 1184e0063 PTE 800000078d198163 SEV-SNP: PFN 0x78d198, RMP entry: [0x6030000000144001 - 0x000000000000000f] Oops: Oops: 0003 [#1] SMP CPU: 3 UID: 0 PID: 31407 Comm: highlanderd_hea Tainted: G U W O Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026 RIP: 0010:prep_new_page+0x67/0x220 Call Trace: <TASK> get_page_from_freelist+0x1c40/0x1c70 __alloc_frozen_pages_noprof+0xca/0x1f0 alloc_pages_mpol+0x10b/0x1b0 alloc_pages_noprof+0x81/0x90 pte_alloc_one+0x1b/0xd0 do_pte_missing+0xdf/0x1020 handle_mm_fault+0x7c7/0xb20 do_user_addr_fault+0x268/0x6b0 exc_page_fault+0x67/0xa0 asm_exc_page_fault+0x26/0x30 RIP: 0033:0x4a6b1e </TASK> gsmi: Log Shutdown Reason 0x03 CR2: ffff99a64d198000 ---[ end trace 0000000000000000 ]--- RIP: 0010:prep_new_page+0x67/0x220 Drop the pseudo-TODO comment about needing to pin the page if guest_memfd every supports migration, as integrating with invalidations events means KVM will Just Work if/when page migration is ever supported (assuming SNP hardware supports migrating VMSA pages). Note #3, invalidate() and invalidate_range() have _completely_ different semantics; the new invalidate_range() is a true invalidation, whereas the existing invalidate() is really a "make shared" operation. Ignore the confusing naming and poor Kconfig bundling for the moment to minimize the delta for LTS kernels, the mess will be cleaned up shortly. Reported-by: Hyunwoo Kim <imv4bel@gmail.com> Closes: https://lore.kernel.org/all/aimMWzAf5b3luM0b@v4bel Fixes: e366f92ea99e ("KVM: SEV: Support SEV-SNP AP Creation NAE event") Cc: stable@vger.kernel.org Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Jörg Rödel <joro@8bytes.org> Cc: Fuad Tabba <tabba@google.com> Cc: Ackerley Tng <ackerleytng@google.com> Reviewed-by: Michael Roth <michael.roth@amd.com> Link: https://patch.msgid.link/20260709204948.1988414-11-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-10Merge tag 'wireless-2026-07-09' of ↵Paolo Abeni1-8/+4
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless Johannes Berg says: ==================== Too many robustness fixes to list. Mostly for - slight out-of-bounds reads of SKBs, - leaks on error conditions, and - malformed netlink input rejection. * tag 'wireless-2026-07-09' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: (46 commits) wifi: cfg80211: bound element ID read when checking non-inheritance wifi: brcmfmac: cyw: fix heap overflow on a short auth frame wifi: brcmfmac: initialize SDIO data work before cleanup wifi: cfg80211: validate assoc response length before status and IE access wifi: cfg80211: validate rx/tx MLME callback frame lengths before access wifi: mac80211: ibss: wait for in-flight TX on disconnect wifi: mac80211: recalculate rx_nss on IBSS peer capability update wifi: cfg80211: use wiphy work for socket owner autodisconnect wifi: mac80211: fix memory leak in ieee80211_register_hw() wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock wifi: mac80211: validate deauth frame length before reason access wifi: mac80211: avoid non-S1G AID fallback for S1G assoc wifi: cfg80211: reject empty PMSR peer lists wifi: cfg80211: reject unsupported PMSR FTM location requests wifi: cfg80211: validate PMSR FTM preamble range wifi: cfg80211: validate PMSR measurement type data wifi: nl80211: constrain MBSSID TX link ID range wifi: nl80211: validate nested MBSSID IE blobs wifi: ieee80211: validate MLE common info length wifi: cfg80211: derive S1G beacon TSF from S1G fields ... ==================== Link: https://patch.msgid.link/20260709115038.243870-3-johannes@sipsolutions.net Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-10driver core: platform: provide platform_device_set_of_node_from_dev()Bartosz Golaszewski1-0/+2
Provide a platform-specific variant of device_set_of_node_from_dev(). In addition to bumping the reference count of the OF node being assigned, it also assigns the fwnode of the platform device. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://patch.msgid.link/20260706-pdev-fwnode-ref-v3-4-1ff028e33779@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-10driver core: platform: provide platform_device_set_fwnode()Bartosz Golaszewski1-0/+3
Provide a helper function encapsulating the logic of assigning firmware nodes to platform devices created with platform_device_alloc(). Make the kerneldoc state that this is the proper interface for assigning firmware nodes to dynamically allocated platform devices. This will allow us to switch to counting the references of the device's firmware nodes in the future, not only the OF nodes. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://patch.msgid.link/20260706-pdev-fwnode-ref-v3-3-1ff028e33779@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-10driver core: platform: provide platform_device_set_of_node()Bartosz Golaszewski1-0/+3
Encapsulate the reference counting logic for OF nodes assigned to platform devices created with platform_device_alloc() in a helper function. Make the kerneldoc state that this is the proper interface for assigning OF nodes to dynamically allocated platform devices. This will allow us to switch to counting the references of the device's firmware nodes, not only the OF nodes. Reviewed-by: Manuel Ebner <manuelebner@mailbox.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://patch.msgid.link/20260706-pdev-fwnode-ref-v3-2-1ff028e33779@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-10usb: fix UAF when probe runs concurrent to dyn ID removalGary Guo1-1/+2
Dynamic IDs are only guaranteed to be valid when usb_dynids_lock is held, as remove_id_store can free the node. Thus, make a copy in usb_probe_interface. Clarify the documentation that the id parameter is only valid during the probe. USB serial has the same pattern, but it does not need fixing as the IDs cannot be removed via sysfs. Fixes: 0c7a2b72746a ("USB: add remove_id sysfs attr for usb drivers") Signed-off-by: Gary Guo <gary@garyguo.net> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260707-usb_dyn_id_uaf-v2-7-632dcf3adfba@garyguo.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-10usb: typec: tcpm: fix EPR AVS APDO maximum voltage decodingXu Rao1-1/+1
pdo_epr_avs_apdo_max_voltage_mv() extracts the EPR AVS minimum-voltage field instead of the maximum-voltage field. As a result, an EPR AVS APDO with different minimum and maximum voltages is decoded as having identical limits. The currently visible effect is that tcpm_log_source_caps() reports a min-min voltage range. Extract PDO_EPR_AVS_APDO_MAX_VOLT in the maximum-voltage accessor. Fixes: f82890c98f3e ("tcpm: Parse and log AVS APDO") Signed-off-by: Xu Rao <raoxu@uniontech.com> Link: https://patch.msgid.link/48301FCEC9F3CA14+20260616085439.987664-1-raoxu@uniontech.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-10serial: core: add new I/O type for SPI and I2C bus devicesHugo Villeneuve1-0/+1
I2C/SPI serial drivers don't use the following struct uart_port variables: port->membase port->mapbase port->iobase However, they are forced to set membase to a non-zero value so that uart_configure_port() will succeed because of the following check: /* If there isn't a port here, don't do anything further. */ if (!port->iobase && !port->mapbase && !port->membase) return; Add a new I/O type for SPI and I2C bus devices to remove the need to implement the kind of above-mentioned ambiguous workarounds to make them work. Now that UART report functions are using uart_iotype_*() functions, no more irrelevant I/O information are being printed for UPIO_BUS iotypes. Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://patch.msgid.link/20260521-tty-upio-v3-7-bf74567994a0@dimonoff.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-10serial: uniformize serial port I/O infos displayHugo Villeneuve1-0/+1
Uniformize serial port I/O infos display from three different functions that display mostly the same information, but with some variations, by adding a common function. This make use of new functions uart_iotype_mmio() and uart_iotype_legacy_io() to simplify and improve code readability. This will prevent displaying irrelevant information for future IO types (ex: UPIO_BUS), while also addressing the (eventually) invalid check for "iotype >= UPIO_MEM". This also allows us to remove the confusing cast to (unsigned long long) for iobase which is defined as an unsigned long, and use %pa to display the mapbase pointer, as it is done in earlycon_print_info(). Replace snprintf with more robust scnprintf so we could perhaps one day get rid of snprintf() entirely. Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://patch.msgid.link/20260521-tty-upio-v3-4-bf74567994a0@dimonoff.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-10serial: core: add uart_iotype_mmio/io helper functionsHugo Villeneuve1-0/+4
To help simplify code that check on the io type mode of the port. Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://patch.msgid.link/20260521-tty-upio-v3-2-bf74567994a0@dimonoff.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-10platform/x86/amd/pmf: Store commonly used enums in the header fileShyam Sundar S K1-9/+0
Relocate commonly used enums from multiple source files into a shared header file to simplify code structure, improve readability, and enhance maintainability. Also, remove the initialization of the first enum member, since it is not needed. Add the AMD_PMF_ prefix to the laptop_placement and platform_type enums since these names are overly generic for inclusion in a UAPI header Co-developed-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://patch.msgid.link/20260609081044.2416731-4-Shyam-sundar.S-k@amd.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-07-10Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netPaolo Abeni117-1028/+1648
Cross-merge networking fixes after downstream PR (net-7.2-rc3). Conflicts: tools/testing/selftests/net/lib.sh dd6a23bac306b ("selftests: net: make busywait timeout clock portable") 895bad9cc4cec ("selftests: net: make busywait timeout clock portable") Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-10timekeeping: Drive time_offset skew via per-tick ntp_error transferDavid Woodhouse1-0/+1
Currently, the phase offset of time_offset and time_adjust is delivered by adjusting tick_length in second_overflow(), and immediately draining time_offset/time_adjust by the amount that the tick_length adjustment is *estimated* to cause. This is fairly approximate, in part because it is not always correct to assume that precisely NTP_INTERVAL_FREQ ticks will occur between one call to second_overflow() and the next. It could also over and under-run in the final second of delivery. Instead of inflating tick_length, transfer the intended skew directly into ntp_error each tick to achieve the desired rate. In second_overflow(), calculate skew_delta which is the per-tick slew rate, in the same units as time_offset: (ns << NTP_SCALE_SHIFT) / HZ. In logarithmic_accumulation(), drain up to 'skew_delta' time units from time_offset into ntp_error to drive the overall effective rate. The new ntp_drain_skew() function returns the amount which is actually 'claimed' by time_offset (and in a future patch, time_adjust). Any overrun which is delivered by the changed 'mult' (as described below) but not claimed by ntp_drain_skew() will remain in ntp_error to be corrected away in subsequent ticks. Simply transferring the precise amount from time_offset to ntp_error would be sufficent to make the time *eventually* converge, however the skew delivered is limited by the choice of { mult, mult+1 } each tick and thus the convergence would be extremely slow. In theory we could inflate ntp_err_mult with the magnitude of ntp_error in the general case — but that would cause overcorrection in a tickless kernel. Instead, in timekeeping_adjust(), take skew_delta into account when calculating 'mult', such that the available {mult, mult+1} choices bracket the overall effective rate *including* the skew, to avoid the delta just building up in ntp_error. The effect is that the inflated 'mult' causes ntp_error to grow because xtime_interval is (e.g.) longer than the true tick_length. But then the same delta is removed again as it's drained from time_offset. This gives behaviour equivalent to the old tick_length += delta approach but with exact per-tick accounting of the time_offset actually imparted to the clock, and no overrun. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Assisted-by: Kiro:claude-opus-4.8 Link: https://patch.msgid.link/20260621220051.1030462-5-dwmw2@infradead.org
2026-07-10timekeeping: Account for clocksource tick quantisation via NTPDavid Woodhouse1-3/+5
cycle_interval is an integer number of counter cycles per NTP interval, so the real time it represents differs from the nominal NTP_INTERVAL_LENGTH by up to half a counter period. For coarse clocksources this is significant: the 3.579545 MHz ACPI PM timer at HZ=1000 rounds 3579.545 cycles up to 3580, making each tick 1.000127 ms (+127 PPM). Commit a386b5af8edd ("time: Compensate for rounding on odd-frequency clocksources") introduced xtime_remainder to compensate for exactly this, citing the same 127 PPM ACPI PM example. The compensation is correct and necessary, but it was applied inside the timekeeping accumulation in timekeeping.c: subtracted in the mult computation in timekeeping_adjust() and folded into the ntp_error update in logarithmic_accumulation(). That keeps the base rate correct and leaves NTP its full symmetric +/-MAXFREQ range rather than +373/-627 PPM, but the NTP code in ntp.c never sees it: tick_length is computed without the correction, so ntp.c's notion of how long a tick is disagrees with the rate timekeeping actually produces. Make the offset an explicit part of the NTP tick_length instead. Add ntp_data::cs_tick_adj, a fixed per-second addend that ntp_update_frequency() includes alongside ntp_tick_adj and time_freq. tk_setup_internals() computes it from the difference between the real cycle_interval duration and the nominal interval, stores it in the timekeeper, and hands it to NTP through a new argument to ntp_clear() -- which already recomputes the frequency and is invoked after every clocksource (re)configuration. timekeeping_init() now uses TK_UPDATE_ALL for this; clearing NTP there is otherwise redundant since ntp_init() has just initialised it. ntp.c now computes the true tick rate, giving a single source of truth. Like ntp_tick_adj, cs_tick_adj stays internal to the kernel: userspace still sees the nominal 1.000000 ms tick via adjtimex and is unaware of the addends. timekeeping_adjust() and logarithmic_accumulation() use ntp_tick / xtime_interval directly, and xtime_remainder is removed. The base-rate arithmetic is unchanged: ntp_tick becomes xtime_interval << ntp_error_shift, so the mult division yields the same base mult and the ntp_error accumulation still nets to zero per tick. Beyond the cleanup of treating all the tick_length contributions (nominal interval, ntp_tick_adj, cs_tick_adj, time_freq) consistently as addends in one place, it also prepares for feed-forward discipline: a future timekeeping_set_reference() will set tick_length to track an absolute external reference such as a vmclock, and that path needs ntp.c to own a tick_length that already reflects the clocksource quantisation, with no hidden correction applied elsewhere. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Assisted-by: Kiro:claude-opus-4.8 Acked-by: John Stultz <jstultz@google.com> Link: https://patch.msgid.link/20260621220051.1030462-4-dwmw2@infradead.org