Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

30 participants
6210 discussions

[PATCH v2 000/110] vfs: change inode->i_ino from unsigned long to u64

by Jeff Layton

This version splits the change up to be more bisectable. It first adds a new kino_t typedef and a new "PRIino" macro to hold the width specifier for format strings. The conversion is done, and then everything is changed to remove the new macro and typedef. I also missed a few places in the earlier set. This one hopefully does a bit more thorough job. My thanks and apologies to everyone who sent R-b/A-b for the v1 series. v2 breaks a lot of the changes up into two patches so many of those didn't carry over. Please resend those if you're still OK with it. The entire pile is in the "iino-u64" branch of my tree, if anyone is interested in testing this: https://git.kernel.org/pub/scm/linux/kernel/git/jlayton/linux.git/ Original cover letter follows: ----------------------8<----------------------- Christian said [1] to "just do it" when I proposed this, so here we are! For historical reasons, the inode->i_ino field is an unsigned long, which means that it's 32 bits on 32 bit architectures. This has caused a number of filesystems to implement hacks to hash a 64-bit identifier into a 32-bit field, and deprives us of a universal identifier field for an inode. This patchset changes the inode->i_ino field from an unsigned long to a u64. This shouldn't make any material difference on 64-bit hosts, but 32-bit hosts will see struct inode grow by at least 4 bytes. This could have effects on slabcache sizes and field alignment. The bulk of the changes are to format strings and tracepoints, since the kernel itself doesn't care that much about the i_ino field. The first patch changes some vfs function arguments, so check that one out carefully. With this change, we may be able to shrink some inode structures. For instance, struct nfs_inode has a fileid field that holds the 64-bit inode number. With this set of changes, that field could be eliminated. I'd rather leave that sort of cleanups for later just to keep this simple. Much of this set was generated by LLM, but I attributed it to myself since I consider this to be in the "menial tasks" category of LLM usage. [1]: https://lore.kernel.org/linux-fsdevel/20260219-portrait-winkt-959070cee42f@… Signed-off-by: Jeff Layton <jlayton(a)kernel.org> --- Changes in v2: - Use a typedef and macro and do the change in two steps to make it cleanly bisectable - Fix check_for_busy_inodes() in fscrypt - Added patch to reorganize tracepoint structs for better packing - Added patch to change sock.sk_ino to u64 - Added patch to clean up internal handling of inode numbers in audit subsystem - Drop some unnecessary casts - Link to v1: https://lore.kernel.org/r/20260226-iino-u64-v1-0-ccceff366db9@kernel.org --- Jeff Layton (110): vfs: introduce kino_t typedef and PRIino format macro vfs: widen inode hash/lookup functions to u64 audit: widen ino fields to u64 net: change sock.sk_ino and sock_i_ino() to u64 trace: store i_ino as u64 instead of ino_t/unsigned long trace: reorder TP_STRUCT__entry fields for better packing on 32-bit ext4: use PRIino format for i_ino jbd2: use PRIino format for i_ino f2fs: use PRIino format for i_ino lockd: use PRIino format for i_ino nfs: use PRIino format for i_ino nfsd: use PRIino format for i_ino locks: use PRIino format for i_ino proc: use PRIino format for i_ino nilfs2: use PRIino format for i_ino 9p: use PRIino format for i_ino affs: use PRIino format for i_ino afs: use PRIino format for i_ino autofs: use PRIino format for i_ino befs: use PRIino format for i_ino bfs: use PRIino format for i_ino cachefiles: use PRIino format for i_ino ceph: use PRIino format for i_ino coda: use PRIino format for i_ino cramfs: use PRIino format for i_ino ecryptfs: use PRIino format for i_ino efs: use PRIino format for i_ino exportfs: use PRIino format for i_ino ext2: use PRIino format for i_ino freevxfs: use PRIino format for i_ino hfs: use PRIino format for i_ino hfsplus: use PRIino format for i_ino hpfs: use PRIino format for i_ino isofs: use PRIino format for i_ino jffs2: use PRIino format for i_ino jfs: use PRIino format for i_ino minix: use PRIino format for i_ino nsfs: use PRIino format for i_ino ntfs3: use PRIino format for i_ino ocfs2: use PRIino format for i_ino orangefs: use PRIino format for i_ino overlayfs: use PRIino format for i_ino qnx4: use PRIino format for i_ino qnx6: use PRIino format for i_ino ubifs: use PRIino format for i_ino udf: use PRIino format for i_ino ufs: use PRIino format for i_ino zonefs: use PRIino format for i_ino security: use PRIino format for i_ino drm/amdgpu: use PRIino format for i_ino fsnotify: use PRIino format for i_ino net: use PRIino format for i_ino uprobes: use PRIino format for i_ino dma-buf: use PRIino format for i_ino fscrypt: use PRIino format for i_ino fsverity: use PRIino format for i_ino iomap: use PRIino format for i_ino net: use PRIino format for i_ino vfs: use PRIino format for i_ino vfs: change kino_t from unsigned long to u64 ext4: replace PRIino with %llu/%llx format strings jbd2: replace PRIino with %llu/%llx format strings f2fs: replace PRIino with %llu/%llx format strings lockd: replace PRIino with %llu/%llx format strings nfs: replace PRIino with %llu/%llx format strings nfsd: replace PRIino with %llu/%llx format strings proc: replace PRIino with %llu/%llx format strings nilfs2: replace PRIino with %llu/%llx format strings 9p: replace PRIino with %llu/%llx format strings affs: replace PRIino with %llu/%llx format strings afs: replace PRIino with %llu/%llx format strings autofs: replace PRIino with %llu/%llx format strings befs: replace PRIino with %llu/%llx format strings bfs: replace PRIino with %llu/%llx format strings cachefiles: replace PRIino with %llu/%llx format strings ceph: replace PRIino with %llu/%llx format strings coda: replace PRIino with %llu/%llx format strings cramfs: replace PRIino with %llu/%llx format strings ecryptfs: replace PRIino with %llu/%llx format strings efs: replace PRIino with %llu/%llx format strings exportfs: replace PRIino with %llu/%llx format strings ext2: replace PRIino with %llu/%llx format strings freevxfs: replace PRIino with %llu/%llx format strings hfs: replace PRIino with %llu/%llx format strings hfsplus: replace PRIino with %llu/%llx format strings hpfs: replace PRIino with %llu/%llx format strings isofs: replace PRIino with %llu/%llx format strings jffs2: replace PRIino with %llu/%llx format strings jfs: replace PRIino with %llu/%llx format strings minix: replace PRIino with %llu/%llx format strings ntfs3: replace PRIino with %llu/%llx format strings ocfs2: replace PRIino with %llu/%llx format strings orangefs: replace PRIino with %llu/%llx format strings overlayfs: replace PRIino with %llu/%llx format strings qnx4: replace PRIino with %llu/%llx format strings qnx6: replace PRIino with %llu/%llx format strings ubifs: replace PRIino with %llu/%llx format strings udf: replace PRIino with %llu/%llx format strings ufs: replace PRIino with %llu/%llx format strings zonefs: replace PRIino with %llu/%llx format strings fscrypt: replace PRIino with %llu/%llx format strings fsverity: replace PRIino with %llu/%llx format strings iomap: replace PRIino with %llu/%llx format strings fsnotify: replace PRIino with %llu/%llx format strings security: replace PRIino with %llu/%llx format strings drm/amdgpu: replace PRIino with %llu/%llx format strings dma-buf: replace PRIino with %llu/%llx format strings net: replace PRIino with %llu/%llx format strings uprobes: replace PRIino with %llu/%llx format strings vfs: remove kino_t typedef and PRIino format macro drivers/dma-buf/dma-buf.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4 +- fs/9p/vfs_addr.c | 4 +- fs/9p/vfs_inode.c | 6 +- fs/9p/vfs_inode_dotl.c | 6 +- fs/affs/amigaffs.c | 8 +- fs/affs/bitmap.c | 2 +- fs/affs/dir.c | 2 +- fs/affs/file.c | 20 +- fs/affs/inode.c | 12 +- fs/affs/namei.c | 14 +- fs/affs/symlink.c | 2 +- fs/afs/dir.c | 10 +- fs/afs/dir_search.c | 2 +- fs/afs/dynroot.c | 2 +- fs/afs/inode.c | 2 +- fs/autofs/inode.c | 2 +- fs/befs/linuxvfs.c | 28 +- fs/bfs/dir.c | 4 +- fs/cachefiles/io.c | 6 +- fs/cachefiles/namei.c | 12 +- fs/cachefiles/xattr.c | 2 +- fs/ceph/crypto.c | 4 +- fs/coda/dir.c | 2 +- fs/coda/inode.c | 2 +- fs/cramfs/inode.c | 2 +- fs/crypto/crypto.c | 2 +- fs/crypto/hooks.c | 2 +- fs/crypto/keyring.c | 4 +- fs/crypto/keysetup.c | 2 +- fs/dcache.c | 4 +- fs/ecryptfs/crypto.c | 6 +- fs/ecryptfs/file.c | 2 +- fs/efs/inode.c | 6 +- fs/eventpoll.c | 2 +- fs/exportfs/expfs.c | 4 +- fs/ext2/dir.c | 10 +- fs/ext2/ialloc.c | 9 +- fs/ext2/inode.c | 2 +- fs/ext2/trace.h | 8 +- fs/ext2/xattr.c | 14 +- fs/ext4/dir.c | 2 +- fs/ext4/ext4.h | 4 +- fs/ext4/extents.c | 8 +- fs/ext4/extents_status.c | 28 +- fs/ext4/fast_commit.c | 8 +- fs/ext4/ialloc.c | 10 +- fs/ext4/indirect.c | 2 +- fs/ext4/inline.c | 14 +- fs/ext4/inode.c | 22 +- fs/ext4/ioctl.c | 4 +- fs/ext4/mballoc.c | 6 +- fs/ext4/migrate.c | 2 +- fs/ext4/move_extent.c | 20 +- fs/ext4/namei.c | 10 +- fs/ext4/orphan.c | 16 +- fs/ext4/page-io.c | 10 +- fs/ext4/super.c | 22 +- fs/ext4/xattr.c | 10 +- fs/f2fs/compress.c | 4 +- fs/f2fs/dir.c | 2 +- fs/f2fs/extent_cache.c | 8 +- fs/f2fs/f2fs.h | 6 +- fs/f2fs/file.c | 12 +- fs/f2fs/gc.c | 2 +- fs/f2fs/inline.c | 4 +- fs/f2fs/inode.c | 48 ++-- fs/f2fs/namei.c | 8 +- fs/f2fs/node.c | 12 +- fs/f2fs/recovery.c | 10 +- fs/f2fs/xattr.c | 10 +- fs/freevxfs/vxfs_bmap.c | 4 +- fs/fserror.c | 2 +- fs/hfs/catalog.c | 2 +- fs/hfs/extent.c | 4 +- fs/hfs/inode.c | 4 +- fs/hfsplus/attributes.c | 10 +- fs/hfsplus/catalog.c | 2 +- fs/hfsplus/dir.c | 6 +- fs/hfsplus/extents.c | 6 +- fs/hfsplus/inode.c | 8 +- fs/hfsplus/super.c | 6 +- fs/hfsplus/xattr.c | 10 +- fs/hpfs/dir.c | 4 +- fs/hpfs/dnode.c | 4 +- fs/hpfs/ea.c | 4 +- fs/hpfs/inode.c | 4 +- fs/inode.c | 49 ++-- fs/iomap/ioend.c | 2 +- fs/iomap/trace.h | 8 +- fs/isofs/compress.c | 2 +- fs/isofs/dir.c | 2 +- fs/isofs/inode.c | 6 +- fs/isofs/namei.c | 2 +- fs/jbd2/journal.c | 4 +- fs/jbd2/transaction.c | 2 +- fs/jffs2/dir.c | 4 +- fs/jffs2/file.c | 4 +- fs/jffs2/fs.c | 18 +- fs/jfs/inode.c | 2 +- fs/jfs/jfs_imap.c | 2 +- fs/jfs/jfs_metapage.c | 2 +- fs/lockd/svclock.c | 8 +- fs/lockd/svcsubs.c | 2 +- fs/locks.c | 6 +- fs/minix/inode.c | 10 +- fs/nfs/dir.c | 20 +- fs/nfs/file.c | 8 +- fs/nfs/filelayout/filelayout.c | 8 +- fs/nfs/flexfilelayout/flexfilelayout.c | 8 +- fs/nfs/inode.c | 6 +- fs/nfs/nfs4proc.c | 4 +- fs/nfs/pnfs.c | 12 +- fs/nfsd/export.c | 2 +- fs/nfsd/nfs4state.c | 4 +- fs/nfsd/nfsfh.c | 4 +- fs/nfsd/vfs.c | 2 +- fs/nilfs2/alloc.c | 10 +- fs/nilfs2/bmap.c | 2 +- fs/nilfs2/btnode.c | 2 +- fs/nilfs2/btree.c | 12 +- fs/nilfs2/dir.c | 12 +- fs/nilfs2/direct.c | 4 +- fs/nilfs2/gcinode.c | 2 +- fs/nilfs2/inode.c | 8 +- fs/nilfs2/mdt.c | 2 +- fs/nilfs2/namei.c | 2 +- fs/nilfs2/segment.c | 2 +- fs/notify/fdinfo.c | 4 +- fs/nsfs.c | 4 +- fs/ntfs3/super.c | 2 +- fs/ocfs2/alloc.c | 2 +- fs/ocfs2/aops.c | 4 +- fs/ocfs2/dir.c | 8 +- fs/ocfs2/dlmfs/dlmfs.c | 10 +- fs/ocfs2/extent_map.c | 12 +- fs/ocfs2/inode.c | 2 +- fs/ocfs2/quota_local.c | 2 +- fs/ocfs2/refcounttree.c | 10 +- fs/ocfs2/xattr.c | 4 +- fs/orangefs/inode.c | 2 +- fs/overlayfs/export.c | 2 +- fs/overlayfs/namei.c | 4 +- fs/overlayfs/util.c | 2 +- fs/pipe.c | 2 +- fs/proc/fd.c | 2 +- fs/proc/task_mmu.c | 4 +- fs/qnx4/inode.c | 4 +- fs/qnx6/inode.c | 2 +- fs/ubifs/debug.c | 8 +- fs/ubifs/dir.c | 28 +- fs/ubifs/file.c | 28 +- fs/ubifs/journal.c | 6 +- fs/ubifs/super.c | 16 +- fs/ubifs/tnc.c | 4 +- fs/ubifs/xattr.c | 14 +- fs/udf/directory.c | 18 +- fs/udf/file.c | 2 +- fs/udf/inode.c | 12 +- fs/udf/namei.c | 8 +- fs/udf/super.c | 2 +- fs/ufs/balloc.c | 6 +- fs/ufs/dir.c | 10 +- fs/ufs/ialloc.c | 6 +- fs/ufs/inode.c | 18 +- fs/ufs/ufs_fs.h | 6 +- fs/ufs/util.c | 2 +- fs/verity/init.c | 2 +- fs/zonefs/super.c | 8 +- fs/zonefs/trace.h | 18 +- include/linux/audit.h | 2 +- include/linux/fs.h | 28 +- include/net/sock.h | 4 +- include/trace/events/cachefiles.h | 18 +- include/trace/events/ext4.h | 423 +++++++++++++++-------------- include/trace/events/f2fs.h | 172 ++++++------ include/trace/events/filelock.h | 34 +-- include/trace/events/filemap.h | 20 +- include/trace/events/fs_dax.h | 20 +- include/trace/events/fsverity.h | 30 +- include/trace/events/hugetlbfs.h | 42 +-- include/trace/events/netfs.h | 8 +- include/trace/events/nilfs2.h | 12 +- include/trace/events/readahead.h | 18 +- include/trace/events/timestamp.h | 16 +- include/trace/events/writeback.h | 162 +++++------ kernel/audit.h | 9 +- kernel/audit_fsnotify.c | 4 +- kernel/audit_watch.c | 8 +- kernel/auditsc.c | 2 +- kernel/events/uprobes.c | 4 +- net/ax25/af_ax25.c | 2 +- net/bluetooth/af_bluetooth.c | 4 +- net/can/bcm.c | 2 +- net/ipv4/ping.c | 2 +- net/ipv4/raw.c | 2 +- net/ipv4/tcp_ipv4.c | 2 +- net/ipv4/udp.c | 2 +- net/ipv6/datagram.c | 2 +- net/ipv6/tcp_ipv6.c | 2 +- net/key/af_key.c | 2 +- net/netlink/af_netlink.c | 2 +- net/netlink/diag.c | 2 +- net/netrom/af_netrom.c | 4 +- net/packet/af_packet.c | 2 +- net/packet/diag.c | 2 +- net/phonet/socket.c | 4 +- net/rose/af_rose.c | 4 +- net/sctp/proc.c | 4 +- net/socket.c | 2 +- net/unix/af_unix.c | 2 +- net/unix/diag.c | 6 +- net/x25/x25_proc.c | 4 +- net/xdp/xsk_diag.c | 2 +- security/apparmor/apparmorfs.c | 4 +- security/integrity/integrity_audit.c | 2 +- security/ipe/audit.c | 2 +- security/lsm_audit.c | 10 +- security/selinux/hooks.c | 10 +- security/smack/smack_lsm.c | 12 +- 220 files changed, 1181 insertions(+), 1181 deletions(-) --- base-commit: 842cfe0733c5a03982a7ae496de6fdc0dd661a41 change-id: 20260224-iino-u64-b44a3a72543c Best regards, -- Jeff Layton <jlayton(a)kernel.org>

1 month, 2 weeks

[PATCH RFC 00/18] accel/qda: Introduce Qualcomm DSP Accelerator driver

by Ekansh Gupta

This patch series introduces the Qualcomm DSP Accelerator (QDA) driver, a modern DRM-based accelerator implementation for Qualcomm Hexagon DSPs. The driver provides a standardized interface for offloading computational tasks to DSPs found on Qualcomm SoCs, supporting all DSP domains (ADSP, CDSP, SDSP, GDSP). The QDA driver is designed as an alternative for the FastRPC driver in drivers/misc/, offering improved resource management, better integration with standard kernel subsystems, and alignment with the Linux kernel's Compute Accelerators framework. User-space staging branch ============ https://github.com/qualcomm/fastrpc/tree/accel/staging Key Features ============ * Standard DRM accelerator interface via /dev/accel/accelN * GEM-based buffer management with DMA-BUF import/export support * IOMMU-based memory isolation using per-process context banks * FastRPC protocol implementation for DSP communication * RPMsg transport layer for reliable message passing * Support for all DSP domains (ADSP, CDSP, SDSP, GDSP) * Comprehensive IOCTL interface for DSP operations High-Level Architecture Differences with Existing FastRPC Driver ================================================================= The QDA driver represents a significant architectural departure from the existing FastRPC driver (drivers/misc/fastrpc.c), addressing several key limitations while maintaining protocol compatibility: 1. DRM Accelerator Framework Integration - FastRPC: Custom character device (/dev/fastrpc-*) - QDA: Standard DRM accel device (/dev/accel/accelN) - Benefit: Leverages established DRM infrastructure for device management. 2. Memory Management - FastRPC: Custom memory allocator with ION/DMA-BUF integration - QDA: Native GEM objects with full PRIME support - Benefit: Seamless buffer sharing using standard DRM mechanisms 3. IOMMU Context Bank Management - FastRPC: Direct IOMMU domain manipulation, limited isolation - QDA: Custom compute bus (qda_cb_bus_type) with proper device model - Benefit: Each CB device is a proper struct device with IOMMU group support, enabling better isolation and resource tracking. - https://lore.kernel.org/all/245d602f-3037-4ae3-9af9-d98f37258aae@oss.qualco… 4. Memory Manager Architecture - FastRPC: Monolithic allocator - QDA: Pluggable memory manager with backend abstraction - Benefit: Currently uses DMA-coherent backend, easily extensible for future memory types (e.g., carveout, CMA) 5. Transport Layer - FastRPC: Direct RPMsg integration in core driver - QDA: Abstracted transport layer (qda_rpmsg.c) - Benefit: Clean separation of concerns, easier to add alternative transports if needed 8. Code Organization - FastRPC: ~3000 lines in single file - QDA: Modular design across multiple files (~4600 lines total) * qda_drv.c: Core driver and DRM integration * qda_gem.c: GEM object management * qda_memory_manager.c: Memory and IOMMU management * qda_fastrpc.c: FastRPC protocol implementation * qda_rpmsg.c: Transport layer * qda_cb.c: Context bank device management - Benefit: Better maintainability, clearer separation of concerns 9. UAPI Design - FastRPC: Custom IOCTL interface - QDA: DRM-style IOCTLs with proper versioning support - Benefit: Follows DRM conventions, easier userspace integration 10. Documentation - FastRPC: Minimal in-tree documentation - QDA: Comprehensive documentation in Documentation/accel/qda/ - Benefit: Better developer experience, clearer API contracts 11. Buffer Reference Mechanism - FastRPC: Uses buffer file descriptors (FDs) for all book-keeping in both kernel and DSP - QDA: Uses GEM handles for kernel-side management, providing better integration with DRM subsystem - Benefit: Leverages DRM GEM infrastructure for reference counting, lifetime management, and integration with other DRM components Key Technical Improvements =========================== * Proper device model: CB devices are real struct device instances on a custom bus, enabling proper IOMMU group management and power management integration * Reference-counted IOMMU devices: Multiple file descriptors from the same process share a single IOMMU device, reducing overhead * GEM-based buffer lifecycle: Automatic cleanup via DRM GEM reference counting, eliminating many resource leak scenarios * Modular memory backends: The memory manager supports pluggable backends, currently implementing DMA-coherent allocations with SID-prefixed addresses for DSP firmware * Context-based invocation tracking: XArray-based context management with proper synchronization and cleanup Patch Series Organization ========================== Patches 1-2: Driver skeleton and documentation Patches 3-6: RPMsg transport and IOMMU/CB infrastructure Patches 7-9: DRM device registration and basic IOCTL Patches 10-12: GEM buffer management and PRIME support Patches 13-17: FastRPC protocol implementation (attach, invoke, create, map/unmap) Patch 18: MAINTAINERS entry Open Items =========== The following items are identified as open items: 1. Privilege Level Management - Currently, daemon processes and user processes have the same access level as both use the same accel device node. This needs to be addressed as daemons attach to privileged DSP PDs and require higher privilege levels for system-level operations - Seeking guidance on the best approach: separate device nodes, capability-based checks, or DRM master/authentication mechanisms 2. UAPI Compatibility Layer - Add UAPI compat layer to facilitate migration of client applications from existing FastRPC UAPI to the new QDA accel driver UAPI, ensuring smooth transition for existing userspace code - Seeking guidance on implementation approach: in-kernel translation layer, userspace wrapper library, or hybrid solution 3. Documentation Improvements - Add detailed IOCTL usage examples - Document DSP firmware interface requirements - Create migration guide from existing FastRPC 4. Per-Domain Memory Allocation - Develop new userspace API to support memory allocation on a per domain basis, enabling domain-specific memory management and optimization 5. Audio and Sensors PD Support - The current patch series does not handle Audio PD and Sensors PD functionalities. These specialized protection domains require additional support for real-time constraints and power management Interface Compatibility ======================== The QDA driver maintains compatibility with existing FastRPC infrastructure: * Device Tree Bindings: The driver uses the same device tree bindings as the existing FastRPC driver, ensuring no changes are required to device tree sources. The "qcom,fastrpc" compatible string and child node structure remain unchanged. * Userspace Interface: While the driver provides a new DRM-based UAPI, the underlying FastRPC protocol and DSP firmware interface remain compatible. This ensures that DSP firmware and libraries continue to work without modification. * Migration Path: The modular design allows for gradual migration, where both drivers can coexist during the transition period. Applications can be migrated incrementally to the new UAPI with the help of the planned compatibility layer. References ========== Previous discussions on this migration: - https://lkml.org/lkml/2024/6/24/479 - https://lkml.org/lkml/2024/6/21/1252 Testing ======= The driver has been tested on Qualcomm platforms with: - Basic FastRPC attach/release operations - DSP process creation and initialization - Memory mapping/unmapping operations - Dynamic invocation with various buffer types - GEM buffer allocation and mmap - PRIME buffer import from other subsystems Signed-off-by: Ekansh Gupta <ekansh.gupta(a)oss.qualcomm.com> --- Ekansh Gupta (18): accel/qda: Add Qualcomm QDA DSP accelerator driver docs accel/qda: Add Qualcomm DSP accelerator driver skeleton accel/qda: Add RPMsg transport for Qualcomm DSP accelerator accel/qda: Add built-in compute CB bus for QDA and integrate with IOMMU accel/qda: Create compute CB devices on QDA compute bus accel/qda: Add memory manager for CB devices accel/qda: Add DRM accel device registration for QDA driver accel/qda: Add per-file DRM context and open/close handling accel/qda: Add QUERY IOCTL and basic QDA UAPI header accel/qda: Add DMA-backed GEM objects and memory manager integration accel/qda: Add GEM_CREATE and GEM_MMAP_OFFSET IOCTLs accel/qda: Add PRIME dma-buf import support accel/qda: Add initial FastRPC attach and release support accel/qda: Add FastRPC dynamic invocation support accel/qda: Add FastRPC DSP process creation support accel/qda: Add FastRPC-based DSP memory mapping support accel/qda: Add FastRPC-based DSP memory unmapping support MAINTAINERS: Add MAINTAINERS entry for QDA driver Documentation/accel/index.rst | 1 + Documentation/accel/qda/index.rst | 14 + Documentation/accel/qda/qda.rst | 129 ++++ MAINTAINERS | 9 + arch/arm64/configs/defconfig | 2 + drivers/accel/Kconfig | 1 + drivers/accel/Makefile | 2 + drivers/accel/qda/Kconfig | 35 ++ drivers/accel/qda/Makefile | 19 + drivers/accel/qda/qda_cb.c | 182 ++++++ drivers/accel/qda/qda_cb.h | 26 + drivers/accel/qda/qda_compute_bus.c | 23 + drivers/accel/qda/qda_drv.c | 375 ++++++++++++ drivers/accel/qda/qda_drv.h | 171 ++++++ drivers/accel/qda/qda_fastrpc.c | 1002 ++++++++++++++++++++++++++++++++ drivers/accel/qda/qda_fastrpc.h | 433 ++++++++++++++ drivers/accel/qda/qda_gem.c | 211 +++++++ drivers/accel/qda/qda_gem.h | 103 ++++ drivers/accel/qda/qda_ioctl.c | 271 +++++++++ drivers/accel/qda/qda_ioctl.h | 118 ++++ drivers/accel/qda/qda_memory_dma.c | 91 +++ drivers/accel/qda/qda_memory_dma.h | 46 ++ drivers/accel/qda/qda_memory_manager.c | 382 ++++++++++++ drivers/accel/qda/qda_memory_manager.h | 148 +++++ drivers/accel/qda/qda_prime.c | 194 +++++++ drivers/accel/qda/qda_prime.h | 43 ++ drivers/accel/qda/qda_rpmsg.c | 327 +++++++++++ drivers/accel/qda/qda_rpmsg.h | 57 ++ drivers/iommu/iommu.c | 4 + include/linux/qda_compute_bus.h | 22 + include/uapi/drm/qda_accel.h | 224 +++++++ 31 files changed, 4665 insertions(+) --- base-commit: d4906ae14a5f136ceb671bb14cedbf13fa560da6 change-id: 20260223-qda-firstpost-4ab05249e2cc Best regards, -- Ekansh Gupta <ekansh.gupta(a)oss.qualcomm.com>

1 month, 2 weeks

Primatz Guard Recovery: Addressing Romance Scams Linked to Digital Assets

by phillipsmathew895＠gmail.com

Romance scams begin with emotional trust-building, often through social media or messaging apps. Scammers later introduce supposed crypto or digital asset investment opportunities and persuade victims to transfer funds. Once payments are made, communication fades and funds become difficult to retrieve. Primatz Guard Recovery supports victims by reviewing financial trails, identifying scam tactics, and providing guidance on recovery steps with no consultation charges. Staying cautious with online relationships and avoiding financial commitments based on emotional pressure remains essential. Homepage: Primatz Guard Recovery

1 month, 2 weeks

How To Recover Lost Funds From Online Investment Scam - Reach Out To Betafort Recovery

by glennkael8＠gmail.com

With professionalism and integrity, Betafort Recovery assures that their clients get the finest possible help in retrieving their lost digital assets. With a staff of professionals dedicated to assisting individuals in navigating the recovery process, they provide 24 hour support to guarantee that customers receive timely and effective assistance when they need it the most. Testimonials from delighted clients demonstrate Betafort Recovery abilities in recovering lost digital assets, emphasizing their dedication to client satisfaction and good outcomes. NO UPFRONT FEES REQUIRED. Online presence: Betafort Recovery

1 month, 2 weeks

[PATCH v2 0/6] dma-buf: heaps: add coherent reserved-memory heap

by Albert Esteve

This patch introduces a new heap driver to expose DT non‑reusable "shared-dma-pool" coherent regions as dma-buf heaps, so userspace can allocate buffers from each reserved, named region. Because these regions are device‑dependent, each heap instance binds a heap device to its reserved‑mem region via a newly introduced helper function -namely, of_reserved_mem_device_init_with_mem()- so coherent allocations use the correct dev->dma_mem. Charging to cgroups for these buffers is intentionally left out to keep review focused on the new heap; I plan to follow up based on Eric’s [1] and Maxime’s [2] work on dmem charging from userspace. This series also makes the new heap driver modular, in line with the CMA heap change in [3]. [1] https://lore.kernel.org/all/20260218-dmabuf-heap-cma-dmem-v2-0-b249886fb7b2… [2] https://lore.kernel.org/all/20250310-dmem-cgroups-v1-0-2984c1bc9312@kernel.… [3] https://lore.kernel.org/all/20260303-dma-buf-heaps-as-modules-v3-0-24344812… Signed-off-by: Albert Esteve <aesteve(a)redhat.com> --- Changes in v2: - Removed dmem charging parts - Moved coherent heap registering logic to coherent.c - Made heap device a member of struct dma_heap - Split dma_heap_add logic into create/register, to be able to access the stored heap device before registered. - Avoid platform device in favour of heap device - Added a wrapper to rmem device_init() op - Switched from late_initcall() to module_init() - Made the coherent heap driver modular - Link to v1: https://lore.kernel.org/r/20260224-b4-dmabuf-heap-coherent-rmem-v1-1-dffef4… --- Albert Esteve (5): dma-buf: dma-heap: split dma_heap_add of_reserved_mem: add a helper for rmem device_init op dma-buf: heaps: Add Coherent heap to dmabuf heaps dma: coherent: register to coherent heap dma-buf: heaps: coherent: Turn heap into a module John Stultz (1): dma-buf: dma-heap: Keep track of the heap device struct drivers/dma-buf/dma-heap.c | 138 +++++++++-- drivers/dma-buf/heaps/Kconfig | 9 + drivers/dma-buf/heaps/Makefile | 1 + drivers/dma-buf/heaps/coherent_heap.c | 429 ++++++++++++++++++++++++++++++++++ drivers/of/of_reserved_mem.c | 27 ++- include/linux/dma-heap.h | 16 ++ include/linux/dma-map-ops.h | 7 + include/linux/of_reserved_mem.h | 8 + kernel/dma/coherent.c | 34 +++ 9 files changed, 642 insertions(+), 27 deletions(-) --- base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f change-id: 20260223-b4-dmabuf-heap-coherent-rmem-91fd3926afe9 Best regards, -- Albert Esteve <aesteve(a)redhat.com>

1 month, 2 weeks

Forgot Your Crypto Wallet Password? Here's What to Do

by hamtonbecky＠gmail.com

Forgetting the password to your crypto wallet can be incredibly stressful, especially with valuable assets at stake. Unlike traditional accounts, most non-custodial crypto wallets (like MetaMask, Exodus, Electrum, or hardware wallets) don't offer simple "forgot password" resets. Recovery depends entirely on your wallet type and backups. Key Recovery Options If You Have Your Recovery Phrase (Seed Phrase) This is the most reliable method. Most wallets use a 12- or 24-word recovery phrase to restore access. Uninstall/reinstall the wallet app or extension. Choose "Import" or "Recover" wallet. Enter your seed phrase. Set a new password. This works for wallets like Crypto.com, Bitcoin.com, and many others. Always store your seed phrase securely offline. For Custodial Wallets/Exchanges If your funds are on a platform like Blockchain.com (trading account) or an exchange, use their official "Forgot Password" feature. Enter your email/phone, verify identity, and reset via link or support. These are easier since the platform holds keys. Try Remembering or Brute-Forcing (Limited Success) Brainstorm variations based on hints, patterns, or old passwords. For some wallets (e.g., Bitcoin Core .dat files), advanced users try tools like Hashcat or John the Ripper on their own hardware. This is time-consuming, technical, and often unsuccessful for strong passwords. If Nothing Works Without the seed phrase or backups, self-recovery is usually impossible due to crypto's strong security design. Many users permanently lose access. If you need expert help, reach out to Cryptera Chain Signals (CCS), a specialized firm in crypto fund recovery and wallet restoration. They assist with inaccessible wallets and related issues using advanced forensics and tracing. Website: https://www.crypterachainsignals.com/ Email: info(a)crypterachainsignals.com Important Warnings Never share your seed phrase, private keys, or password with anyone. Beware of scams promising guaranteed recovery for upfront fees. Prevention is key: Back up your seed phrase securely and use strong, memorable passwords. Act quickly and carefully your funds depend on it. Good luck!

1 month, 2 weeks

Re: [PATCH v2 040/110] ocfs2: use PRIino format for i_ino

by jack＠suse.cz

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

1 month, 2 weeks

[PATCH RFC 00/26] Add DMA-buf mapping types and convert vfio/iommufd to use them

by Jason Gunthorpe

Since its introduction, DMA-buf has only supported using scatterlist for the exporter and importer to exchange address information. This is not sufficient for all use cases as dma_addr_t is a very specific and limited type that should not be abused for things unrelated to the DMA API. There are several motivations for addressing this now: 1) VFIO to IOMMUFD and KVM requires a physical address, not a dma_addr_t scatterlist, it cannot be represented in the scatterlist structure 2) xe vGPU requires the host driver to accept a DMABUF from VFIO of its own VF and convert it into an internal VRAM address on the PF 3) We are starting to look at replacement datastructures for scatterlist 4) Ideas around UALink/etc are suggesting not using the DMA API None of these can sanely be achieved using scatterlist. Introduce a new mechanism called "mapping types" which allows DMA-buf to work with more map/unmap options than scatterlist. Each mapping type encompasses a full set of functions and data unique to itself. The core code provides a match-making system to select the best type offered by the exporter and importer to be the active mapping type for the attachment. Everything related to scatterlist is moved into a DMA-buf SGT mapping type, and into the "dma_buf_sgt_*" namespace for clarity. Existing exporters are moved over to explicitly declare SGT mapping types and importers are adjusted to use the dma_buf_sgt_* named importer helpers. Mapping types are designed to be extendable, a driver can declare its own mapping type for its internal private interconnect and use that without having to adjust the core code. The new attachment sequence starts with the importing driver declaring what mapping types it can accept: struct dma_buf_mapping_match imp_match[] = { DMA_BUF_IMAPPING_MY_DRIVER(dev, ...), DMA_BUF_IMAPPING_SGT(dev, false), }; attach = dma_buf_mapping_attach(dmabuf, imp_match, ...) Most drivers will do this via a dma_buf_sgt_*attach() helper. The exporting driver can then declare what mapping types it can supply: int exporter_match_mapping(struct dma_buf_match_args *args) { struct dma_buf_mapping_match exp_match[] = { DMA_BUF_EMAPPING_MY_DRIVER(my_ops, dev, ...), DMA_BUF_EMAPPING_SGT(sgt_ops, dev, false), DMA_BUF_EMAPPING_PAL(PAL_ops), }; return dma_buf_match_mapping(args, exp_match, ...); } Most drivers will do this via a helper: static const struct dma_buf_ops ops = { DMA_BUF_SIMPLE_SGT_EXP_MATCH(map_func, unmap_func) }; During dma_buf_mapping_attach() the core code will select a mutual match between the importer and exporter and record it as the active match in the attach->map_type. Each mapping type has its own types/function calls for mapping/unmapping, and storage in the attach->map_type for its information. As such each mapping type can offer function signatures and data that exactly matches its needs. This series goes through a sequence of: 1) Introduce the basic mapping type framework and the main components of the SGT mapping type 2) Automatically make all existing exporters and importers use core generated SGT mapping types so every attachment has a SGT mapping type 3) Convert all exporter drivers to natively create a SGT mapping type 4) Move all dma_buf_* functions and types that are related to SGT into dma_buf_sgt_* 5) Remove all the now-unused items that have been moved into SGT specific structures. 6) Demonstrate adding a new Physical Address List alongside SGT. Due to the high number of files touched I would expect this to be broken into phases, but this shows the entire picture. This is on github: https://github.com/jgunthorpe/linux/commits/dmabuf_map_type It is a followup to the discussion here: https://lore.kernel.org/dri-devel/20251027044712.1676175-1-vivek.kasireddy@… Jason Gunthorpe (26): dma-buf: Introduce DMA-buf mapping types dma-buf: Add the SGT DMA mapping type dma-buf: Add dma_buf_mapping_attach() dma-buf: Route SGT related actions through attach->map_type dma-buf: Allow single exporter drivers to avoid the match_mapping function drm: Check the SGT ops for drm_gem_map_dma_buf() dma-buf: Convert all the simple exporters to use SGT mapping type drm/vmwgfx: Use match_mapping instead of dummy calls accel/habanalabs: Use the SGT mapping type drm/xe/dma-buf: Use the SGT mapping type drm/amdgpu: Use the SGT mapping type vfio/pci: Change the DMA-buf exporter to use mapping_type dma-buf: Update dma_buf_phys_vec_to_sgt() to use the SGT mapping type iio: buffer: convert to use the SGT mapping type functionfs: convert to use the SGT mapping type dma-buf: Remove unused SGT stuff from the common structures treewide: Rename dma_buf_map_attachment(_unlocked) to dma_buf_sgt_ treewide: Rename dma_buf_unmap_attachment(_unlocked) to dma_buf_sgt_* treewide: Rename dma_buf_attach() to dma_buf_sgt_attach() treewide: Rename dma_buf_dynamic_attach() to dma_buf_sgt_dynamic_attach() dma-buf: Add the Physical Address List DMA mapping type vfio/pci: Add physical address list support to DMABUF iommufd: Use the PAL mapping type instead of a vfio function iommufd: Support DMA-bufs with multiple physical ranges iommufd/selftest: Check multi-phys DMA-buf scenarios dma-buf: Add kunit tests for mapping type Documentation/gpu/todo.rst | 2 +- drivers/accel/amdxdna/amdxdna_gem.c | 14 +- drivers/accel/amdxdna/amdxdna_ubuf.c | 10 +- drivers/accel/habanalabs/common/memory.c | 54 ++- drivers/accel/ivpu/ivpu_gem.c | 10 +- drivers/accel/ivpu/ivpu_gem_userptr.c | 11 +- drivers/accel/qaic/qaic_data.c | 8 +- drivers/dma-buf/Makefile | 1 + drivers/dma-buf/dma-buf-mapping.c | 186 ++++++++- drivers/dma-buf/dma-buf.c | 180 ++++++--- drivers/dma-buf/heaps/cma_heap.c | 12 +- drivers/dma-buf/heaps/system_heap.c | 13 +- drivers/dma-buf/st-dma-mapping.c | 373 ++++++++++++++++++ drivers/dma-buf/udmabuf.c | 8 +- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 98 +++-- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 +- drivers/gpu/drm/armada/armada_gem.c | 33 +- drivers/gpu/drm/drm_gem_shmem_helper.c | 2 +- drivers/gpu/drm/drm_prime.c | 31 +- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 18 +- drivers/gpu/drm/i915/gem/i915_gem_object.c | 2 +- .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 8 +- .../gpu/drm/i915/gem/selftests/mock_dmabuf.c | 8 +- drivers/gpu/drm/msm/msm_gem_prime.c | 7 +- drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 11 +- drivers/gpu/drm/tegra/gem.c | 33 +- drivers/gpu/drm/virtio/virtgpu_prime.c | 23 +- drivers/gpu/drm/vmwgfx/vmwgfx_prime.c | 32 +- drivers/gpu/drm/xe/xe_bo.c | 18 +- drivers/gpu/drm/xe/xe_dma_buf.c | 61 +-- drivers/iio/industrialio-buffer.c | 15 +- drivers/infiniband/core/umem_dmabuf.c | 15 +- drivers/iommu/iommufd/io_pagetable.h | 4 +- drivers/iommu/iommufd/iommufd_private.h | 8 - drivers/iommu/iommufd/iommufd_test.h | 7 + drivers/iommu/iommufd/pages.c | 85 ++-- drivers/iommu/iommufd/selftest.c | 177 ++++++--- .../media/common/videobuf2/videobuf2-core.c | 2 +- .../common/videobuf2/videobuf2-dma-contig.c | 26 +- .../media/common/videobuf2/videobuf2-dma-sg.c | 21 +- .../common/videobuf2/videobuf2-vmalloc.c | 13 +- .../platform/nvidia/tegra-vde/dmabuf-cache.c | 9 +- drivers/misc/fastrpc.c | 21 +- drivers/tee/tee_heap.c | 13 +- drivers/usb/gadget/function/f_fs.c | 11 +- drivers/vfio/pci/vfio_pci_dmabuf.c | 79 ++-- drivers/xen/gntdev-dmabuf.c | 29 +- include/linux/dma-buf-mapping.h | 297 ++++++++++++++ include/linux/dma-buf.h | 168 ++++---- io_uring/zcrx.c | 9 +- net/core/devmem.c | 14 +- samples/vfio-mdev/mbochs.c | 10 +- sound/soc/fsl/fsl_asrc_m2m.c | 12 +- tools/testing/selftests/iommu/iommufd.c | 43 ++ tools/testing/selftests/iommu/iommufd_utils.h | 17 + 55 files changed, 1764 insertions(+), 614 deletions(-) create mode 100644 drivers/dma-buf/st-dma-mapping.c base-commit: c63e5a50e1dd291cd95b04291b028fdcaba4c534 -- 2.43.0

1 month, 2 weeks

RECOVER LOST INVESTMENT:THROUGH CHAINTRACE ASSET RECOVERY

by mikelowrey090＠gmail.com

I am thrilled to share my positive experience with CHAINTRACE ASSET RECOVERY, a reputable firm that specializes in recovering lost or scammed cryptocurrencies. Unfortunately, I fell victim to a sophisticated scam, which resulted in the loss of my bitcoin. I had sent the funds to a scammer's wallet address, thinking I was making a legitimate transaction. However, it soon became apparent that I had been deceived. Devastated and feeling helpless, I began to research possible solutions to recover my stolen bitcoin. That's when I came across CHAINTRACE ASSET RECOVERY. I was skeptical at first, but after reading numerous testimonials and reviews from satisfied clients, I decided to reach out to them for assistance. The team at CHAINTRACE ASSET RECOVERY was professional, responsive, and empathetic. They guided me through the recovery process, which was surprisingly efficient and straightforward. Their expertise and knowledge of blockchain technology and cryptocurrency transactions were impressive, and I was confident that I was in good hands. Thanks to CHAINTRACE ASSET RECOVERY, I was able to recover a significant portion of my lost bitcoin. I am extremely grateful for their help and would highly recommend their services to anyone who has fallen victim to cryptocurrency scams. If you have lost your crypto to scammers, I urge you to contact CHAINTRACE ASSET RECOVERY. Their dedication to helping individuals recover their stolen assets is truly commendable, and I am thankful to have found them. In conclusion, my experience with CHAINTRACE ASSET RECOVERY has been nothing short of exceptional. Their professionalism, expertise, and commitment to recovering lost cryptocurrencies have made a significant difference in my life. If you are a victim of cryptocurrency scams, do not lose hope. Reach out to CHAINTRACE ASSET RECOVERY, and let their team of experts help you recover your stolen assets. WHATSAPP : +1 (581) 256‑1989 EMAIL: chaintraceasset(a)post.com WEBSITE: ‪https://chaintraceassetrecovery.com

1 month, 2 weeks

Lost Recovery Services

by pierrebeatrice468＠gmail.com

If you've lost access to your Bitcoin or other cryptocurrencies, ALMIGHTY RECOVERY can help. Their team employs proven methods to recover lost funds, providing support through every step of the process. This service is crucial for those who may have forgotten passwords or lost recovery keys. Email,.. almightyrecoverycoin(@) mail . (com) WhatsApp,.. +53 5 (155) 6969 Website,.. almightyrecoveryco.wixsite.com/almighty-recovery-co

1 month, 2 weeks

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig