summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
9 daysxen/mcelog: simplify MCE_GETCLEAR_FLAGS using xchg()Uros Bizjak
The MCE_GETCLEAR_FLAGS ioctl retrieves xen_mcelog.flags while atomically clearing it. This was previously implemented using a cmpxchg() loop. Replace the cmpxchg() loop with a single xchg(), which provides the same atomic get-and-clear semantics, avoids retry spinning under contention, and simplifies the code. The code on x86_64 improves from: 186: 8b 15 00 00 00 00 mov 0x0(%rip),%edx 18c: 89 d0 mov %edx,%eax 18e: f0 0f b1 0d 00 00 00 lock cmpxchg %ecx,0x0(%rip) 195: 00 196: 39 c2 cmp %eax,%edx 198: 75 ec jne 186 <...> to just: 186: 87 05 00 00 00 00 xchg %eax,0x0(%rip) No functional change intended. Signed-off-by: Uros Bizjak <ubizjak@gmail.com> Cc: Juergen Gross <jgross@suse.com> Cc: Stefano Stabellini <sstabellini@kernel.org> Cc: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Juergen Gross <jgross@suse.com> Message-ID: <20260122141754.116129-1-ubizjak@gmail.com>
9 daysxen/balloon: improve accuracy of initial balloon target for dom0Roger Pau Monne
The dom0 balloon target set by the toolstack is the value returned by XENMEM_current_reservation. Do the same in the kernel balloon driver and set the current allocation to the value returned by XENMEM_current_reservation. On my test system this causes the kernel balloon driver target to exactly match the value set by the toolstack in xenstore. Note this approach can be used by both PV and PVH dom0s, as the toolstack always uses XENMEM_current_reservation to set the initial target regardless of the dom0 type. Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Juergen Gross <jgross@suse.com> Signed-off-by: Juergen Gross <jgross@suse.com> Message-ID: <20260128110510.46425-3-roger.pau@citrix.com>
9 daysPartial revert "x86/xen: fix balloon target initialization for PVH dom0"Roger Pau Monne
This partially reverts commit 87af633689ce16ddb166c80f32b120e50b1295de so the current memory target for PV guests is still fetched from start_info->nr_pages, which matches exactly what the toolstack sets the initial memory target to. Using get_num_physpages() is possible on PV also, but needs adjusting to take into account the ISA hole and the PFN at 0 not considered usable memory despite being populated, and hence would need extra adjustments. Instead of carrying those extra adjustments switch back to the previous code. That leaves Linux with a difference in how current memory target is obtained for HVM vs PV, but that's better than adding extra logic just for PV. However if switching to start_info->nr_pages for PV domains we need to differentiate between released pages (freed back to the hypervisor) as opposed to pages in the physmap which are not populated to start with. Introduce a new xen_unpopulated_pages to account for papges that have never been populated, and hence in the PV case don't need subtracting. Fixes: 87af633689ce ("x86/xen: fix balloon target initialization for PVH dom0") Reported-by: James Dingwall <james@dingwall.me.uk> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Juergen Gross <jgross@suse.com> Signed-off-by: Juergen Gross <jgross@suse.com> Message-ID: <20260128110510.46425-2-roger.pau@citrix.com>
9 daysRevert "drm/nouveau/disp: Set drm_mode_config_funcs.atomic_(check|commit)"John Ogness
This reverts commit 604826acb3f53c6648a7ee99a3914ead680ab7fb. Apparently there is more to supporting atomic modesetting than providing atomic_(check|commit) callbacks. Before this revert: WARNING: [] drivers/gpu/drm/drm_plane.c:389 at .__drm_universal_plane_init+0x13c/0x794 [drm], CPU#1: modprobe/1790 BUG: Kernel NULL pointer dereference on read at 0x00000000 .drm_atomic_get_plane_state+0xd4/0x210 [drm] (unreliable) .drm_client_modeset_commit_atomic+0xf8/0x338 [drm] .drm_client_modeset_commit_locked+0x80/0x260 [drm] .drm_client_modeset_commit+0x40/0x7c [drm] .__drm_fb_helper_restore_fbdev_mode_unlocked.part.0+0xfc/0x108 [drm_kms_helper] .drm_fb_helper_set_par+0x8c/0xb8 [drm_kms_helper] .fbcon_init+0x31c/0x618 [...] .__drm_fb_helper_initial_config_and_unlock+0x474/0x7f4 [drm_kms_helper] .drm_fbdev_client_hotplug+0xb0/0x120 [drm_client_lib] .drm_client_register+0x88/0xe4 [drm] .drm_fbdev_client_setup+0x12c/0x19b4 [drm_client_lib] .drm_client_setup+0x15c/0x18c [drm_client_lib] .nouveau_drm_probe+0x19c/0x268 [nouveau] Fixes: 604826acb3f5 ("drm/nouveau/disp: Set drm_mode_config_funcs.atomic_(check|commit)") Reported-by: John Ogness <john.ogness@linutronix.de> Closes: https://lore.kernel.org/lkml/87ldhf1prw.fsf@jogness.linutronix.de Signed-off-by: John Ogness <john.ogness@linutronix.de> Tested-by: Daniel Palmer <daniel@thingy.jp> Link: https://patch.msgid.link/20260130113230.2311221-1-john.ogness@linutronix.de Signed-off-by: Danilo Krummrich <dakr@kernel.org>
9 daysMerge tag 'scsi-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "Small changes in drivers only, no core changes. The firewire one fixes a user controlled overflow (but I still can't see how it could be exploited)" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: ufs: amd-versal2: Fix PHY initialization in HCE enable notify scsi: firewire: sbp-target: Fix overflow in sbp_make_tpg() scsi: be2iscsi: Fix a memory leak in beiscsi_boot_get_sinfo() scsi: qla2xxx: edif: Fix dma_free_coherent() size
9 daysMerge tag 'irq-urgent-2026-02-01' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull irq fixes from Ingo Molnar: "Misc irqchip fixes: - Fix a regression in the ls-extirq irqchip driver - Fix an irqchip platform enumeration regression in the simple-pm-bus driver" * tag 'irq-urgent-2026-02-01' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: bus: simple-pm-bus: Probe the Layerscape SCFG node irqchip/ls-extirq: Convert to a platform driver to make it work again
9 daysthermal/qcom/lmh: Replace IRQF_ONESHOT with IRQF_NO_THREADSebastian Andrzej Siewior
Passing IRQF_ONESHOT ensures that the interrupt source is masked until the secondary (threaded) handler is done. If only a primary handler is used then the flag makes no sense because the interrupt can not fire (again) while its handler is running. The flag also prevents force-threading of the primary handler and the irq-core will warn about this. The intention here was probably to not allow forced-threading. Replace IRQF_ONESHOT with IRQF_NO_THREAD. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260128095540.863589-14-bigeasy@linutronix.de
9 daysrtc: amlogic-a4: Remove IRQF_ONESHOTSebastian Andrzej Siewior
Passing IRQF_ONESHOT ensures that the interrupt source is masked until the secondary (threaded) handler is done. If only a primary handler is used then the flag makes no sense because the interrupt can not fire (again) while its handler is running. The flag also prevents force-threading of the primary handler and the irq-core will warn about this. Remove IRQF_ONESHOT from irqflags. Fixes: c89ac9182ee29 ("rtc: support for the Amlogic on-chip RTC") Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Xianwei Zhao <xianwei.zhao@amlogic.com> Link: https://patch.msgid.link/20260128095540.863589-13-bigeasy@linutronix.de
9 daysusb: typec: fusb302: Remove IRQF_ONESHOTSebastian Andrzej Siewior
Passing IRQF_ONESHOT ensures that the interrupt source is masked until the secondary (threaded) handler is done. If only a primary handler is used then the flag makes no sense because the interrupt can not fire (again) while its handler is running. The flag also prevents force-threading of the primary handler and the irq-core will warn about this. Remove IRQF_ONESHOT from irqflags. Fixes: 309b6341d5570 ("usb: typec: fusb302: Revert incorrect threaded irq fix") Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://patch.msgid.link/20260128095540.863589-12-bigeasy@linutronix.de
9 daysEDAC/altera: Remove IRQF_ONESHOTSebastian Andrzej Siewior
Passing IRQF_ONESHOT ensures that the interrupt source is masked until the secondary (threaded) handler is done. If only a primary handler is used then the flag makes no sense because the interrupt can not fire (again) while its handler is running. The flag also prevents force-threading of the primary handler and the irq-core will warn about this. Remove IRQF_ONESHOT from irqflags. Fixes: a29d64a45eed1 ("EDAC, altera: Add IRQ Flags to disable IRQ while handling") Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260128095540.863589-11-bigeasy@linutronix.de
9 dayschar: tpm: cr50: Remove IRQF_ONESHOTSebastian Andrzej Siewior
Passing IRQF_ONESHOT ensures that the interrupt source is masked until the secondary (threaded) handler is done. If only a primary handler is used then the flag makes no sense because the interrupt can not fire (again) while its handler is running. The flag also prevents force-threading of the primary handler and the irq-core will warn about this. Remove IRQF_ONESHOT from irqflags. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Link: https://patch.msgid.link/20260128095540.863589-10-bigeasy@linutronix.de
9 daysscsi: efct: Use IRQF_ONESHOT and default primary handlerSebastian Andrzej Siewior
There is no added value in efct_intr_msix() compared to irq_default_primary_handler(). Using a threaded interrupt without a dedicated primary handler mandates the IRQF_ONESHOT flag to mask the interrupt source while the threaded handler is active. Otherwise the interrupt can fire again before the threaded handler had a chance to run. Use the default primary interrupt handler by specifying NULL and set IRQF_ONESHOT so the interrupt source is masked until the secondary handler is done. Fixes: 4df84e8466242 ("scsi: elx: efct: Driver initialization routines") Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260128095540.863589-8-bigeasy@linutronix.de
9 daysBluetooth: btintel_pcie: Use IRQF_ONESHOT and default primary handlerSebastian Andrzej Siewior
There is no added value in btintel_pcie_msix_isr() compared to irq_default_primary_handler(). Using a threaded interrupt without a dedicated primary handler mandates the IRQF_ONESHOT flag to mask the interrupt source while the threaded handler is active. Otherwise the interrupt can fire again before the threaded handler had a chance to run. Use the default primary interrupt handler by specifying NULL and set IRQF_ONESHOT so the interrupt source is masked until the secondary handler is done. Fixes: c2b636b3f788d ("Bluetooth: btintel_pcie: Add support for PCIe transport") Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260128095540.863589-7-bigeasy@linutronix.de
9 daysbus: fsl-mc: Use default primary handlerSebastian Andrzej Siewior
There is no added value in dprc_irq0_handler() compared to irq_default_primary_handler(). Use the default primary interrupt handler by specifying NULL. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com> Link: https://patch.msgid.link/20260128095540.863589-6-bigeasy@linutronix.de
9 daysmailbox: bcm-ferxrm-mailbox: Use default primary handlerSebastian Andrzej Siewior
request_threaded_irq() is invoked with a primary and a secondary handler and no flags are passed. The primary handler is the same as irq_default_primary_handler() so there is no need to have an identical copy. The lack of the IRQF_ONESHOT flag can be dangerous because the interrupt source is not masked while the threaded handler is active. This means, especially on LEVEL typed interrupt lines, the interrupt can fire again before the threaded handler had a chance to run. Use the default primary interrupt handler by specifying NULL and set IRQF_ONESHOT so the interrupt source is masked until the secondary handler is done. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260128095540.863589-5-bigeasy@linutronix.de
9 daysiommu/amd: Use core's primary handler and set IRQF_ONESHOTSebastian Andrzej Siewior
request_threaded_irq() is invoked with a primary and a secondary handler and no flags are passed. The primary handler is the same as irq_default_primary_handler() so there is no need to have an identical copy. The lack of the IRQF_ONESHOT can be dangerous because the interrupt source is not masked while the threaded handler is active. This means, especially on LEVEL typed interrupt lines, the interrupt can fire again before the threaded handler had a chance to run. Use the default primary interrupt handler by specifying NULL and set IRQF_ONESHOT so the interrupt source is masked until the secondary handler is done. Fixes: 72fe00f01f9a3 ("x86/amd-iommu: Use threaded interupt handler") Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260128095540.863589-4-bigeasy@linutronix.de
9 daysplatform/x86: int0002: Remove IRQF_ONESHOT from request_irq()Sebastian Andrzej Siewior
Passing IRQF_ONESHOT ensures that the interrupt source is masked until the secondary (threaded) handler is done. If only a primary handler is used then the flag makes no sense because the interrupt cannot fire (again) while its handler is running. The flag also prevents force-threading of the primary handler and the irq-core will warn about this. The flag was added to match the flag on the shared handler which uses a threaded handler and therefore IRQF_ONESHOT. This is no longer needed because devm_request_irq() now passes IRQF_COND_ONESHOT for this case. Revert adding IRQF_ONESHOT to irqflags. Fixes: 8f812373d1958 ("platform/x86: intel: int0002_vgpio: Pass IRQF_ONESHOT to request_irq()") Reported-by: Borah, Chaitanya Kumar <chaitanya.kumar.borah@intel.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://patch.msgid.link/20260128095540.863589-3-bigeasy@linutronix.de Closes: https://lore.kernel.org/all/555f1c56-0f74-41bf-8bd2-6217e0aab0c6@intel.com
9 daysirqchip/aspeed-scu-ic: Remove unused variable maskThomas Gleixner
The kernel test robot reports: drivers/irqchip/irq-aspeed-scu-ic.c:107:27: warning: variable 'mask' set but not used 107 | unsigned int sts, mask; Remove the leftover. Fixes: b2a0c13f8b4f ("irqchip/aspeed-scu-ic: Add support for AST2700 SCU interrupt controllers") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/874io0h3sz.ffs@tglx Closes: https://lore.kernel.org/oe-kbuild-all/202602010957.9uuKqUkG-lkp@intel.com/
10 daysdrivers: thermal: intel: tcc_cooling: Drop redundant local variableSumeet Pawnikar
Simplify the error path by directly returning PTR_ERR(tcc_cdev) instead of storing it in an intermediate variable ret which can be dropped then because it is only used for that. Also remove an uneeded empty line before the declaration of local variable err. Signed-off-by: Sumeet Pawnikar <sumeet4linux@gmail.com> [ rjw: Dropped unneeded changes, rewrote changelog, adjusted subject ] Link: https://patch.msgid.link/20260131151615.6230-1-sumeet4linux@gmail.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
10 daysACPI: battery: fix incorrect charging status when current is zeroAta İlhan Köktürk
On some laptops, such as the Huawei Matebook series, the embedded controller continues to report "Charging" status even when the charge threshold is reached and no current is being drawn. This incorrect reporting prevents the system from switching to battery power profiles, leading to significantly higher power (e.g., 18W instead of 7W during browsing) and missed remaining battery time estimation. Validate the "Charging" state by checking if rate_now is zero. If the hardware reports charging but the current is zero, report "Not Charging" to user space. Signed-off-by: Ata İlhan Köktürk <atailhan2006@gmail.com> [ rjw: Whitespace fix, braces added to an inner if (), new comment rewrite ] [ rjw: Changelog edits ] Link: https://patch.msgid.link/20260129144856.43058-1-atailhan2006@gmail.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
10 daysMerge tag 'iommu-fixes-v6.19-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/iommu/linux Pull iommu fixes from Joerg Roedel: - Fix a performance regression cause by the new Generic IO-Page-Table code detected in Intel VT-d driver - Command queue flushing fix for NVidia version of the ARM-SMMU-v3 * tag 'iommu-fixes-v6.19-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/iommu/linux: iommu/tegra241-cmdqv: Reset VCMDQ in tegra241_vcmdq_hw_init_user() iommupt: Only cache flush memory changed by unmap
11 dayshwmon: (acpi_power_meter) Fix deadlocks related to acpi_power_meter_notify()Rafael J. Wysocki
The acpi_power_meter driver's .notify() callback function, acpi_power_meter_notify(), calls hwmon_device_unregister() under a lock that is also acquired by callbacks in sysfs attributes of the device being unregistered which is prone to deadlocks between sysfs access and device removal. Address this by moving the hwmon device removal in acpi_power_meter_notify() outside the lock in question, but notice that doing it alone is not sufficient because two concurrent METER_NOTIFY_CONFIG notifications may be attempting to remove the same device at the same time. To prevent that from happening, add a new lock serializing the execution of the switch () statement in acpi_power_meter_notify(). For simplicity, it is a static mutex which should not be a problem from the performance perspective. The new lock also allows the hwmon_device_register_with_info() in acpi_power_meter_notify() to be called outside the inner lock because it prevents the other notifications handled by that function from manipulating the "resource" object while the hwmon device based on it is being registered. The sending of ACPI netlink messages from acpi_power_meter_notify() is serialized by the new lock too which generally helps to ensure that the order of handling firmware notifications is the same as the order of sending netlink messages related to them. In addition, notice that hwmon_device_register_with_info() may fail in which case resource->hwmon_dev will become an error pointer, so add checks to avoid attempting to unregister the hwmon device pointer to by it in that case to acpi_power_meter_notify() and acpi_power_meter_remove(). Fixes: 16746ce8adfe ("hwmon: (acpi_power_meter) Replace the deprecated hwmon_device_register") Closes: https://lore.kernel.org/linux-hwmon/CAK8fFZ58fidGUCHi5WFX0uoTPzveUUDzT=k=AAm4yWo3bAuCFg@mail.gmail.com/ Reported-by: Jaroslav Pulchart <jaroslav.pulchart@gooddata.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
11 daysublk: remove "can't touch 'ublk_io' any more" commentsCaleb Sander Mateos
The struct ublk_io is in fact accessed in __ublk_complete_rq() after the comment. But it's not racy to access the ublk_io between clearing its UBLK_IO_FLAG_OWNED_BY_SRV flag and completing the request, as no other thread can use the ublk_io in the meantime. Signed-off-by: Caleb Sander Mateos <csander@purestorage.com> Reviewed-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
11 daysublk: add UBLK_F_NO_AUTO_PART_SCAN feature flagMing Lei
Add a new feature flag UBLK_F_NO_AUTO_PART_SCAN to allow users to suppress automatic partition scanning when starting a ublk device. This is useful for some cases in which user don't want to scan partitions. Users still can manually trigger partition scanning later when appropriate using standard tools (e.g., partprobe, blockdev --rereadpt). Reported-by: Yoav Cohen <yoav@nvidia.com> Link: https://lore.kernel.org/linux-block/DM4PR12MB63280C5637917C071C2F0D65A9A8A@DM4PR12MB6328.namprd12.prod.outlook.com/ Signed-off-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
11 daysublk: check list membership before cancelling batch fetch commandMing Lei
Add !list_empty(&fcmd->node) check in ublk_batch_cancel_cmd() to ensure the fcmd hasn't already been removed from the list. Once an fcmd is removed from the list, it's considered claimed by whoever removed it and will be freed by that path. Meantime switch to list_del_init() for deleting it from list. Signed-off-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
11 daysublk: drop ublk_ctrl_start_recovery() header argumentCaleb Sander Mateos
ublk_ctrl_start_recovery() only uses its const struct ublksrv_ctrl_cmd * header argument to log the dev_id. But this value is already available in struct ublk_device's ub_number field. So log ub_number instead and drop the unused header argument. Signed-off-by: Caleb Sander Mateos <csander@purestorage.com> Reviewed-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
11 daysublk: use READ_ONCE() to read struct ublksrv_ctrl_cmdCaleb Sander Mateos
struct ublksrv_ctrl_cmd is part of the io_uring_sqe, which may lie in userspace-mapped memory. It's racy to access its fields with normal loads, as userspace may write to them concurrently. Use READ_ONCE() to copy the ublksrv_ctrl_cmd from the io_uring_sqe to the stack. Use the local copy in place of the one in the io_uring_sqe. Fixes: 87213b0d847c ("ublk: allow non-blocking ctrl cmds in IO_URING_F_NONBLOCK issue") Signed-off-by: Caleb Sander Mateos <csander@purestorage.com> Reviewed-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
11 daysublk: Validate SQE128 flag before accessing the cmdGovindarajulu Varadarajan
ublk_ctrl_cmd_dump() accesses (header *)sqe->cmd before IO_URING_F_SQE128 flag check. This could cause out of boundary memory access. Move the SQE128 flag check earlier in ublk_ctrl_uring_cmd() to return -EINVAL immediately if the flag is not set. Fixes: 71f28f3136af ("ublk_drv: add io_uring based userspace block driver") Signed-off-by: Govindarajulu Varadarajan <govind.varadar@gmail.com> Reviewed-by: Caleb Sander Mateos <csander@purestorage.com> Reviewed-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
11 daysiommu/tegra241-cmdqv: Reset VCMDQ in tegra241_vcmdq_hw_init_user()Nicolin Chen
The Enable bits in CMDQV/VINTF/VCMDQ_CONFIG registers do not actually reset the HW registers. So, the driver explicitly clears all the registers when a VINTF or VCMDQ is being initialized calling its hw_deinit() function. However, a userspace VCMDQ is not properly reset, unlike an in-kernel VCMDQ getting reset in tegra241_vcmdq_hw_init(). Meanwhile, tegra241_vintf_hw_init() calling tegra241_vintf_hw_deinit() will not deinit any VCMDQ, since there is no userspace VCMDQ mapped to the VINTF at that stage. Then, this may result in dirty VCMDQ registers, which can fail the VM. Like tegra241_vcmdq_hw_init(), reset a VCMDQ in tegra241_vcmdq_hw_init() to fix this bug. This is required by a host kernel. Fixes: 6717f26ab1e7 ("iommu/tegra241-cmdqv: Add user-space use support") Cc: stable@vger.kernel.org Reported-by: Bao Nguyen <ncqb@google.com> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
11 dayscrypto: caam - fix netdev memory leak in dpaa2_caam_probeJianpeng Chang
When commit 0e1a4d427f58 ("crypto: caam: Unembed net_dev structure in dpaa2") converted embedded net_device to dynamically allocated pointers, it added cleanup in dpaa2_dpseci_disable() but missed adding cleanup in dpaa2_dpseci_free() for error paths. This causes memory leaks when dpaa2_dpseci_dpio_setup() fails during probe due to DPIO devices not being ready yet. The kernel's deferred probe mechanism handles the retry successfully, but the netdevs allocated during the failed probe attempt are never freed, resulting in kmemleak reports showing multiple leaked netdev-related allocations all traced back to dpaa2_caam_probe(). Fix this by preserving the CPU mask of allocated netdevs during setup and using it for cleanup in dpaa2_dpseci_free(). This approach ensures that only the CPUs that actually had netdevs allocated will be cleaned up, avoiding potential issues with CPU hotplug scenarios. Fixes: 0e1a4d427f58 ("crypto: caam: Unembed net_dev structure in dpaa2") Signed-off-by: Jianpeng Chang <jianpeng.chang.cn@windriver.com> Reviewed-by: Breno Leitao <leitao@debian.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
11 dayscrypto: hisilicon/qm - increase wait time for mailboxWeili Qian
The device requires more time to process queue stop and function stop mailbox commands compared to other mailbox commands . In the current driver, the mailbox processing wait time for queue stop and function stop is less than the device timeout, which may cause the driver to incorrectly assume that the mailbox processing has failed. Therefore, the driver wait time for queue stop and function stop should be set to be greater than the device timeout. And PF and VF communication relies on mailbox, the communication wait time should also be modified. Signed-off-by: Weili Qian <qianweili@huawei.com> Signed-off-by: Chenghai Huang <huangchenghai2@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
11 dayscrypto: hisilicon/qm - obtain the mailbox configuration at one timeWeili Qian
The malibox needs to be triggered by a 128bit atomic operation. The reason is that the PF and VFs of the device share the mmio memory of the mailbox, and the mutex cannot lock mailbox operations in different functions, especially when passing through VFs to virtual machines. Currently, the write operation to the mailbox is already a 128-bit atomic write. The read operation also needs to be modified to a 128-bit atomic read. Since there is no general 128-bit IO memory access API in the current ARM64 architecture, and the stp and ldp instructions do not guarantee atomic access to device memory, they cannot be extracted as a general API. Therefore, the 128-bit atomic read and write operations need to be implemented in the driver. Signed-off-by: Weili Qian <qianweili@huawei.com> Signed-off-by: Chenghai Huang <huangchenghai2@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
11 dayscrypto: hisilicon/qm - remove unnecessary code in qm_mb_write()Weili Qian
Since the HiSilicon accelerator is used only on the ARM64 architectures, the implementations for other architectures are not needed, so remove the unnecessary code. Signed-off-by: Weili Qian <qianweili@huawei.com> Signed-off-by: Chenghai Huang <huangchenghai2@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
11 dayscrypto: hisilicon/qm - move the barrier before writing to the mailbox registerChenghai Huang
Before sending the data via the mailbox to the hardware, to ensure that the data accessed by the hardware is the most up-to-date, a write barrier should be added before writing to the mailbox register. The current memory barrier is placed after writing to the register, the barrier order should be modified to be before writing to the register. Signed-off-by: Chenghai Huang <huangchenghai2@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
11 dayscrypto: hisilicon/trng - support tfms sharing the deviceWeili Qian
Since the number of devices is limited, and the number of tfms may exceed the number of devices, to ensure that tfms can be successfully allocated, support tfms sharing the same device. Fixes: e4d9d10ef4be ("crypto: hisilicon/trng - add support for PRNG") Signed-off-by: Weili Qian <qianweili@huawei.com> Signed-off-by: Chenghai Huang <huangchenghai2@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
11 dayscrypto: hisilicon/zip - add lz4 algorithm for hisi_zipChenghai Huang
Add the "hisi-lz4-acomp" algorithm by the crypto acomp. When the 8th bit of the capability register is 1, the lz4 algorithm will register to crypto acomp, and the window length is configured to 16K by default. Since the "hisi-lz4-acomp" currently only support compression direction, decompression is completed by the soft lz4 algorithm. Signed-off-by: Chenghai Huang <huangchenghai2@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
11 dayss390/pkey: Support new xflag PKEY_XFLAG_NOCLEARKEYHarald Freudenberger
Introduce a new xflag PKEY_XFLAG_NOCLEARKEY which when given refuses the conversion of "clear key tokens" to protected key material. Some algorithms (PAES, PHMAC) have the need to construct "clear key tokens" to be used during selftest. But in general these algorithms should only support clear key material for testing purpose. So now the algorithm implementation can signal via xflag PKEY_XFLAG_NOCLEARKEY that a conversion of clear key material to protected key is not acceptable and thus the pkey layer (usually one of the handler modules) refuses clear key material with -EINVAL. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
11 dayscrypto: stm32 - Replace min_t(size_t) with just min()Thorsten Blum
In most cases, min_t(size_t) and explicit casting are unnecessary because the values ->hw_blocksize, ->payload_{in,out}, and ->header_in are already of type 'size_t'. Use the simpler min() macro instead. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
11 dayscrypto: virtio - Replace package id with numa node idBibo Mao
With multiple virtio crypto devices supported with different NUMA nodes, when crypto session is created, it will search virtio crypto device with the same numa node of current CPU. Here API topology_physical_package_id() is replaced with cpu_to_node() since package id is physical concept, and one package id have multiple memory numa id. Signed-off-by: Bibo Mao <maobibo@loongson.cn> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
11 dayscrypto: virtio - Remove duplicated virtqueue_kick in ↵Bibo Mao
virtio_crypto_skcipher_crypt_req With function virtio_crypto_skcipher_crypt_req(), there is already virtqueue_kick() call with spinlock held in function __virtio_crypto_skcipher_do_req(). Remove duplicated virtqueue_kick() function call here. Fixes: d79b5d0bbf2e ("crypto: virtio - support crypto engine framework") Cc: stable@vger.kernel.org Signed-off-by: Bibo Mao <maobibo@loongson.cn> Acked-by: Jason Wang <jasowang@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
11 dayscrypto: virtio - Add spinlock protection with virtqueue notificationBibo Mao
When VM boots with one virtio-crypto PCI device and builtin backend, run openssl benchmark command with multiple processes, such as openssl speed -evp aes-128-cbc -engine afalg -seconds 10 -multi 32 openssl processes will hangup and there is error reported like this: virtio_crypto virtio0: dataq.0:id 3 is not a head! It seems that the data virtqueue need protection when it is handled for virtio done notification. If the spinlock protection is added in virtcrypto_done_task(), openssl benchmark with multiple processes works well. Fixes: fed93fb62e05 ("crypto: virtio - Handle dataq logic with tasklet") Cc: stable@vger.kernel.org Signed-off-by: Bibo Mao <maobibo@loongson.cn> Acked-by: Jason Wang <jasowang@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
11 daysnet: usb: r8152: fix resume reset deadlockSergey Senozhatsky
rtl8152 can trigger device reset during reset which potentially can result in a deadlock: **** DPM device timeout after 10 seconds; 15 seconds until panic **** Call Trace: <TASK> schedule+0x483/0x1370 schedule_preempt_disabled+0x15/0x30 __mutex_lock_common+0x1fd/0x470 __rtl8152_set_mac_address+0x80/0x1f0 dev_set_mac_address+0x7f/0x150 rtl8152_post_reset+0x72/0x150 usb_reset_device+0x1d0/0x220 rtl8152_resume+0x99/0xc0 usb_resume_interface+0x3e/0xc0 usb_resume_both+0x104/0x150 usb_resume+0x22/0x110 The problem is that rtl8152 resume calls reset under tp->control mutex while reset basically re-enters rtl8152 and attempts to acquire the same tp->control lock once again. Reset INACCESSIBLE device outside of tp->control mutex scope to avoid recursive mutex_lock() deadlock. Fixes: 4933b066fefb ("r8152: If inaccessible at resume time, issue a reset") Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org> Link: https://patch.msgid.link/20260129031106.3805887-1-senozhatsky@chromium.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
11 daysmacvlan: fix error recovery in macvlan_common_newlink()Eric Dumazet
valis provided a nice repro to crash the kernel: ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 ping -c1 -I p1 1.2.3.4 He also gave a very detailed analysis: <quote valis> The issue is triggered when a new macvlan link is created with MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan port and register_netdevice() called from macvlan_common_newlink() fails (e.g. because of the invalid link name). In this case macvlan_hash_add_source is called from macvlan_change_sources() / macvlan_common_newlink(): This adds a reference to vlan to the port's vlan_source_hash using macvlan_source_entry. vlan is a pointer to the priv data of the link that is being created. When register_netdevice() fails, the error is returned from macvlan_newlink() to rtnl_newlink_create(): if (ops->newlink) err = ops->newlink(dev, &params, extack); else err = register_netdevice(dev); if (err < 0) { free_netdev(dev); goto out; } and free_netdev() is called, causing a kvfree() on the struct net_device that is still referenced in the source entry attached to the lower device's macvlan port. Now all packets sent on the macvlan port with a matching source mac address will trigger a use-after-free in macvlan_forward_source(). </quote valis> With all that, my fix is to make sure we call macvlan_flush_sources() regardless of @create value whenever "goto destroy_macvlan_port;" path is taken. Many thanks to valis for following up on this issue. Fixes: aa5fd0fb7748 ("driver: macvlan: Destroy new macvlan port if macvlan_common_newlink failed.") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: valis <sec@valis.email> Reported-by: syzbot+7182fbe91e58602ec1fe@syzkaller.appspotmail.com Closes: https: //lore.kernel.org/netdev/695fb1e8.050a0220.1c677c.039f.GAE@google.com/T/#u Cc: Boudewijn van der Heide <boudewijn@delta-utec.com> Link: https://patch.msgid.link/20260129204359.632556-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
11 daysnet: sfp: Fix quirk for Ubiquiti U-Fiber Instant SFP moduleMarek Behún
Commit fd580c9830316eda ("net: sfp: augment SFP parsing with phy_interface_t bitmap") did not add augumentation for the interface bitmap in the quirk for Ubiquiti U-Fiber Instant. The subsequent commit f81fa96d8a6c7a77 ("net: phylink: use phy_interface_t bitmaps for optical modules") then changed phylink code for selection of SFP interface: instead of using link mode bitmap, the interface bitmap is used, and the fastest interface mode supported by both SFP module and MAC is chosen. Since the interface bitmap contains also modes faster than 1000base-x, this caused a regression wherein this module stopped working out-of-the-box. Fix this. Fixes: fd580c9830316eda ("net: sfp: augment SFP parsing with phy_interface_t bitmap") Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/20260129082227.17443-1-kabel@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
11 daysMerge tag 'for-linus-iommufd' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jgg/iommufd Pull iommufd fix from Jason Gunthorpe: "One fix for a harmless KMSAN splat" * tag 'for-linus-iommufd' of git://git.kernel.org/pub/scm/linux/kernel/git/jgg/iommufd: iommufd: Initialize batch->kind in batch_clear()
11 daysMerge tag 'firewire-fixes-6.19-rc8' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394 Pull firewire fix from Takashi Sakamoto: "Fix a race condition introduced in v6.18. Andreas Persson discovered this issue while working with Focusrite Saffire Pro 40 (TCD33070). The fw_card instance maintains a linked list of pending transactions, which must be protected against concurrent access. However, a commit b5725cfa4120 ("firewire: core: use spin lock specific to timer for split transaction") unintentionally allowed concurrent accesses to this list. Fix this by adjusting the relevant critical sections to properly serialize access" * tag 'firewire-fixes-6.19-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394: firewire: core: fix race condition against transaction list
11 daysMerge tag 'rust-fixes-6.19' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux Pull Rust fixes from Miguel Ojeda: "Toolchain and infrastructure: - Trigger rebuilds of the newly added 'proc-macro2' crate (and its dependencies) when the Rust compiler version changes - Fix error in '.rsi' targets (macro expanding single targets) under 'O=' pointing to an external (not subdir) folder - Fix off-by-one line number in 'rustdoc' KUnit tests - Add '-fdiagnostics-show-context' to GCC flags skipped by 'bindgen' - Clean objtool warning by adding one more 'noreturn' function - Clean 'libpin_init_internal.{so,dylib}' in 'mrproper' 'kernel' crate: - Fix build error when using expressions in formatting arguments - Mark 'num::Bounded::__new()' as unsafe and clean documentation accordingly - Always inline functions using 'build_assert' with arguments - Fix 'rusttest' build error providing the right 'isize_atomic_repr' type for the host 'macros' crate: - Fix 'rusttest' build error by ignoring example rust-analyzer: - Remove assertion that was not true for distributions like NixOS - Add missing dependency edges and fix editions for 'quote' and sysroot crates to provide correct IDE support DRM Tyr: - Fix build error by adding missing dependency on 'CONFIG_COMMON_CLK' Plus clean a few typos in docs and comments" * tag 'rust-fixes-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux: (28 commits) rust: num: bounded: clean __new documentation and comments scripts: generate_rust_analyzer: fix resolution of #[pin_data] macros drm/tyr: depend on `COMMON_CLK` to fix build error rust: sync: atomic: Provide stub for `rusttest` 32-bit hosts kbuild: rust: clean libpin_init_internal in mrproper rust: proc-macro2: rebuild if the version text changes rust: num: bounded: add missing comment for always inlined function rust: sync: refcount: always inline functions using build_assert with arguments rust: bits: always inline functions using build_assert with arguments scripts: generate_rust_analyzer: compile sysroot with correct edition scripts: generate_rust_analyzer: compile quote with correct edition scripts: generate_rust_analyzer: quote: treat `core` and `std` as dependencies scripts: generate_rust_analyzer: syn: treat `std` as a dependency scripts: generate_rust_analyzer: remove sysroot assertion rust: kbuild: give `--config-path` to `rustfmt` in `.rsi` target scripts: generate_rust_analyzer: Add pin_init_internal deps scripts: generate_rust_analyzer: Add pin_init -> compiler_builtins dep scripts: generate_rust_analyzer: Add compiler_builtins -> core dep rust: macros: ignore example with module parameters rust: num: bounded: mark __new as unsafe ...
11 daysdrm/radeon: Make MSI address limit based on the device DMA limitVivian Wang
The radeon driver restricts the MSI message address for devices older than the BONAIR generation to 32-bit MSI addresses due to the former restrictions of the PCI/MSI code which only allowed either 32-bit or full 64-bit address range. This does not work on platforms which have a MSI doorbell address above the 32-bit boundary but do not support the full 64 bit address range. The PCI/MSI core converted this binary decision to a DMA_BIT_MASK() based decision, which allows to describe the device limitations precisely. Convert the driver to provide the exact DMA address limitations to the PCI/MSI core. That allows devices which do not support the full 64-bit address space to work on platforms which have a MSI doorbell address above the 32-bit limit as long as it is within the hardware's addressable range. [ tglx: Massage changelog ] Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patch.msgid.link/20260129-pci-msi-addr-mask-v4-3-70da998f2750@iscas.ac.cn
11 daysPCI/MSI: Check the device specific address mask in msi_verify_entries()Vivian Wang
Instead of a 32-bit/64-bit dichotomy, check the MSI address against the device specific address mask. This allows platforms with an MSI doorbell address above the 32-bit limit to work with devices without full 64-bit MSI address support, as long as the doorbell is within the addressable range of the device. [ tglx: Massaged changelog ] Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260129-pci-msi-addr-mask-v4-2-70da998f2750@iscas.ac.cn
11 daysPCI/MSI: Convert the boolean no_64bit_msi flag to a DMA address maskVivian Wang
Some PCI devices have PCI_MSI_FLAGS_64BIT in the MSI capability, but implement less than 64 address bits. This breaks on platforms where such a device is assigned an MSI address higher than what's supported. Currently, no_64bit_msi bit is set for these devices, meaning that only 32-bit MSI addresses are allowed for them. However, on some platforms the MSI doorbell address is above the 32-bit limit but within the addressable range of the device. As a first step to enable MSI on those combinations of devices and platforms, convert the boolean no_64bit_msi flag to a DMA mask and fixup the affected usage sites: - no_64bit_msi = 1 -> msi_addr_mask = DMA_BIT_MASK(32) - no_64bit_msi = 0 -> msi_addr_mask = DMA_BIT_MASK(64) - if (no_64bit_msi) -> if (msi_addr_mask < DMA_BIT_MASK(64)) Since no values other than DMA_BIT_MASK(32) and DMA_BIT_MASK(64) are used, this is functionally equivalent. This prepares for changing the binary decision between 32 and 64 bit to a DMA mask based decision which allows to support systems which have a DMA address space less than 64bit but a MSI doorbell address above the 32-bit limit. [ tglx: Massaged changelog ] Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Brett Creeley <brett.creeley@amd.com> # ionic Reviewed-by: Thomas Gleixner <tglx@kernel.org> Acked-by: Takashi Iwai <tiwai@suse.de> # sound Link: https://patch.msgid.link/20260129-pci-msi-addr-mask-v4-1-70da998f2750@iscas.ac.cn