summaryrefslogtreecommitdiff
path: root/include/linux
AgeCommit message (Collapse)AuthorFilesLines
2026-07-09mm: page_reporting: allow driver to set batch capacityMichael S. Tsirkin1-1/+3
At the moment, if a virtio balloon device has a page reporting vq but its size is < PAGE_REPORTING_CAPACITY (32), the balloon driver fails probe. But, there's no way for host to know this value, so it can easily create a smaller vq and suddenly adding the reporting capability to the device makes all of the driver fail. Not pretty. Add a capacity field to page_reporting_dev_info so drivers can control the maximum number of pages per report batch. In virtio-balloon, set the capacity to the reporting virtqueue size, letting page_reporting adapt to whatever the device provides. Capacity need not be a power of two. Code previously called out division by PAGE_REPORTING_CAPACITY as cheap since it was a power of 2, but no performance difference was observed with non-power-of-2 values. If capacity is 0 or exceeds PAGE_REPORTING_CAPACITY, it defaults to PAGE_REPORTING_CAPACITY. The 0 check and the clamping is done in page_reporting_register(), before the reporting work is scheduled, so we never get division by 0. Link: https://lore.kernel.org/444c24cf39f3f3620fc90ef4695bd6b0979f4c4b.1783232420.git.mst@redhat.com Fixes: b0c504f15471 ("virtio-balloon: add support for providing free page reports to host") Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Assisted-by: Claude:claude-opus-4-6 Acked-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Gregory Price <gourry@gourry.net> Acked-by: Zi Yan <ziy@nvidia.com> Reviewed-by: Pankaj Gupta <pankaj.gupta@amd.com> Cc: Alexander Duyck <alexander.h.duyck@linux.intel.com> Cc: Brendan Jackman <jackmanb@google.com> Cc: Eugenio Pérez <eperezma@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vlastimil Babka <vbabka@kernel.org> Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-09MAINTAINERS: s/SeongJae/SJ/SJ Park1-2/+0
My legal and preferred first names are SeongJae and SJ, respectively. I was using the legal name for commits and tags, while using the preferred name for conversations. It sometimes confuses people including myself. Consistently use the preferred name. Together remove copyright notes on files. Those are only confusing for people who are not familiar with the law. Meanwhile, we can infer the information in a better way from git logs and public information. Link: https://lore.kernel.org/20260630013820.143366-1-sj@kernel.org Signed-off-by: SJ Park <sj@kernel.org> Acked-by: Lorenzo Stoakes <ljs@kernel.org> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Cc: Liam R. Howlett <liam@infradead.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vlastimil Babka <vbabka@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-09remoteproc: qcom_q6v5_pas: Switch over to generic PAS TZ APIsSumit Garg1-3/+3
Switch qcom_q6v5_pas client driver over to generic PAS TZ APIs. Generic PAS TZ service allows to support multiple TZ implementation backends like QTEE based SCM PAS service, OP-TEE based PAS service and any further future TZ backend service. Since qcom_q6v5_pas depends on MDT loader for PAS firmware loading, it has to be switched over to generic PAS APIs in this commit to avoid any build issues. Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Tested-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> # Lemans Tested-by: Vignesh Viswanathan <vignesh.viswanathan@oss.qualcomm.com> # IPQ9650 Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260702115835.167602-5-sumit.garg@kernel.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-09Merge branch '20260702115835.167602-2-sumit.garg@kernel.org' of ↵Bjorn Andersson1-0/+43
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into rproc-next Merge Qualcomm generic pas service from SoC topic branch to faciliate dependencies for the upcoming remoteproc driver changes.
2026-07-09Merge branch '20260702115835.167602-2-sumit.garg@kernel.org' into ↵Bjorn Andersson1-0/+43
drivers-for-7.3 Merge the introduction of the generic Qualcomm Peripheral Authentication Service abstraction through a topic branch, in order to allow it to be pulled into other subsystems.
2026-07-09firmware: qcom: Add a generic PAS serviceSumit Garg1-0/+43
Qcom platforms has the legacy of using non-standard SCM calls splintered over the various kernel drivers. These SCM calls aren't compliant with the standard SMC calling conventions which is a prerequisite to enable migration to the FF-A specifications from Arm. OP-TEE as an alternative trusted OS to Qualcomm TEE (QTEE) can't support these non-standard SCM calls. And even for newer architectures using S-EL2 with Hafnium support, QTEE won't be able to support SCM calls either with FF-A requirements coming in. And with both OP-TEE and QTEE drivers well integrated in the TEE subsystem, it makes further sense to reuse the TEE bus client drivers infrastructure. The added benefit of TEE bus infrastructure is that there is support for discoverable/enumerable services. With that client drivers don't have to manually invoke a special SCM call to know the service status. So enable the generic Peripheral Authentication Service (PAS) provided by the firmware. It acts as the common layer with different TZ backends plugged in whether it's an SCM implementation or a proper TEE bus based PAS service implementation. Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Tested-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> # Lemans Reviewed-by: Harshal Dev <harshal.dev@oss.qualcomm.com> Tested-by: Vignesh Viswanathan <vignesh.viswanathan@oss.qualcomm.com> # IPQ9650 Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260702115835.167602-2-sumit.garg@kernel.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-09Merge tag 'net-7.2-rc3' of ↵Linus Torvalds1-0/+5
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Paolo Abeni: "Including fixes from netfilter, Bluetooth and batman-adv. Current release - regressions: - bluetooth: fix using chan->conn as indication to no remote netdev Current release - new code bugs: - netfilter: cap to maximum number of expectation per master on updates Previous releases - regressions: - bluetooth: - fix UAF of hci_conn_params in add_device_complete - fix null ptr deref in hci_abort_conn() - igmp: remove multicast group from hash table on device destruction - batman-adv: prevent TVLV OOB check overflow - eth: mlx5/mlx5e: - fix off-by-one in single-FDB error rollback - skip peer flow cleanup when LAG seq is unavailable - fix crashes in dynamic per-channel stats and HV VHCA agent - eth: mana: Sync page pool RX frags for CPU Previous releases - always broken: - netfilter: - mark malformed IPv6 extension headers for hotdrop - terminate table name before find_table_lock() - ipvs: use parsed transport offset in TCP state lookup - sched: act_pedit: fix TOCTOU heap OOB write in tc offload - ethtool: rss: fix hfunc and input_xfrm parsing on big endian - ipv4/ipv6: fix UAF and memory leak in IGMP/MLD - tls: consume empty data records in tls_sw_read_sock() - eth: - octeontx2-af: fix VF bringup affecting PF promiscuous state - gue: validate REMCSUM private option length" * tag 'net-7.2-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (94 commits) macsec: don't read an unset MAC header in macsec_encrypt() dibs: loopback: validate offset and size in move_data() octeontx2-af: fix VF bringup affecting PF promiscuous state ethtool: rss: Fix hfunc and input_xfrm parsing on big endian net/mlx5: Fix L3 tunnel entropy refcount leak net: macb: drop in-flight Tx SKBs on close net: mana: Sync page pool RX frags for CPU net: mana: Validate the packet length reported by the NIC selftests/net: fix EVP_MD_CTX leak in tcp_mmap ipvs: ensure inner headers in ICMP errors are in headroom ipvs: use parsed transport offset in SCTP state lookup ipvs: use parsed transport offset in TCP state lookup ipvs: pass parsed transport offset to state handlers netfilter: handle unreadable frags netfilter: flowtable: support IPIP tunnel with direct xmit netfilter: flowtable: IPIP tunnel hardware offload is not yet support netfilter: flowtable: use dst in this direction when pushing IPIP header netfilter: ipset: allocate the proper memory for the generic hash structure netfilter: ipset: cleanup the add/del backlog when resize failed netfilter: ipset: exclude gc when resize is in progress ...
2026-07-09ACPI/IORT: Implement ACPI infrastructure to enable GICv5 IWB probe deferralLorenzo Pieralisi1-1/+2
Implement an IORT ACPI hook to retrieve the acpi_handle of the interrupt controller handling a specific GSI (if any, on GICv5 systems only the IWB is represented in firmware with an ACPI device object) and add the IWB to the list of devices whose dependencies can be detected (and cleared) in ACPI core to guarantee that probe dependencies for the IWB can be satisfied. Enable autodep detection for arm64 by adding the arch_acpi_add_auto_dep() callback in the ACPI IORT driver. Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Link: https://patch.msgid.link/20260709-gic-v5-acpi-iwb-probe-deferral-v4-6-48dae790f871@kernel.org Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-07-09ACPI: irq: Move RISC-V interrupt controllers autodep to ACPI IRQ codeLorenzo Pieralisi1-1/+4
RISC-V implements arch code to detect probe dependencies for devices and the interrupt controller the devices GSIs are routed to. The code itself is arch agnostic apart from an arch specific helper function required to retrieve the acpi_handle of the interrupt controller that manages the device GSI interrupt. In order to enable IRQ probe dependencies detection on other architectures, move RISC-V IRQ probe dependency detection code to generic ACPI IRQ code. Allow interrupt controller drivers to register an arch specific function to determine the acpi_handle for a specific GSI number to use the mechanism if needed by the respective interrupt controller drivers. Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Reviewed-by: Sunil V L <sunilvl@oss.qualcomm.com> Tested-by: Sunil V L <sunilvl@oss.qualcomm.com> Link: https://patch.msgid.link/20260709-gic-v5-acpi-iwb-probe-deferral-v4-5-48dae790f871@kernel.org Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-07-09ACPI: Add acpi_device_clear_deps() helper functionLorenzo Pieralisi1-0/+8
Code clearing device dependencies in ACPI in drivers through acpi_dev_clear_dependencies() requires annoying ifdeffery to make sure it is compiled out on !CONFIG_ACPI configurations. Implement a wrapper function to clear device dependencies that can be used in device drivers without conditional compilation. Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Link: https://patch.msgid.link/20260709-gic-v5-acpi-iwb-probe-deferral-v4-1-48dae790f871@kernel.org Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-07-09net: phy: Drop #inclusion of <linux/mod_devicetable.h> from <linux/mdio.h>Uwe Kleine-König (The Capable Hub)1-1/+0
<linux/mdio.h> itself doesn't use any of the device id structures. The files #including <linux/mdio.h> use a variety of them: $ git grep -l '<linux/mdio.h>' | xargs grep --color -E '\<(acpi_device_id|amba_id|ap_device_id|apr_device_id|auxiliary_device_id|bcma_device_id|ccw_device_id|cdx_device_id|coreboot_device_id|css_device_id|dfl_device_id|dmi_(device|system)_id|eisa_device_id|fsl_mc_device_id|hda_device_id|hid_device_id|hv_vmbus_device_id|i2c_device_id|i3c_device_id|ieee1394_device_id|input_device_id|ipack_device_id|isapnp_device_id|ishtp_device_id|mcb_device_id|mdio_device_id|mei_cl_device_id|mhi_device_id|mips_cdmm_device_id|of_device_id|parisc_device_id|pci_device_id|pci_epf_device_id|pcmcia_device_id|platform_device_id|pnp_(card_)?device_id|rio_device_id|rpmsg_device_id|sdio_device_id|sdw_device_id|serio_device_id|slim_device_id|spi_device_id|spmi_device_id|ssam_device_id|ssb_device_id|tb_service_id|tee_client_device_id|typec_device_id|ulpi_device_id|usb_device_id|vchiq_device_id|virtio_device_id|wmi_device_id|x86_(cpu|device)_id|zorro_device_id|cpu_feature)\>' ... but none of them relies on <linux/mdio.h>'s #include. <linux/mod_devicetable.h> is a bad header mixing many different device id structures and thus is an unfortunate dependency because if e.g. struct wmi_device_id is modified all users of <linux/mdio.h> need to be recompiled despite none of them using struct wmi_device_id. So drop the unused header. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/ca270a534d0f230a939a3fb4a661808b35d6436d.1783329817.git.u.kleine-koenig@baylibre.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-08bpf: Introduce jit_required flag and remove bpf_prog_has_kfunc_call()Tiezhu Yang1-7/+2
Introduce a 'jit_required' bitfield flag in struct bpf_prog to track whether a BPF program strictly requires the JIT compiler to run. This prevents a dangerous runtime fallback to the interpreter for features that are only implemented in the JIT compiler. Currently, bpf_prog_has_kfunc_call() is used only for kernel function calls, replace the kfunc-specific helper with the new 'jit_required' flag. This makes it easy to support other JIT-only BPF features, such as inlined helpers. Suggested-by: Alexei Starovoitov <ast@kernel.org> Suggested-by: KaFai Wan <kafai.wan@linux.dev> Suggested-by: Leon Hwang <leon.hwang@linux.dev> Acked-by: Leon Hwang <leon.hwang@linux.dev> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
2026-07-09mmc: core: add NXP IW61x base ID and block size quirkJeff Chen1-0/+1
The NXP IW61x series SDIO chipset identifies itself with a base card ID (0x0204) during the initial MMC bus scan, while the specific WLAN function reports a different ID (0x0205). To ensure that the MMC_QUIRK_BLKSZ_FOR_BYTE_MODE quirk is correctly inherited by all SDIO functions (including Wi-Fi), it must be attached to the base card ID at the core level. Add the SDIO_DEVICE_ID_NXP_IW61X_BASE definition and apply the required fixup in the SDIO quirk table. Signed-off-by: Jeff Chen <jeff.chen_1@nxp.com>
2026-07-09efi: fix stale reference to efi_recover_from_page_fault()Breno Leitao1-2/+2
efi_recover_from_page_fault() was renamed to efi_crash_gracefully_on_page_fault(), but the comment above enum efi_rts_ids was not updated. Use the current name. Fixes: c46f52231e79 ("x86/{fault,efi}: Fix and rename efi_recover_from_page_fault()") Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2026-07-08KVM: x86: Treat a vCPU as unreachable if its index is invalidSean Christopherson1-0/+1
In the "vCPU locked or unreachable" lockdep assertion, treat a vCPU as unreachable if its index is invalid, i.e. if the vCPU is in the process of being created. Until the vCPU is inserted into the array of vCPUs, the only way to get at the vCPU is via kvm_vm_ioctl_create_vcpu(). Note, the actual index is set _before_ adding the vCPU to the array, i.e. there's no risk of a false negative on the lockdep assertion. Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Link: https://patch.msgid.link/20260630225619.511632-10-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-08KVM: Move nVMX's lockdep logic for vcpu->mutex to a common helperSean Christopherson1-0/+6
Extract nVMX's lockdep assertion that a vCPU is locked or otherwise unreachable into a common helper, as KVM x86 is about to gain another user, but there is nothing x86-specific about the logic, i.e. the assertion may be useful for other architectures. No functional change intended. Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Link: https://patch.msgid.link/20260630225619.511632-9-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-08SUNRPC: pin upper rpc_clnt across the TLS connect_workerChuck Lever1-0/+1
The TLS connect path has a use-after-free: nothing pins the upper rpc_clnt across the delayed connect_worker. xs_connect() stores task->tk_client in sock_xprt::clnt as a raw pointer and queues the worker; for TLS-secured transports that worker is xs_tcp_tls_setup_socket(), which reads several fields out of the saved pointer (cl_timeout, cl_program, cl_prog, cl_vers, cl_cred, cl_stats) to construct the args for the inner handshake rpc_clnt. The xprt does not reference the rpc_clnt; the rpc_clnt references the xprt. xs_destroy() does cancel the connect_worker, but it runs only when the xprt's refcount drops to zero, which cannot happen until the rpc_clnt releases its cl_xprt reference in rpc_free_client_work(). When a TLS handshake fails fatally (for example, an mTLS mount whose client cert does not match the server), the connecting task is woken with -EACCES and exits, the mount caller invokes rpc_shutdown_client(), and the upper rpc_clnt is freed before the queued connect_worker fires. xs_tcp_tls_setup_socket() then dereferences the freed clnt, producing the refcount_t underflow Michael Nemanov reported. Take a reference on the upper rpc_clnt in xs_connect() for TLS transports via a new rpc_hold_client() helper, and drop it in the connect_worker's exit path with rpc_release_client(). The xprt_lock_connect() / xprt_unlock_connect() pairing already serialises xs_connect() with xs_tcp_tls_setup_socket(), so the take and release are balanced one-for-one. The non-TLS connect worker (xs_tcp_setup_socket) never reads sock_xprt::clnt, so leave that path alone and avoid the clnt-holds-xprt-holds-clnt cycle that would otherwise prevent xprt destruction. Reported-by: Michael Nemanov <michael.nemanov@vastdata.com> Closes: https://lore.kernel.org/linux-nfs/40e3d522-dfcf-4fc1-9c55-b5e81f1536d5@vastdata.com/ Fixes: 75eb6af7acdf ("SUNRPC: Add a TCP-with-TLS RPC transport class") Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Tested-by: Michael Nemanov <michael.nemanov@vastdata.com> Reviewed-by: Michael Nemanov <michael.nemanov@vastdata.com> Signed-off-by: Anna Schumaker <anna.schumaker@hammerspace.com>
2026-07-08libbpf: Drop in-loader metadata check for load-time verificationDaniel Borkmann1-1/+0
The signed gen_loader used to police its own metadata map from within BPF: emit_signature_match() read the kernel-cached map->sha[] back through hardcoded struct bpf_map offsets and compared it against a hash that compute_sha_update_offsets() baked into the signed instructions, after a BPF_OBJ_GET_INFO_BY_FD round-trip to populate map->sha[]. The kernel now verifies the metadata at BPF_PROG_LOAD time by folding the frozen contents of the loader's exclusive fd_array maps into the signature, so the loader no longer checks anything itself. Generated loaders thus carry no verification logic of their own anymore: Nothing in the signing chain depends on emitted loader bytecode doing the right thing. On the loading side, skel_internal.h now sets fd_array_cnt for a signed load so the kernel scans fd_array for the exclusive metadata map - still frozen, as the kernel requires - and the BPF_OBJ_GET_INFO_BY_FD round-trip to populate map->sha[] is gone. The struct bpf_map layout BUILD_BUG_ON()s on the kernel side are removed as well: they only pinned the ABI for the in-BPF read of map->sha[] that is no longer needed. Same for the map->excl member. Note: gen_hash is retained; it still marks a loader as signed so an untrusted host cannot re-dimension maps or override initial values now covered by the signature. Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20260708075343.358712-4-daniel@iogearbox.net Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-08bpf: Verify signed loader metadata at load timeDaniel Borkmann1-0/+1
A signed gen_loader program carries the programs, maps and relocations it installs in a metadata array map. The loader instructions are covered by the PKCS#7 signature, but the metadata map is not: Today the loader compares the map contents from within BPF against a hash baked into its (signed) instructions, using the kernel-cached map hash. The kernel itself never actually attests that the metadata the loader installs is the metadata that was signed. This split is the core of the long-standing objection to the BPF signing scheme from the LSM / integrity side: the integrity check of a light skeleton only completes once the loader program runs, that is, after the security_bpf_prog_load() hook, so at admission time an LSM observes a program whose payload has not yet been verified. Auditing the chain link is also not a purely cryptographic operation: whoever signs or reviews an lskel has to disassemble the loader's preamble to convince themselves that the embedded hash check is present and correct [0][1]. Two acceptable fixes were identified in those threads: Complete the integrity check before the admission hook fires, or add a second hook that collects the verification result after the loader ran [2]. Covering both the loader and its maps directly with the PKCS#7 signature is what Blaise Boscaccy's patchsets proposed in several forms. Let's implement the former, without growing the UAPI, and in particular as a single unified scheme where the signature spans the raw bytes rather than derived hashes. A signed loader binds its metadata map(s) through the existing fd_array, and an exclusive map is already bound to a program digest (excl_prog_hash). So when a signature is present, collect the exclusive maps from fd_array and append their frozen contents to the instructions before verification: The signature now covers insns || metadata_0 || metadata_1 || [...] in the fd_array order, and verification completes in bpf_check(), once the fd_array maps are resolved into used_maps, before the LSM admission hook and the rest of verification. A program is either BPF_SIG_UNSIGNED or BPF_SIG_VERIFIED, with nothing in between. While folding the fd_array maps, a non-exclusive map bound to a signed program is rejected, so every map folded into the signature is exclusive. A signed loader that fails to cover its metadata thus does not load, and BPF_SIG_VERIFIED always means the instructions and every exclusive map are authentic. The maps must be frozen so the hashed bytes cannot change before the loader runs; the map <-> program digest binding is enforced by the verifier for every used map. Binding maps through fd_array_cnt makes the verifier resolve and excl-check them (excl_prog_sha vs prog->digest) before it would otherwise compute the digest, so compute prog->digest up front in bpf_check(), over the unmodified instructions the signature covers, for a load that folds metadata. Unsigned programs are not affected by the signature path; for them the LSM admission hook merely moves below fd_array resolution, with minimal bounded work in between. Note, signed loaders generated by older libbpf/ bpftool versions need to be regenerated; some of the recent fixes we've had on the signed loader side require the latter already to close gaps. Finally, some remarks around the security_bpf_prog_load() placement given there was discussion on whether a new hook is needed or the existing security_bpf_prog() hook should be reused [3]: For a new hook it would mean that just for loading a single BPF program it has to pass through four layers of LSM hooks: 1) security_bpf (cmd=PROG_LOAD): for gating various bpf subcmds 2) security_bpf_prog_load: historical admission hook (CAP/token, prog_type, attach point), pre-verification 3) security_bpf_prog_verify_signature: newly asked admission hook, same role as 2), plus the BPF signature verdict 4) security_bpf_prog: gate handing the prog fd back to userspace, verification done & signature verified The use-cases of 2) and 3) conflate, thus BPF community prefers to just keep a total of 3 LSM hooks (as-is today): 3) makes 2) incoherent given they are the /same class/ of hook, that is, access-control admission on the load and split only by _what_ they can see. Worse, with the split, for a signed BPF program security_bpf_prog_load 2) admits a program whose signature has not been checked, so a policy gating at 2) is structurally unable to express "admit only verified" and every such policy is forced onto 3) *anyway*. In other words, one doesn't get two complementary hooks, but rather, one real admission hook aka 3) plus a now-degraded /legacy/ hook 2) that can't answer the question operators actually want to ask. Reusing security_bpf_prog() 4) for admission is no alternative either: it fires only after the entire verifier (and JIT) pipeline ran, so denying a not-yet-verified program at that point burns exactly the work a denial is supposed to avoid, and by then the program has an id assigned and the kallsyms/perf/audit load events fired. Policies are free to also consume the signature verdict at 4), but admission control belongs into security_bpf_prog_load(). Hence the latter remains the only admission hook, merely moved past signature verification; with moving large allocations further down into the BPF verifier, there is now only minimal work between the old and new location: The preparation work in bpf_check() is reordered such that only the minimally necessary setup happens up front: Allocating the env, initializing the verifier log and resolving the fd_array that a signed BPF metadata map needs. The worst case allocation up until security_bpf_prog_load() is ~90K which is the env itself (~54K) plus the continuous fd_array cache (at most 32K). The insn_aux_data array is moved into a later stage in the verification. Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/2f71d6c03698eb17d51f7247efde777627ee578a.camel@HansenPartnership.com [0] Link: https://lore.kernel.org/lkml/ecf0521ed302db672672ebfbc670ecfba36a6e00.camel@HansenPartnership.com [1] Link: https://lore.kernel.org/bpf/88703f00d5b7a779728451008626efa45e42db3d.camel@HansenPartnership.com [2] Link: https://lore.kernel.org/bpf/DJOFY21DYUI4.19WKQ3NPZ4H5R@gmail.com [3] Link: https://lore.kernel.org/bpf/20260708075343.358712-3-daniel@iogearbox.net Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-08bpf: Resolve and cache fd_array objects at load timeDaniel Borkmann1-1/+21
The fd_array passed to BPF_PROG_LOAD carries the map and module BTF file descriptors a program binds. The verifier reads it more than once during a load: process_fd_array() walks it to bind the maps and BTFs, and check_and_resolve_insns() and the kfunc BTF resolver later read it again to resolve the program's BPF_PSEUDO_MAP_IDX* and module kfunc refs. For signed BPF, we need these upfront in memory, thus resolve each fd to its object once and cache it by fd_array index, then bind that cached object for the rest of the load. env->fd_array becomes a small per-slot {map, btf} cache rather than a bpfptr_t; every later reference is then an in-bounds lookup of an already-resolved object, and an index outside the cache is rejected instead of read from user memory: - continuous (fd_array_cnt given): the caller declares the length and every entry is resolved and bound up front (used also by the BPF signed loader) - sparse (no fd_array_cnt): left as the legacy path with no fd_array cache; each reference reads its fd from the caller's fd_array and resolves it on the spot. Deduplication in used_maps and the kfunc BTF table keeps this correct, and only unsigned programs use this shape. Split these into separate helpers to make it easier to follow. Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Anton Protopopov <a.s.protopopov@gmail.com> Link: https://lore.kernel.org/bpf/20260708075343.358712-2-daniel@iogearbox.net Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-08usb: typec: Add helper to check cable altmode supportAndrei Kuchynski1-0/+1
Introduce typec_cable_altmode_unsupported function to evaluate whether an alternate mode is restricted based on the connected cable's properties. Implement validation logic that parses the cable's identity to catch incompatible setups early. Alternate modes are restricted over: - cables lacking an identity header - passive cables with USB 2.0 speed - active cables unless they have corresponding plugs The function returns false if the cable is not registered or the identifier is not set. Suggested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Andrei Kuchynski <akuchynski@chromium.org> Reviewed-by: Benson Leung <bleung@chromium.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://patch.msgid.link/20260626142702.1941182-2-akuchynski@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-08tick: Remove arch_needs_cpuMete Durlu1-3/+0
Remove unused arch_needs_cpu() hook. No architectures use it after s390 removed its use case. Suggested-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Mete Durlu <meted@linux.ibm.com> Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Reviewed-by: Thomas Gleixner <tglx@kernel.org> Acked-by: Rafael J. Wysocki (Intel) <rafael@kernel.org> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-07-08ipv4: igmp: Fix potential UAF in igmp_gq_start_timer()Eric Dumazet1-0/+5
A race condition exists between device teardown (inetdev_destroy) and incoming IGMP query processing (igmp_rcv), leading to a Use-After-Free in the IGMP timer callback. During device destruction, inetdev_destroy() drops the primary reference to in_device, which can drop its refcount to 0. The actual freeing of in_device memory is deferred via RCU (using call_rcu()). Concurrently, igmp_rcv() runs under RCU read lock and obtains the in_device pointer. Because the memory is RCU-protected, CPU-0 can safely dereference in_device even if its refcount has hit 0. However, if CPU-0 calls igmp_gq_start_timer() and re-arms the timer, it attempts to acquire a reference using in_dev_hold(). This increments the refcount from 0 to 1, triggering a "refcount_t: addition on 0" warning. Since the in_device memory is still scheduled to be freed after the RCU grace period (as the free callback does not check the refcount again), the device is freed while the timer is still armed. When the timer expires, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not arm the timer. A similar issue in IPv6 MLD is fixed in a subsequent patch. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Zero Day Initiative <zdi-disclosures@trendmicro.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260705181756.963063-2-edumazet@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-08Merge drm/drm-next into drm-misc-nextThomas Zimmermann114-1035/+1632
Backmerging to get updates from v7.2-rc2 into drm-misc-next. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2026-07-08iomap: add helper to mark folio uptodateJoanne Koong1-0/+1
Add an exported helper iomap_folio_mark_uptodate() to mark a folio as uptodate and update its uptodate bitmap if the folio has iomap state data attached. This is needed because there are some filesystems (eg fuse) that have paths outside of conventional iomap calls that need to mark a folio as uptodate (eg writing server-pushed data directly into the page cache) and need the iomap-internal uptodate bitmap to be in sync with the uptodate state of the folio. Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Joanne Koong <joannelkoong@gmail.com> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2026-07-08syscall_user_dispatch: Make it configurable in KconfigGregory Price3-7/+29
Syscall User Dispatch is presently built under CONFIG_GENERIC_SYSCALL and cannot be disabled independently. Add CONFIG_SYSCALL_USER_DISPATCH to make it an optional feature. Signed-off-by: Gregory Price <gourry@gourry.net> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260706140020.873735-2-gourry@gourry.net
2026-07-08mmc: sdio: add Morse Micro vendor idsLachlan Hodges1-0/+3
Add the Morse Micro mm81x series vendor ids. Acked-by: Ulf Hansson <ulfh@kernel.org> Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
2026-07-07timekeeping: Move the vDSO update declarations into a private headerThomas Weißschuh1-19/+0
All architectures are now fully using the generic vDSO infrastructure. They don't need these declarations anymore to implement the functions in architecture-specific code. Move them to the private header. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260707-timekeeping-header-cleanup-v1-2-e85ad96409a9@linutronix.de
2026-07-07timekeeping: Fold vdso_time_update_aux() declarations into the generic ifdefferyThomas Weißschuh1-6/+4
The only caller of vdso_time_update_aux() is already gated behind CONFIG_POSIX_AUX. The additional check in the header files is not necessary. Remove it and then fold the declarations into the existing CONFIG_GENERIC_GETTIMEOFDAY ifdeffery. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260707-timekeeping-header-cleanup-v1-1-e85ad96409a9@linutronix.de
2026-07-07hrtimer: Remove inclusion of hrtimer_bases.h remove from hrtimer.hThomas Weißschuh (Schneider Electric)1-1/+0
hrtimer.h is used all over the kernel. Any change to hrtimer_bases.h effectively triggers a full rebuild. As all logical dependencies from hrtimer.h to hrtimer_bases.h have been removed, the inclusion is now unncessary. Remove it. Signed-off-by: Thomas Weißschuh (Schneider Electric) <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260702-hrtimer-header-dependencies-v1-8-c50b19bda473@linutronix.de
2026-07-07hrtimer: Explicitly include some necessary headers in hrtimer_rearm.hThomas Weißschuh (Schneider Electric)1-0/+5
Multiple used types and symbols are only visible through transitive dependency chains. Include the headers explicitly as those chains are going to go away. Signed-off-by: Thomas Weißschuh (Schneider Electric) <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260702-hrtimer-header-dependencies-v1-6-c50b19bda473@linutronix.de
2026-07-07hrtimer: Move hrtimer_update_function() to hrtimer.cThomas Weißschuh (Schneider Electric)1-22/+2
The usage of the hrtimer base forces hrtimer.h to also expose the base structure definitions. Move the function to hrtimer.c to avoid this. Signed-off-by: Thomas Weißschuh (Schneider Electric) <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260702-hrtimer-header-dependencies-v1-3-c50b19bda473@linutronix.de
2026-07-07hrtimer: Move hrtimer_callback_running() to hrtimer_bases.hThomas Weißschuh (Schneider Electric)2-9/+10
The usage of the hrtimer base introduces a dependency on the timer base structure definitions from the widely-used hrtimer.h. Move the helper to hrtimer_bases.h to trim this dependency. Also adapt the two only callers to now include hrtimer_bases.h. Signed-off-by: Thomas Weißschuh (Schneider Electric) <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260702-hrtimer-header-dependencies-v1-2-c50b19bda473@linutronix.de
2026-07-07hrtimer: Rename hrtimer_defs.h to hrtimer_bases.hThomas Weißschuh (Schneider Electric)2-3/+3
This header was originally added for #defines and was later extended with the hrtimer base structures. All the #defines have been removed in the meantime, so the naming is off now. Rename the header to fit its contents more. This will also make the upcoming addition of some functions nicer. Signed-off-by: Thomas Weißschuh (Schneider Electric) <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260702-hrtimer-header-dependencies-v1-1-c50b19bda473@linutronix.de
2026-07-07genirq: Remove unnecessary NULL check of the kstat_irqs fieldRadu Rendec1-1/+1
The kstat_irqs field of struct irq_desc is used to store a per-cpu count of interrupt events. It is initialized in init_desc(), along with all the other fields in struct irq_desc that need explicit initialization, and therefore it's always available (non-NULL) for any valid interrupt descriptor (with a caveat - see below). When CONFIG_SPARSE_IRQ is enabled, all interrupt descriptors are always allocated dynamically via alloc_desc(), which calls init_desc(), so in that case kstat_irqs is guaranteed to be non-NULL before a valid struct irq_desc pointer is even returned. By contrast, when CONFIG_SPARSE_IRQ is disabled, interrupt descriptors are allocated statically in the irq_desc[] array, and kstat_irqs is initialized implicitly to NULL. The per-cpu pointer is initialized only later, for all descriptors, via start_kernel() -> early_irq_init() -> init_desc(). The kstat_irqs field is used mostly for printing interrupt statistics (i.e. reading /proc/interrupts), and that cannot happen until much later, when user-space is fully initialized. So, there is no concern with that use case. The list below includes all functions where the NULL check is removed, along with a list of all possible call chains and/or a brief explanation of why it's safe to remove the NULL check in that case. * irq_desc_kstat_cpu() [include/linux/irqdesc.h] - All direct call sites use it for printing IRQ statistics. - Indirect call site: per_cpu_count_show() - also used for printing interruptstatistics. * kstat_irqs_cpu() [kernel/irq/irqdesc.c] - Called by sun3_int7() and sun3_int5() [arch/m68k/sun3/sun3ints.c] These are interrupt handlers and cannot be called until their corresponding interrupts are initialized in sun3_init_IRQ(). The call chain leading to that is: start_kernel() -> init_IRQ() [arch/m68k/kernel/ints.c] -> mach_init_IRQ = sun3_init_IRQ() The init_IRQ() call happens right *after* the early_irq_init() call, which means the descriptors are already fully initialized by the time the interrupt handlers are even registered. - Called by show_interrupts() [arch/s390/kernel/irq.c] - used for printing interrupt statistics. * kstat_irqs() [kernel/irq/irqdesc.c] The only possible call chain is via fs/proc/stat.c: stat_open() -> show_stat() -> show_all_irqs() -> kstat_irqs_usr() -> kstat_irqs() It is used for printing interrupt statistics. * kstat_snapshot_irqs() The only possible call chain is via kernel/watchdog.c: watchdog_timer_fn() -> is_softlockup() -> start_counting_irqs() -> kstat_snapshot_irqs() The watchdog timer cannot fire early, before early_irq_init(). * kstat_get_irq_since_snapshot() The only possible call chain is via kernel/watchdog.c: watchdog_timer_fn() -> report_cpu_status() -> print_irq_counts() -> kstat_get_irq_since_snapshot() The watchdog timer cannot fire early, before early_irq_init(). Signed-off-by: Radu Rendec <radu@rendec.net> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260705210951.2717741-2-radu@rendec.net
2026-07-07cred: delete task_euid()Alice Ryhl1-1/+0
task_euid() is a very weird operation. You can see how weird it is by grepping for task_euid() - binder is its only user. task_euid() obtains the objective effective UID - it looks at the credentials of the task for purposes of acting on it as an object, but then accesses the effective UID (which the credentials.7 man page describes as "[...] used by the kernel to determine the permissions that the process will have when accessing shared resources [...]"). Since usage in Binder has now been removed, get rid of the resulting dead code. Changes to the zh_CN translation was carried out with the help of Gemini and Google Translate, and since adjusted as per Alex Shi's feedback. Suggested-by: Jann Horn <jannh@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
2026-07-07bpf: Reject MEM_ALLOC BTF accesses past object boundsYiyang Chen1-1/+1
BTF struct walks relax the struct-size check for accesses through a trailing flexible array. That is valid for ordinary BTF type walking, but PTR_TO_BTF_ID | MEM_ALLOC values point to objects allocated with the static BTF type size. When walking a MEM_ALLOC object, reject the access before applying the flexible-array relaxation if the access range extends past the struct size. Apply the same policy to struct ID matching so kfunc and kptr type checks do not walk past the allocated object bounds either. Fixes: 958cf2e273f0 ("bpf: Introduce bpf_obj_new") Fixes: 36d8bdf75a93 ("bpf: Add alloc/xchg/direct_access support for local percpu kptr") Signed-off-by: Yiyang Chen <chenyy23@mails.tsinghua.edu.cn> Reviewed-by: Amery Hung <ameryhung@gmail.com> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/bpf/4b8c8a81102ba4b595011434c881194f264ddc59.1782807039.git.chenyy23@mails.tsinghua.edu.cn Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-07tracing: Add a no-rcu-check version of trace_##event##_enabled()Steven Rostedt1-1/+11
Tracepoints require that RCU is watching. To prevent them from being used in places that RCU is not watching, the trace_##event() macro always calls rcu_is_watching() even when the event is not enabled and warns if RCU is not watching. This is to make sure a warning is triggered even if the tracepoint is never enabled (as it is only a bug when it is). It was noticed that tracepoints could be hidden within trace_#event#_enabled() calls, which are used to do extra work for the tracepoint only if the tracepoint is enabled. But this also can hide the fact that a tracepoint is placed in a location that can be called when RCU is not watching. Commit 9764e731ef6ab ("tracepoint: Add lockdep rcu_is_watching() check to trace_##name##_enabled()") added a check to the trace_##event##_enabled() macro to make sure RCU is watching when it is called to make sure not to hide the bug of a tracepoint being called when RCU is not watching. There is one case in the irq_disable tracepoint where it is within a trace_irq_disable_enabled() block, but it checks if RCU is watching, and if it isn't, it makes a call to ct_irq_enter() that makes RCU watch again. But because trace_irq_disable_enabled() now checks if RCU is watching and will trigger if it isn't. This is a false warning as the code within the block handles this case. Add a new internal macro __trace_##event##_enabled() that doesn't check if RCU is watching, and convert the irq_enable/disable tracepoints over to it. Link: https://patch.msgid.link/20260701132744.6a7fc68b@robin Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Closes: https://lore.kernel.org/all/CAMuHMdXud_RpWag_hFqa2ByBGRxg6KnxGL1ObCWZrpTsk3TfAw@mail.gmail.com/ Fixes: 9764e731ef6ab ("tracepoint: Add lockdep rcu_is_watching() check to trace_##name##_enabled()") Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-07-07tracing: Prevent out-of-bounds read in glob matchingHuihui Huang1-0/+1
String event fields are not necessarily NUL-terminated, so the filter predicate functions (filter_pred_string(), filter_pred_strloc() and filter_pred_strrelloc()) pass the field length to the regex match callbacks, and the length-aware matchers honour it. regex_match_glob() was the exception: it ignored the length and called glob_match(), which scans the string until it hits a NUL byte. Some string fields are not NUL-terminated. One example is the dynamic char array of the xfs_* namespace tracepoints, which is copied without a trailing NUL. For such a field, glob matching reads past the end of the event field, causing a KASAN slab-out-of-bounds read in glob_match(), reached via regex_match_glob() and filter_match_preds() from the xfs_lookup tracepoint. Add a length-bounded glob_match_len() and use it from regex_match_glob() so glob matching always stops at the field boundary. The matching loop is factored into a shared helper so glob_match() keeps its behaviour. Fixes: 60f1d5e3bac4 ("ftrace: Support full glob matching") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/da1aaf125fc3b63320b0c540fd6afa7c3d5b4f1a.1782836943.git.hhhuang@smu.edu.sg 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: Huihui Huang <hhhuang@smu.edu.sg> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-07-07firmware: arm_ffa: Fix Endpoint Memory Access Descriptor offset calculationSebastian Ene1-1/+1
Use the descriptor's `ep_mem_offset` to calculate the start of the endpoint memory access array and to comply with the FF-A spec instead of defaulting to `sizeof(struct ffa_mem_region)`. This requires moving `ffa_mem_region_additional_setup()` earlier in the setup flow. Also, add sanity checks to ensure the calculated descriptor offsets do not exceed `max_fragsize`. Fixes: 113580530ee7 ("firmware: arm_ffa: Update memory descriptor to support v1.1 format") Reviewed-by: Sudeep Holla <sudeep.holla@kernel.org> Signed-off-by: Mostafa Saleh <smostafa@google.com> Signed-off-by: Sebastian Ene <sebastianene@google.com> Link: https://patch.msgid.link/20260702103848.1647249-3-sebastianene@google.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-07-07KVM: arm64: Validate the offset to the mem access descriptorSebastian Ene1-0/+7
Prevent the pKVM hypervisor from making assumptions that the endpoint memory access descriptor (EMAD) comes right after the FF-A memory region header. Prior to FF-A version 1.1 the header of the memory region didn't contain an offset to the endpoint memory access descriptor. The layout of a memory transaction looks like this from 1.1 onward: Type | Field name | Offset [ Header | ffa_mem_region | 0 EMAD 1 | ffa_mem_region_attributes) | ffa_mem_region.ep_mem_offset ] Verify that the offset to the first endpoint memory access descriptor is within the mailbox buffer bounds. Also, fix one hardcoded sizeof(struct ffa_mem_region_attributes) that should be replaced ffa_emad_size_get() for compatibility with FFA v1.0. Fixes: 42fb33dde42b ("KVM: arm64: Use FF-A 1.1 with pKVM") Signed-off-by: Mostafa Saleh <smostafa@google.com> Signed-off-by: Sebastian Ene <sebastianene@google.com> Reviewed-by: Vincent Donnefort <vdonnefort@google.com> Link: https://patch.msgid.link/20260702103848.1647249-5-sebastianene@google.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-07-07wifi: mac80211: Route (Re)association req/response to per-STA queueIlan Peer1-0/+11
An association request or response frame is generally delivered to the driver without a TX queue object. However, with drivers that do encryption offload and couple the key with a transmit queue, this means that the frames are not being encrypted. Fix this by routing the association frames to the management TXQ. This will allow the driver to set up the required resources before transmitting the association frame, e.g., set up keys etc. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260706222925.febcc62f485c.Iff932880e4b98232cbf6ba405fbb90d650a85381@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-07x86/setup: do not include kexec_handover.h from asm/setup.hPratyush Yadav (Google)1-5/+1
x86 asm/setup.h includes linux/kexec_handover.h. This is because it is used by setup.c and kaslr.c. But this inclusion is problematic. The header is included in many places, so it results in the KHO header being propagated there. Also, the setup header is used by realmode code. If KHO header includes things like mm.h, it causes a big dump of compilation failures. Nothing in setup.h uses anything from KHO. Remove the header from setup.h, and directly include it in setup.c. which does use things from KHO. Since kaslr.c is a part of the decompressor, avoid including linux headers there directly. Instead, split out struct kho_scratch, which is the only thing the kaslr.c uses, and move it to include/asm-generic/kexec_handover.h. This should also help reduce files recompiled when kexec_handover.h changes. Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org> Acked-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/20260706153751.1166003-1-pratyush@kernel.org Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
2026-07-07Merge tag 'drm-xe-next-2026-07-03' of ↵Dave Airlie1-16/+15
https://gitlab.freedesktop.org/drm/xe/kernel into drm-next UAPI Changes: - Add additional error components to xe drm_ras (Riana) - Drop 'force_execlist' module parameter (Roper) Cross-subsystem Changes: - Perf events: Export perf_allow_{cpu,tracepoint} to be used by Xe (John) Display Changes: - Skip FORCE_WC and vm_bound check for external dma-bufs (Auld) Driver Changes: - Gate observation streams with perf_allow_cpu (John Hubbard) - Documentation updates and fixes (Michal, Zhan) - Remove unreleased NVL-S GuC (Daniele) - Fix pcode init path (Michal) - RTP fixes and improvements (Gustavo, Violet, Thomas, Roper) - TLB invalidation fixes and improvements (Tilak) - PXP detachment from HuC for newer platforms (Daniele) - Multi-queue fix (Niranjana) - Improve Kconfig.profile help (Rodrigo) - Xe_drm_ras and hw_error updates and fixes (Raag, Riana) - NVL-S updated PCI-IDs and W/a (Gustavo, Nitin) - Fix dma_fence refcound (Wentao) - Madvise: optimize invalidation path (Arvind) - Fix a infinite gt-reset loop in the timeout recovery (Rodrigo) - Fix wa_oob codegen recipe for external module builds (Thomas) - Avoid global forcewake in cycle query path (Xin) - Update TTM device benefical_order (Brost) - Fix buffer overflow in guc capture (Tejas) - Page-table fixes and improvements (Brian, Francois, Auld, Brost) - Removing redundant check (Lu) - General MCR and MMIO clean-up and improvements (Michal) - Don't whitelist OA registers unconditionally (Ashutosh) - SVM error return fix (Brost) - Userptr fix and small related clean-ups (Shuicheng) - Don't attempt to process FAST_REQ or EVENT relays on PF (Michal) - Couple fdinfo improvements (Auld) - Drop manual VF check on i2c (Raag) - Probe info outside of xe_info_init functions (Gustavo) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/akf7xr96MI4Rd6Qj@intel.com
2026-07-06Merge tag 'mm-hotfixes-stable-2026-07-06-17-49' of ↵Linus Torvalds3-9/+26
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull misc fixes from Andrew Morton: "20 hotfixes. 17 are for MM. 12 are cc:stable and the remaining 8 address post-7.1 issues or aren't considered suitable for backporting. Two patches from SJ addresses a couple of quite old DAMON issues. And two patches from Yichong Chen fixes tools/virtio build issues. The remaining patches are singletons" * tag 'mm-hotfixes-stable-2026-07-06-17-49' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: tools/include: include stdint.h for SIZE_MAX in overflow.h tools/virtio: add missing compat definitions for vhost_net_test mm: do file ownership checks with the proper mount idmap samples/damon/mtier: fail early if address range parameters are invalid mm: a second pagecache maintainer mm/damon: add a kernel-doc comment for damon_ctx->rnd_state mm/damon: add a kernel-doc comment for damon_ctx->probes mailmap: add entries for Radu Rendec selftests/mm: hmm-tests: include linux/mman.h to access MADV_COLLAPSE selftests/mm: pagemap_ioctl: use the correct page size for transact_test() fs/proc: fix KPF_KSM reported for all anonymous pages mm: page_ext: add count limit to page_ext_iter_next to prevent invalid PFN access mm/damon/ops-common: handle extreme intervals in damon_hot_score() MAINTAINERS: add Lance as an rmap reviewer mm/compaction: handle free_pages_prepare() properly in compaction_free() mm/damon/sysfs-schemes: put stats for scheme_add_dirs() internal error mm/damon/sysfs-schemes: fix dir put orders in access_pattern_add_dirs() mm: shrinker: fix NULL pointer dereference in debugfs mm: shrinker: fix shrinker_info teardown race with expansion selftests/mm: fix ksft_process_madv.sh test category
2026-07-07Merge tag 'drm-misc-next-2026-07-02' of ↵Dave Airlie1-2/+2
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for 7.3: UAPI Changes: Cross-subsystem Changes: Core Changes: - bridge: Add atomic_create_state callback and helpers, drop atomic_reset - dp: Add support for DSC max delta BPP - edid: Parse panel type from DisplayID 2.x Display Parameters - sysfb: Improve panel, stride and framebuffer size validation Driver Changes: - hibmc: Improvements to the plane formats handling, switch to gem-shmem - nouveau: race fixes, misc improvements - bridges: - Convert all bridges to atomic_create_state - panels: - panel-edp: New quirks for BOE NE160QDM-NY1, MB116AS01 Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <mripard@redhat.com> Link: https://patch.msgid.link/20260702-powerful-successful-raptor-eded34@houat
2026-07-06firmware: stratix10-svc: fix FCS SMC call kernel-docGenevieve Chan1-5/+7
Correct kernel-doc errors for two FCS SMC calls: INTEL_SIP_SMC_FCS_SEND_CERTIFICATE: - Describe as async to match STD_CALL_VAL usage - Replace INTEL_SIP_SMC_FCS_REJECTED with INTEL_SIP_SMC_REJECTED INTEL_SIP_SMC_FCS_GET_PROVISION_DATA: - Replace FCS-specific status macros with standard status macros (INTEL_SIP_SMC_STATUS_ERROR and INTEL_SIP_SMC_STATUS_REJECTED) - Restore return register documentation for a1 (mailbox error), a2 (physical address), and a3 (structure size) Fixes: 4a4709d470e6 ("firmware: stratix10-svc: add new FCS commands") Fixes: 4b0a32016347 ("firmware: stratix10-svc: change get provision data to async SMC call") Cc: stable@vger.kernel.org # 6.0+ Signed-off-by: Genevieve Chan <genevieve.chan@altera.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2026-07-06regulator: qcom_usb_vbus: add pm4125 VBUS regulator supportMark Brown113-1019/+1617
Rakesh Kota <rakesh.kota@oss.qualcomm.com> says: Add support for PM4125 USB VBUS regulator. Unlike PM8150B which uses a current-limit selector, PM4125 uses a 2-bit VBOOST voltage selector supporting 4.25 V, 4.5 V, 4.75 V and 5.0 V output. Link: https://patch.msgid.link/20260706-add_pm4125-vbus-reg-v3-0-999d78a87b81@oss.qualcomm.com
2026-07-06nvme: fix typos in reservation related constantsGuixin Liu1-2/+2
Fix the following spelling errors: - NVMET_PR_NOTIFI_MASK_ALL -> NVMET_PR_NOTIFY_MASK_ALL - NVME_PR_LOG_RESERVATOIN_PREEMPTED -> NVME_PR_LOG_RESERVATION_PREEMPTED - NVME_AEN_RESV_LOG_PAGE_AVALIABLE -> NVME_AEN_RESV_LOG_PAGE_AVAILABLE Signed-off-by: Guixin Liu <kanie@linux.alibaba.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-07-06Merge tag 'v7.2-rc2' into togregJonathan Cameron113-1019/+1617
Linux 7.2-rc2 Done to resolve conflicts with header reorg around mod_devicetable.h and provide a base for other inflight series that touch the includes.
generated by cgit (git 2.54.0.dirty) at 2026-09-15 12:47:21 +0000