To be able to constify instances of struct attribute it has to be
possible to add them to struct attribute_group. The current type of the
attrs member however is not compatible with that. Introduce a union that
allows registration of both const and non-const attributes to enable a
piecewise transition. As both union member types are compatible no
logic needs to be adapted.
Technically it is now possible register a const struct attribute and
receive it as mutable pointer in the callbacks. This is a soundness
issue. But this same soundness issue already exists today in
sysfs_create_file(). Also the struct definition and callback
implementation are always closely linked and are meant to be moved to
const in lockstep.
Similar to commit 906c508afd ("sysfs: attribute_group: allow
registration of const bin_attribute")
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://patch.msgid.link/20251029-sysfs-const-attr-prep-v5-1-ea7d745acff4@weissschuh.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Replace non-standard %Ld with %lld to ensure compliance with the kernel
coding style and potential formatting issues.
Signed-off-by: Clint George <clintbgeorge@gmail.com>
Link: https://patch.msgid.link/20251111151340.9162-3-clintbgeorge@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Replace printk(KERN_CRIT ...) with pr_crit(...) and printk() with
pr_debug(). The change aims to make logging more consistent and
readable.
Signed-off-by: Clint George <clintbgeorge@gmail.com>
Link: https://patch.msgid.link/20251111151340.9162-2-clintbgeorge@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch introduces a new UIO driver, uio_pci_generic_sva, which
extends the functionality of uio_pci_generic by adding support for
Shared Virtual Addressing (SVA) when IOMMU is enabled in the system.
The key enhancement allows PCI devices to directly use user-space virtual
addresses for DMA operations, eliminating the need for bounce buffers or
explicit IOVA mapping. This is achieved by leveraging the kernel's IOMMU-SVA
subsystem, including process address space attachment, page fault handling,
and shared context management between CPU and device.
With this driver, userspace applications can perform zero-copy DMA using
native pointers:
void *addr = malloc(N);
set_dma_addr((uint64_t)addr); // Passing user VA directly
start_dma();
The device can now access 'addr' through the IOMMU's PASID-based translation,
provided that the underlying IOMMU hardware (e.g., Intel VT-d 3.1+, AMD-Vi,
ARM SMMU, RISCV IOMMU) and platform support SVA.
Dependencies:
- CONFIG_IOMMU_SVA must be enabled.
- The platform must support PRI (Page Request Interface) and PASID.
- Device drivers/userspace must handle page faults if demand-paging is used.
The implementation reuses core logic from uio_pci_generic.c while adding
PASID setting, and integration with the IOMMU SVA APIs.
Also, add a read-only sysfs attribute 'pasid' to expose the Process Address
Space ID assigned by IOMMU driver when binding an SVA-enabled device.
For details, refer to the ABI documentation for uio_pci_sva driver sysfs attribute
(Documentation/ABI/testing/sysfs-driver-uio_pci_sva-pasid).
Signed-off-by: Yaxing Guo <guoyaxing@bosc.ac.cn>
Link: https://patch.msgid.link/20250926095828.506-1-guoyaxing@bosc.ac.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix below warnings generated dt_bindings_check for examples in the
bindings.
Documentation/devicetree/bindings/slimbus/slimbus.example.dtb:
slim@28080000 (qcom,slim-ngd-v1.5.0): 'audio-codec@1,0' does not match
any of the regexes: '^pinctrl-[0-9]+$', '^slim@[0-9a-f]+$'
from schema $id:
http://devicetree.org/schemas/slimbus/qcom,slim-ngd.yaml#
Documentation/devicetree/bindings/slimbus/slimbus.example.dtb:
slim@28080000 (qcom,slim-ngd-v1.5.0): #address-cells: 1 was expected
from schema $id:
http://devicetree.org/schemas/slimbus/qcom,slim-ngd.yaml#
Documentation/devicetree/bindings/slimbus/slimbus.example.dtb:
slim@28080000 (qcom,slim-ngd-v1.5.0): 'dmas' is a required property
from schema $id:
http://devicetree.org/schemas/slimbus/qcom,slim-ngd.yaml#
Documentation/devicetree/bindings/slimbus/slimbus.example.dtb:
slim@28080000 (qcom,slim-ngd-v1.5.0): 'dma-names' is a required
property
from schema $id:
http://devicetree.org/schemas/slimbus/qcom,slim-ngd.yaml#
Fixes: 7cbba32a2d ("slimbus: qcom: remove unused qcom controller driver")
Cc: stable <stable@kernel.org>
Reported-by: Rob Herring <robh@kernel.org>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Srinivas Kandagatla <srini@kernel.org>
Link: https://patch.msgid.link/20251114110505.143105-1-srini@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
intel_th_output_open() calls bus_find_device_by_devt() which
internally increments the device reference count via get_device(), but
this reference is not properly released in several error paths. When
device driver is unavailable, file operations cannot be obtained, or
the driver's open method fails, the function returns without calling
put_device(), leading to a permanent device reference count leak. This
prevents the device from being properly released and could cause
resource exhaustion over time.
Found by code review.
Cc: stable <stable@kernel.org>
Fixes: 39f4034693 ("intel_th: Add driver infrastructure for Intel(R) Trace Hub devices")
Signed-off-by: Ma Ke <make24@iscas.ac.cn>
Link: https://patch.msgid.link/20251112091723.35963-1-make24@iscas.ac.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When DT is used to get the reference of 'rp1_node', it should be released
when not needed anymore, otherwise it is leaking.
In such a case, add the missing of_node_put() call at the end of the probe,
as already done in the error handling path.
Fixes: 49d63971f9 ("misc: rp1: RaspberryPi RP1 misc driver")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Andrea della Porta <andrea.porta@suse.com>
Link: https://patch.msgid.link/9bc1206de787fa86384f3e5ba0a8027947bc00ff.1762585959.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Currently if a user enqueues a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistency cannot be addressed without refactoring the API.
alloc_workqueue() treats all queues as per-CPU by default, while unbound
workqueues must opt-in via WQ_UNBOUND.
This default is suboptimal: most workloads benefit from unbound queues,
allowing the scheduler to place worker threads where they’re needed and
reducing noise when CPUs are isolated.
This continues the effort to refactor workqueue APIs, which began with
the introduction of new workqueues and a new alloc_workqueue flag in:
commit 128ea9f6cc ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566 ("workqueue: Add new WQ_PERCPU flag")
This change adds the WQ_UNBOUND flag to explicitly request
alloc_workqueue() to be unbound, because this specific workload has no
benefit being per-cpu.
With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND),
any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND
must now use WQ_PERCPU.
Once migration is complete, WQ_UNBOUND can be removed and unbound will
become the implicit default.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Acked-by: Eli Billauer <eli.billauer@gmail.com>
Link: https://patch.msgid.link/20251107163755.356187-1-marco.crivellari@suse.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
pm_runtime_get_sync() may increment the runtime PM usage count even if the
resume fails, which requires an explicit pm_runtime_put_noidle() to balance
it. This driver ignored the return value, risking a usage-count leak on
resume failure.
Replace it with pm_runtime_resume_and_get(), which returns 0 on success and
a negative errno on failure, and only increments the usage count on success.
This simplifies the error path and avoids possible leaks. Also check for
errors explicitly with `if (ret < 0)`.
Signed-off-by: Vivek BalachandharTN <vivek.balachandhar@gmail.com>
Link: https://patch.msgid.link/20251030120022.239951-1-vivek.balachandhar@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The status of each mux is read during suspend and stored in the private
memory of the mux_chip.
Then the state is restored during the resume.
Reviewed-by: Andrew Davis <afd@ti.com>
Signed-off-by: Thomas Richard (TI.com) <thomas.richard@bootlin.com>
Link: https://patch.msgid.link/20251013-mux-mmio-resume-support-v5-1-de9467ceb2b2@bootlin.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add struct acrn_mmio_dev_res before struct acrn_mmio_dev.
The former is used in the latter and breaking them up provides
better kernel-doc documentation for the struct members.
Suggested-by: Fei Li <fei1.li@intel.com>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Fei Li <fei1.li@intel.com>
Link: https://patch.msgid.link/20251028040409.868254-1-rdunlap@infradead.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The primary consumer is link_path_walk(), calling walk_component() every
time which in turn calls step_into().
Inlining these saves overhead of 2 function calls per path component,
along with allowing the compiler to do better job optimizing them in place.
step_into() had absolutely atrocious assembly to facilitate the
slowpath. In order to lessen the burden at the callsite all the hard
work is moved into step_into_slowpath() and instead an inline-able
fastpath is implemented for rcu-walk.
The new fastpath is a stripped down step_into() RCU handling with a
d_managed() check from handle_mounts().
Benchmarked as follows on Sapphire Rapids:
1. the "before" was a kernel with not-yet-merged optimizations (notably
elision of calls to security_inode_permission() and marking ext4
inodes as not having acls as applicable)
2. "after" is the same + the prep patch + this patch
3. benchmark consists of issuing 205 calls to access(2) in a loop with
pathnames lifted out of gcc and the linker building real code, most
of which have several path components and 118 of which fail with
-ENOENT.
Result in terms of ops/s:
before: 21619
after: 22536 (+4%)
profile before:
20.25% [kernel] [k] __d_lookup_rcu
10.54% [kernel] [k] link_path_walk
10.22% [kernel] [k] entry_SYSCALL_64
6.50% libc.so.6 [.] __GI___access
6.35% [kernel] [k] strncpy_from_user
4.87% [kernel] [k] step_into
3.68% [kernel] [k] kmem_cache_alloc_noprof
2.88% [kernel] [k] walk_component
2.86% [kernel] [k] kmem_cache_free
2.14% [kernel] [k] set_root
2.08% [kernel] [k] lookup_fast
after:
23.38% [kernel] [k] __d_lookup_rcu
11.27% [kernel] [k] entry_SYSCALL_64
10.89% [kernel] [k] link_path_walk
7.00% libc.so.6 [.] __GI___access
6.88% [kernel] [k] strncpy_from_user
3.50% [kernel] [k] kmem_cache_alloc_noprof
2.01% [kernel] [k] kmem_cache_free
2.00% [kernel] [k] set_root
1.99% [kernel] [k] lookup_fast
1.81% [kernel] [k] do_syscall_64
1.69% [kernel] [k] entry_SYSCALL_64_safe_stack
While walk_component() and step_into() of course disappear from the
profile, the link_path_walk() barely gets more overhead despite the
inlining thanks to the fast path added and while completing more walks
per second.
I did not investigate why overhead grew a lot on __d_lookup_rcu().
Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
Link: https://patch.msgid.link/20251120003803.2979978-2-mjguzik@gmail.com
Signed-off-by: Christian Brauner <brauner@kernel.org>
Symlink handling is already marked as unlikely and pushing out some of
it into pick_link() reduces register spillage on entry to step_into()
with gcc 14.2.
The compiler needed additional convincing that handle_mounts() is
unlikely to fail.
At the same time neither clang nor gcc could be convinced to tail-call
into pick_link().
While pick_link() takes an address of stack-based object as an argument
(which definitely prevents the optimization), splitting it into separate
<dentry, mount> tuple did not help. The issue persists even when
compiled without stack protector. As such nothing was done about this
for the time being to not grow the diff.
Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
Link: https://patch.msgid.link/20251120003803.2979978-1-mjguzik@gmail.com
Signed-off-by: Christian Brauner <brauner@kernel.org>
Christoph Hellwig <hch@lst.de> says:
[Fix] the layering bypass in btrfs when updating timestamps on device
files for devices removed from btrfs usage, and FMODE_NOCMTIME handling
in the VFS now that nfsd started using it. Note that I'm still not sure
that nfsd usage is fully correct for all file systems, as only XFS
explicitly supports FMODE_NOCMTIME, but at least the generic code does
the right thing now.
* patches from https://patch.msgid.link/20251120064859.2911749-1-hch@lst.de:
orangefs: use inode_update_timestamps directly
btrfs: fix the comment on btrfs_update_time
btrfs: use vfs_utimes to update file timestamps
fs: export vfs_utimes
fs: lift the FMODE_NOCMTIME check into file_update_time_flags
fs: refactor file timestamp update logic
Link: https://patch.msgid.link/20251120064859.2911749-1-hch@lst.de
Signed-off-by: Christian Brauner <brauner@kernel.org>
Orangefs has no i_version handling and __orangefs_setattr already
explicitly marks the inode dirty. So instead of the using
the flags return value from generic_update_time, just call the
lower level inode_update_timestamps helper directly.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://patch.msgid.link/20251120064859.2911749-7-hch@lst.de
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
Since commit e41f941a23 ("Btrfs: move over to use ->update_time") this
is not a copy of the high-level file_update_time helper.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://patch.msgid.link/20251120064859.2911749-6-hch@lst.de
Signed-off-by: Christian Brauner <brauner@kernel.org>
Btrfs updates the device node timestamps for block device special files
when it stop using the device.
Commit 8f96a5bfa1 ("btrfs: update the bdev time directly when closing")
switch that update from the correct layering to directly call the
low-level helper on the bdev inode. This is wrong and got fixed in
commit 54fde91f52 ("btrfs: update device path inode time instead of
bd_inode") by updating the file system inode instead of the bdev inode,
but this kept the incorrect bypassing of the VFS interfaces and file
system ->update_times method. Fix this by using the propet vfs_utimes
interface.
Fixes: 8f96a5bfa1 ("btrfs: update the bdev time directly when closing")
Fixes: 54fde91f52 ("btrfs: update device path inode time instead of bd_inode")
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://patch.msgid.link/20251120064859.2911749-5-hch@lst.de
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Christian Brauner <brauner@kernel.org>
This will be used to replace an incorrect direct call into
generic_update_time in btrfs.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://patch.msgid.link/20251120064859.2911749-4-hch@lst.de
Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
FMODE_NOCMTIME used to be just a hack for the legacy XFS handle-based
"invisible I/O", but commit e5e9b24ab8 ("nfsd: freeze c/mtime updates
with outstanding WRITE_ATTRS delegation") started using it from
generic callers.
I'm not sure other file systems are actually read for this in general,
so the above commit should get a closer look, but for it to make any
sense, file_update_time needs to respect the flag.
Lift the check from file_modified_flags to file_update_time so that
users of file_update_time inherit the behavior and so that all the
checks are done in one place.
Fixes: e5e9b24ab8 ("nfsd: freeze c/mtime updates with outstanding WRITE_ATTRS delegation")
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://patch.msgid.link/20251120064859.2911749-3-hch@lst.de
Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
Currently the two high-level APIs use two helper functions to implement
almost all of the logic. Refactor the two helpers and the common logic
into a new file_update_time_flags routine that gets the iocb flags or
0 in case of file_update_time passed so that the entire logic is
contained in a single function and can be easily understood and modified.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://patch.msgid.link/20251120064859.2911749-2-hch@lst.de
Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
wait_for_completion_timeout() returns the remaining jiffies
(at least 1) on success or 0 on timeout, but never negative
error codes. The current code incorrectly checks for negative
values, causing timeouts to be ignored and treated as success.
Check for a zero return value to correctly identify and
handle timeout events.
Fixes: 0cf7befa3e ("greybus: gb-beagleplay: Add firmware upload API")
Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn>
Link: https://patch.msgid.link/20251121064027.571-1-vulab@iscas.ac.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This continues the effort to refactor workqueue APIs, which began with
the introduction of new workqueues and a new alloc_workqueue flag in:
commit 128ea9f6cc ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566 ("workqueue: Add new WQ_PERCPU flag")
This change adds a new WQ_PERCPU flag to explicitly request
alloc_workqueue() to be per-cpu when WQ_UNBOUND has not been specified.
With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND),
any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND
must now use WQ_PERCPU.
Once migration is complete, WQ_UNBOUND can be removed and unbound will
become the implicit default.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Reviewed-by: Johan Hovold <johan@kernel.org>
Link: https://patch.msgid.link/20251112152710.207577-1-marco.crivellari@suse.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
typedefs are unnecessary here. They rather obfuscate the code than help.
So drop them and use the types directly.
Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20251119091949.825958-7-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
PRINTK_ERROR() + KERN_ERR_MWAVE are just wrappers around printk() with
a prefix. Instead, pr_fmt() can be used. Drop the former and use the
latter.
Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20251119091949.825958-6-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The printk tracing makes the code hard to follow for no good benefit.
Everyone can use dynamic tracing and/or kprobes.
Drop this unreadable bloatware too.
Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20251119091949.825958-5-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
file_operations::{read/write/open/release} need not be defined. The core
code return proper values already (the same as the being removed ones).
So there is no need to preserve these just for tracing via printk.
Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20251119091949.825958-4-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In mwave, a lot of code depends on the MWAVE_FUTZ_WITH_OTHER_DEVICES
macro. That can be defined in Makefile to compile this in.
1) The code is completely unreadable.
2) Recompiling the kernel to have this untested code compiled in is not
a good idea.
Drop all this.
Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20251119091949.825958-3-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In mwave, there is a lot of commented code for a long time. Drop it.
Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20251119091949.825958-2-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Document the RSPI controller on the Renesas RZ/V2N SoC. The block is
compatible with the RSPI implementation found on the RZ/V2H(P) family.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20251126131619.136605-1-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The use of firmware_loader is an implementation detail of drivers rather
than a dependency. FW_LOADER is typically selected rather than depended
on; the Rust abstractions should do the same thing.
Fixes: de6582833d ("rust: add firmware abstractions")
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20251106-b4-select-rust-fw-v3-1-771172257755@nvidia.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
memset_io() writes memory byte by byte with __raw_writeb() on the arm
platform if the size is word. but XCVR data RAM memory can't be accessed
with byte address, so with memset_io() the channel status control memory
is not really cleared, use writel_relaxed() instead.
Fixes: 2856448686 ("ASoC: fsl_xcvr: Add XCVR ASoC CPU DAI driver")
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://patch.msgid.link/20251126064509.1900974-1-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The custom FIELD_OFFSET macro is no longer used in the driver (replaced
by standard offsetof). Remove the definition.
Signed-off-by: Navaneeth K <knavaneeth786@gmail.com>
Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://patch.msgid.link/20251125112059.16913-6-knavaneeth786@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Replace usage of the custom FIELD_OFFSET macro with the standard
offsetof() macro in rtw_mlme_ext.c. This improves code readability
and uses the kernel's standard mechanism.
Signed-off-by: Navaneeth K <knavaneeth786@gmail.com>
Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://patch.msgid.link/20251125112059.16913-5-knavaneeth786@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove obsolete commented-out code that references unsupported chip
variants (ODM_RTL8723A, ODM_RTL8188E). This code has been dead since
the driver was added to staging.
Also fix the resulting formatting by removing the unnecessary outer
parentheses and moving the inline comment to its own line.
Signed-off-by: Navaneeth K <knavaneeth786@gmail.com>
Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://patch.msgid.link/20251125112059.16913-4-knavaneeth786@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Replace usage of the custom FIELD_OFFSET macro with the standard
offsetof() macro in ioctl_cfg80211.c. This improves code readability
and uses the kernel's standard mechanism.
Also include <linux/stddef.h> in basic_types.h to ensure offsetof()
is available for this and future conversions.
Signed-off-by: Navaneeth K <knavaneeth786@gmail.com>
Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://patch.msgid.link/20251125112059.16913-3-knavaneeth786@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The RGTRY_OFT, RGTRY_SZ, BSSID_OFT, and BSSID_SZ macros are defined but
never used anywhere in the driver. Remove these dead macro definitions
to clean up the code.
Signed-off-by: Navaneeth K <knavaneeth786@gmail.com>
Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://patch.msgid.link/20251125112059.16913-2-knavaneeth786@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The COMEDI standalone 8255 driver can be used to configure a COMEDI
device consisting of one of more subdevices, each using an 8255 digital
I/O chip mapped to a range of port I/O addresses. The base port I/O
address of each chip is specified in an array of integer option values
by the `COMEDI_DEVCONFIG` ioctl.
When support for multiple 8255 subdevices per device was added in the
out-of-tree comedi 0.7.27 back in 1999, if any port I/O region could not
be requested, then the corresponding subdevice was set to be an "unused"
subdevice, and the COMEDI device would still be set-up OK as long as
those were the only types of errors. That has persisted until the
present day, but seems a bit odd in retrospect. All the other COMEDI
drivers that use port I/O or memory regions will fail to set up the
device if any region cannot be requested. It seems unlikely that the
sys admin would deliberately choose a port that cannot be requested just
to leave a gap in the device's usable subdevice numbers, and failing to
set-up the device will provide a more noticeable indication that
something hasn't been set-up correctly, so change the driver to fail to
set up the device if any of the port I/O regions cannot be requested.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20251028112833.15033-1-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "comedi_bond" driver allows a composite COMEDI device to be built up
from the subdevices of other COMEDI devices, although it currently only
supports digital I/O subdevices. Although it checks that it is not
trying to bind to itself, it is possible to end up with a cycle of
"comedi_bond" devices bound to each other. For example:
1. Configure /dev/comedi0 to use some COMEDI hardware device with
digital I/O subdevices, but not a "comedi_bond" device.
2. Configure /dev/comedi1 as a "comedi_bond" device bound to
/dev/comedi0.
3. Unconfigure /dev/comedi0 and reconfigure it as a "comedi_bond" device
bound to /dev/comedi1.
Now we have /dev/comedi0 and /dev/comedi1 bound in a cycle. When an
operation is performed on the digital I/O subdevice of /dev/comedi0 for
example, it will try and perform the operation on /dev/comedi1, which
will try and perform the operation on /dev/comedi0. The task will end
up deadlocked trying to lock /dev/comedi0's mutex which it has already
locked.
I discovered that possibility while investigating fix sysbot crash
https://syzkaller.appspot.com/bug?extid=4a6138c17a47937dcea1 ("possible
deadlock in comedi_do_insn"), but I think that report may be a false
positive.
To avoid that, replace the calls to `comedi_open()` and `comedi_close()`
in "kcomedilib" with calls to `comedi_open_from()` and
`comedi_close_from()`. These take an extra parameter that indicates the
COMEDI minor device number from which the open or close is being
performed. `comedi_open_from()` will refuse to open the device if doing
so would result in a cycle. The cycle detection depends on the extra
parameter having the correct value for this device and also for existing
devices in the chain.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20251027153748.4569-3-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add `comedi_open_from(path, from)` and `comedi_close_from(dev, from)` as
variants of the existing `comedi_from(path)` and `comedi_close(dev)`.
The additional `from` parameter is a minor device number that tells the
function that the COMEDI device is being opened or closed from another
COMEDI device if the value is in the range [0,
`COMEDI_NUM_BOARD_MINORS`-1]. In that case the function will refuse to
open the device if it would lead to a chain of devices opening each
other. (It will also impose a limit on the number of simultaneous opens
from one device to another because we need to count those.)
The new functions are intended to be used by the "comedi_bond" driver,
which is the only driver that uses the existing `comedi_open()` and
`comedi_close()` functions. The new functions will be used to avoid
some possible deadlock situations.
Replace the existing, exported `comedi_open()` and `comedi_close()`
functions with inline wrapper functions that call the newly exported
`comedi_open_from()` and `comedi_close_from()` functions.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20251027153748.4569-2-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
For interrupts from badly behaved hardware (as emulated by Syzbot), it
is possible for the Comedi core functions that manage the progress of
asynchronous data acquisition to be called from driver ISRs while no
asynchronous command has been set up, which can cause problems such as
invalid pointer dereferencing or dividing by zero.
Change those functions in the Comedi core to use this pattern: if
`comedi_get_is_subdevice_running(s)` returns `true` then call a safe
version of the function with the same name prefixed with an underscore,
followed by a call to `comedi_put_is_subdevice_running(s)`, otherwise
take some default action.
`comedi_get_is_subdevice_running(s)` returning `true` ensures that the
details of the asynchronous command will not be destroyed before the
matching call to `comedi_put_is_subdevice_running(s)`.
Replace calls to those functions from elsewhere in the Comedi core with
calls to the safe versions of the functions.
The modified functions are: `comedi_buf_read_alloc()`,
`comedi_buf_read_free()`, `comedi_buf_read_n_available()`,
`comedi_buf_read_samples()`, `comedi_buf_write_alloc()`,
`comedi_buf_write_free()`, `comedi_buf_write_samples()`,
`comedi_bytes_per_scan()`, `comedi_event()`, `comedi_handle_events()`,
`comedi_inc_scan_progress()`, `comedi_nsamples_left()`,
`comedi_nscans_left()`.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20251023133001.8439-3-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
For interrupts from badly behaved hardware (as emulated by Syzbot), it
is possible for the Comedi core functions that manage the progress of
asynchronous data acquisition to be called from driver ISRs while no
asynchronous command has been set up, which can cause problems such as
invalid pointer dereferencing or dividing by zero.
To help protect against that, introduce new functions to maintain a
reference counter for asynchronous commands that are being set up.
`comedi_get_is_subdevice_running(s)` will check if a command has been
set up on a subdevice and is still marked as running, and if so will
increment the reference counter and return `true`, otherwise it will
return `false` without modifying the reference counter.
`comedi_put_is_subdevice_running(s)` will decrement the reference
counter and set a completion event when decremented to 0.
Change the `do_cmd_ioctl()` function (responsible for setting up the
asynchronous command) to reinitialize the completion event and set the
reference counter to 1 before it marks the subdevice as running. Change
the `do_become_nonbusy()` function (responsible for destroying a
completed command) to call `comedi_put_is_subdevice_running(s)` and wait
for the completion event after marking the subdevice as not running.
Because the subdevice normally gets marked as not running before the
call to `do_become_nonbusy()` (and may also be called when the Comedi
device is being detached from the low-level driver), add a new flag
`COMEDI_SRF_BUSY` to the set of subdevice run-flags that indicates that
an asynchronous command was set up and will need to be destroyed. This
flag is set by `do_cmd_ioctl()` and cleared and checked by
`do_become_nonbusy()`.
Subsequent patches will change the Comedi core functions that are called
from low-level drivers for asynchrous command handling to make use of
the `comedi_get_is_subdevice_running()` and
`comedi_put_is_subdevice_running()` functions, and will modify the ISRs
of some of these low-level drivers if they dereference the subdevice's
`async` pointer directly.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20251023133001.8439-2-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Syzbot identified an issue [1] in pcl818_ai_cancel(), which stems from
the fact that in case of early device detach via pcl818_detach(),
subdevice dev->read_subdev may not have initialized its pointer to
&struct comedi_async as intended. Thus, any such dereferencing of
&s->async->cmd will lead to general protection fault and kernel crash.
Mitigate this problem by removing a call to pcl818_ai_cancel() from
pcl818_detach() altogether. This way, if the subdevice setups its
support for async commands, everything async-related will be
handled via subdevice's own ->cancel() function in
comedi_device_detach_locked() even before pcl818_detach(). If no
support for asynchronous commands is provided, there is no need
to cancel anything either.
[1] Syzbot crash:
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
CPU: 1 UID: 0 PID: 6050 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025
RIP: 0010:pcl818_ai_cancel+0x69/0x3f0 drivers/comedi/drivers/pcl818.c:762
...
Call Trace:
<TASK>
pcl818_detach+0x66/0xd0 drivers/comedi/drivers/pcl818.c:1115
comedi_device_detach_locked+0x178/0x750 drivers/comedi/drivers.c:207
do_devconfig_ioctl drivers/comedi/comedi_fops.c:848 [inline]
comedi_unlocked_ioctl+0xcde/0x1020 drivers/comedi/comedi_fops.c:2178
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
...
Reported-by: syzbot+fce5d9d5bd067d6fbe9b@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=fce5d9d5bd067d6fbe9b
Fixes: 00aba6e7b5 ("staging: comedi: pcl818: remove 'neverending_ai' from private data")
Cc: stable <stable@kernel.org>
Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20251023141457.398685-1-n.zhandarovich@fintech.ru
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Syzbot identified an issue [1] in multiq3_attach() that induces a
task timeout due to open() or COMEDI_DEVCONFIG ioctl operations,
specifically, in the case of multiq3 driver.
This problem arose when syzkaller managed to craft weird configuration
options used to specify the number of channels in encoder subdevice.
If a particularly great number is passed to s->n_chan in
multiq3_attach() via it->options[2], then multiple calls to
multiq3_encoder_reset() at the end of driver-specific attach() method
will be running for minutes, thus blocking tasks and affected devices
as well.
While this issue is most likely not too dangerous for real-life
devices, it still makes sense to sanitize configuration inputs. Enable
a sensible limit on the number of encoder chips (4 chips max, each
with 2 channels) to stop this behaviour from manifesting.
[1] Syzbot crash:
INFO: task syz.2.19:6067 blocked for more than 143 seconds.
...
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5254 [inline]
__schedule+0x17c4/0x4d60 kernel/sched/core.c:6862
__schedule_loop kernel/sched/core.c:6944 [inline]
schedule+0x165/0x360 kernel/sched/core.c:6959
schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7016
__mutex_lock_common kernel/locking/mutex.c:676 [inline]
__mutex_lock+0x7e6/0x1350 kernel/locking/mutex.c:760
comedi_open+0xc0/0x590 drivers/comedi/comedi_fops.c:2868
chrdev_open+0x4cc/0x5e0 fs/char_dev.c:414
do_dentry_open+0x953/0x13f0 fs/open.c:965
vfs_open+0x3b/0x340 fs/open.c:1097
...
Reported-by: syzbot+7811bb68a317954a0347@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=7811bb68a317954a0347
Fixes: 77e01cdbad ("Staging: comedi: add multiq3 driver")
Cc: stable <stable@kernel.org>
Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20251023132205.395753-1-n.zhandarovich@fintech.ru
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The ALSA SoC driver for Tegra runs also on SoCs without the Tegra20 APB DMA
controller (e.g. Tegra234).
Signed-off-by: Francesco Lavra <flavra@baylibre.com>
Link: https://patch.msgid.link/20251126112926.4126757-1-flavra@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
After commit b77b4a4815 ("gfs2: Rework freeze / thaw logic"),
the freeze error handling is broken because gfs2_do_thaw()
overwrites the 'error' variable, causing incorrect processing
of the original freeze error.
Fix this by calling gfs2_do_thaw() when gfs2_lock_fs_check_clean()
fails but ignoring its return value to preserve the original
freeze error for proper reporting.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: b77b4a4815 ("gfs2: Rework freeze / thaw logic")
Cc: stable@vger.kernel.org # v6.5+
Signed-off-by: Alexey Velichayshiy <a.velichayshiy@ispras.ru>
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Syzbot identified an issue [1] that crashes kernel, seemingly due to
unexistent callback dev->get_valid_routes(). By all means, this should
not occur as said callback must always be set to
get_zero_valid_routes() in __comedi_device_postconfig().
As the crash seems to appear exclusively in i386 kernels, at least,
judging from [1] reports, the blame lies with compat versions
of standard IOCTL handlers. Several of them are modified and
do not use comedi_unlocked_ioctl(). While functionality of these
ioctls essentially copy their original versions, they do not
have required sanity check for device's attached status. This,
in turn, leads to a possibility of calling select IOCTLs on a
device that has not been properly setup, even via COMEDI_DEVCONFIG.
Doing so on unconfigured devices means that several crucial steps
are missed, for instance, specifying dev->get_valid_routes()
callback.
Fix this somewhat crudely by ensuring device's attached status before
performing any ioctls, improving logic consistency between modern
and compat functions.
[1] Syzbot report:
BUG: kernel NULL pointer dereference, address: 0000000000000000
...
CR2: ffffffffffffffd6 CR3: 000000006c717000 CR4: 0000000000352ef0
Call Trace:
<TASK>
get_valid_routes drivers/comedi/comedi_fops.c:1322 [inline]
parse_insn+0x78c/0x1970 drivers/comedi/comedi_fops.c:1401
do_insnlist_ioctl+0x272/0x700 drivers/comedi/comedi_fops.c:1594
compat_insnlist drivers/comedi/comedi_fops.c:3208 [inline]
comedi_compat_ioctl+0x810/0x990 drivers/comedi/comedi_fops.c:3273
__do_compat_sys_ioctl fs/ioctl.c:695 [inline]
__se_compat_sys_ioctl fs/ioctl.c:638 [inline]
__ia32_compat_sys_ioctl+0x242/0x370 fs/ioctl.c:638
do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]
...
Reported-by: syzbot+ab8008c24e84adee93ff@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=ab8008c24e84adee93ff
Fixes: 3fbfd2223a ("comedi: get rid of compat_alloc_user_space() mess in COMEDI_CHANINFO compat")
Cc: stable <stable@kernel.org>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
Link: https://patch.msgid.link/20251023132234.395794-1-n.zhandarovich@fintech.ru
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
