Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

91 participants
6566 discussions

Start a nNew thread

Abortion pills in Dammam (+966572737505) Get Cytotec

by afrinsultana782445782445＠gmail.com

Abortion pills in Dammam (+966572737505) Get Cytotec

2 months, 4 weeks

Abortion pills in Dammam (+966572737505) Get Cytotec

by afrinsultana782445782445＠gmail.com

Abortion pills in Dammam (+966572737505) Get Cytotec

2 months, 4 weeks

Abortion pills in Dammam (+966572737505) Get Cytotec

by afrinsultana782445782445＠gmail.com

Abortion pills in Dammam (+966572737505) Get Cytotec

2 months, 4 weeks

Abortion pills in Dammam (+966572737505) Get Cytotec

by afrinsultana782445782445＠gmail.com

Abortion pills in Dammam (+966572737505) Get Cytotec

2 months, 4 weeks

Abortion pills in Jeddah (+966572737505) Get Cytotec

by afrinsultana782445782445＠gmail.com

Abortion pills in Jeddah (+966572737505) Get Cytotec

2 months, 4 weeks

About Abortion pills in Riyadh (+966572737505) Get Cytotec

by afrinsultana782445782445＠gmail.com

About Abortion pills in Riyadh (+966572737505) Get Cytotec

2 months, 4 weeks

About Abortion pills in Riyadh (+966572737505) Get Cytotec

by afrinsultana782445782445＠gmail.com

About Abortion pills in Riyadh (+966572737505) Get Cytotec

2 months, 4 weeks

About Abortion pills in Jeddah (+966572737505) Get Cytotec

by Afrinsultana782445782445＠gmail.com

About Abortion pills in Jeddah (+966572737505) Get Cytotec

2 months, 4 weeks

[RFC PATCH 0/7] vfio/pci: Add mmap() for DMABUFs

by Matt Evans

Hi all, There were various suggestions in the September 2025 thread "[TECH TOPIC] vfio, iommufd: Enabling user space drivers to vend more granular access to client processes" [0], and LPC discussions, around improving the situation for multi-process userspace driver designs. This RFC series implements some of these ideas. Background: Multi-process USDs ============================== The userspace driver scenario discussed in that thread involves a primary process driving a PCIe function through VFIO/iommufd, which manages the function-wide ownership/lifecycle. The function is designed to provide multiple distinct programming interfaces (for example, several independent MMIO register frames in one function), and the primary process delegates control of these interfaces to multiple independent client processes (which do the actual work). This scenario clearly relies on a HW design that provides appropriate isolation between the programming interfaces. The two key needs are: 1. Mechanisms to safely delegate a subset of the device MMIO resources to a client process without over-sharing wider access (or influence over whole-device activities, such as reset). 2. Mechanisms to allow a client process to do its own iommufd management w.r.t. its address space, in a way that's isolated from DMA relating to other clients. mmap() of VFIO DMABUFs ====================== First, this RFC addresses #1, implementing the proposals in [0] to add mmap() support to the existing VFIO DMABUF exporter. This enables a userspace driver to define DMABUF ranges corresponding to sub-ranges of a BAR, and grant a given client (via a shared fd) the capability to access (only) those sub-ranges. The VFIO device fds would be kept private to the primary process. All the client can do with that fd is map (or iomap via iommufd) that specific subset of resources, and the impact of bugs/malice is contained. (We'll follow up on #2 separately, as a related-but-distinct problem. PASIDs are one way to achieve per-client isolation of DMA; another could be sharing of a single IOVA space via 'constrained' iommufds.) Revocation/reclaim ================== That's useful as-is, but then the lifetime of access granted to a client needs to be managed well. For example, a protocol between the primary process and the client can indicate when the client is done, and when it's safe to reuse the resources elsewhere. Resources could be released cooperatively, but it's much more robust to enable the driver to make the resources guaranteed-inaccessible when it chooses, so that it can re-assign them to other uses in future. So, second, I've suggested a PoC/example mechanism for reclaiming ranges shared with clients: a new DMABUF ioctl, DMA_BUF_IOCTL_REVOKE, is routed to a DMABUF exporter callback. The VFIO DMABUF exporter's implementation permanently revokes a DMABUF (notifying importers, and zapping PTEs for any mappings). This makes the DMABUF defunct and any client (or third party the client has shared the buffer onto!) cannot be used to access the BAR ranges, whether via DMABUF import or mmap(). A primary driver process would do this operation when the client's tenure ends to reclaim "loaned-out" MMIO interfaces, at which point the interfaces could be safely re-used. This ioctl is one of several possible approaches to achieve buffer revocation, but I wanted to demonstrate something here as it's an important part of the buffer lifecycle in this driver scenario. An alternative implementation could be some VFIO-specific operation to search for a DMABUF (by address?) and kill it, but if the server keeps hold of the DMABUF fd that's already a clean way to locate it later. BAR mapping access attributes ============================= Third, inspired by Alex [Mastro] and Jason's comments in [0], and Mahmoud's work in [1] with the goal of controlling CPU access attributes for VFIO BAR mappings (e.g. WC) I noticed that once we can mmap() VFIO DMABUFs representing BAR sub-spans, it's straightforward to decorate them with access attributes for the VMA. I've proposed reserving a field in struct vfio_device_feature_dma_buf's flags to specify an attribute for its ranges. Although that keeps the (UAPI) struct unchanged, it means all ranges in a DMABUF share the same attribute. I feel a single attribute-to-mmap() relation is logical/reasonable. An application can also create multiple DMABUFs to describe any BAR layout and mix of attributes. Tests ===== I've included an [RFC ONLY] userspace test program which I am _not_ proposing to merge, but am sharing for context. It illustrates & tests various map/revoke cases, but doesn't use the existing VFIO selftests and relies on a (tweaked) QEMU EDU function. I'm working on integrating the scenarios into the existing VFIO selftests. This code has been tested in mapping DMABUFs of single/multiple ranges, aliasing mmap()s, aliasing ranges across DMABUFs, vm_pgoff > 0, revocation, shutdown/cleanup scenarios, and hugepage mappings seem to work correctly. I've lightly tested WC mappings also (by observing resulting PTEs as having the correct attributes...). (The first two commits are a couple of tiny bugfixes which I can send separately, should reviewers prefer.) This series is based on v6.19 but I expect to rebase, at least onto Leon's recent work [2] ("vfio: Wait for dma-buf invalidation to complete"). What are people's thoughts? I'll respin to de-RFC and capture comments, if we think this approach is appropriate. Thanks, Matt References: [0]: https://lore.kernel.org/linux-iommu/20250918214425.2677057-1-amastro@fb.com/ [1]: https://lore.kernel.org/all/20250804104012.87915-1-mngyadam@amazon.de/ [2]: https://lore.kernel.org/linux-iommu/20260205-nocturnal-poetic-chamois-f566a… Matt Evans (7): vfio/pci: Ensure VFIO barmap is set up before creating a DMABUF vfio/pci: Clean up DMABUFs before disabling function vfio/pci: Support mmap() of a DMABUF dma-buf: uapi: Mechanism to revoke DMABUFs via ioctl() vfio/pci: Permanently revoke a DMABUF on request vfio/pci: Add mmap() attributes to DMABUF feature [RFC ONLY] selftests: vfio: Add standalone vfio_dmabuf_mmap_test drivers/dma-buf/dma-buf.c | 5 + drivers/vfio/pci/vfio_pci_core.c | 4 +- drivers/vfio/pci/vfio_pci_dmabuf.c | 300 ++++++- include/linux/dma-buf.h | 22 + include/uapi/linux/dma-buf.h | 1 + include/uapi/linux/vfio.h | 12 +- tools/testing/selftests/vfio/Makefile | 1 + .../vfio/standalone/vfio_dmabuf_mmap_test.c | 822 ++++++++++++++++++ 8 files changed, 1153 insertions(+), 14 deletions(-) create mode 100644 tools/testing/selftests/vfio/standalone/vfio_dmabuf_mmap_test.c -- 2.47.3

2 months, 4 weeks

[PATCH 00/61] vfs: change inode->i_ino from unsigned long to u64

by Jeff Layton

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> --- Jeff Layton (61): vfs: widen inode hash/lookup functions to u64 vfs: change i_ino from unsigned long to u64 trace: update VFS-layer trace events for u64 i_ino ext4: update for u64 i_ino jbd2: update format strings for u64 i_ino f2fs: update for u64 i_ino lockd: update format strings for u64 i_ino nfs: update for u64 i_ino nfs: remove nfs_fattr_to_ino_t() and nfs_fileid_to_ino_t() nfs: remove nfs_compat_user_ino64() nfs: remove enable_ino64 module parameter nfsd: update format strings for u64 i_ino smb: store full 64-bit uniqueid in i_ino smb: remove cifs_uniqueid_to_ino_t() locks: update /proc/locks format for u64 i_ino proc: update /proc/PID/maps for u64 i_ino nilfs2: update for u64 i_ino 9p: update format strings for u64 i_ino affs: update format strings for u64 i_ino afs: update format strings for u64 i_ino autofs: update format strings for u64 i_ino befs: update format strings for u64 i_ino bfs: update format strings for u64 i_ino cachefiles: update format strings for u64 i_ino ceph: update format strings for u64 i_ino coda: update format strings for u64 i_ino cramfs: update format strings for u64 i_ino ecryptfs: update format strings for u64 i_ino efs: update format strings for u64 i_ino exportfs: update format strings for u64 i_ino ext2: update format strings for u64 i_ino freevxfs: update format strings for u64 i_ino hfs: update format strings for u64 i_ino hfsplus: update format strings for u64 i_ino hpfs: update format strings for u64 i_ino isofs: update format strings for u64 i_ino jffs2: update format strings for u64 i_ino jfs: update format strings for u64 i_ino minix: update format strings for u64 i_ino nsfs: update format strings for u64 i_ino ntfs3: update format strings for u64 i_ino ocfs2: update format strings for u64 i_ino orangefs: update format strings for u64 i_ino overlayfs: update format strings for u64 i_ino qnx4: update format strings for u64 i_ino qnx6: update format strings for u64 i_ino ubifs: update format strings for u64 i_ino udf: update format strings for u64 i_ino ufs: update format strings for u64 i_ino zonefs: update format strings for u64 i_ino security: update audit format strings for u64 i_ino drm/amdgpu: update for u64 i_ino fsnotify: update fdinfo format strings for u64 i_ino net: update socket dname format for u64 i_ino uprobes: update format strings for u64 i_ino dma-buf: update format string for u64 i_ino fscrypt: update format strings for u64 i_ino fsverity: update format string for u64 i_ino iomap: update format string for u64 i_ino net: update legacy protocol format strings for u64 i_ino vfs: update core format strings for u64 i_ino 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/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/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 | 46 ++-- fs/iomap/ioend.c | 2 +- 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 | 22 +- fs/nfs/file.c | 8 +- fs/nfs/filelayout/filelayout.c | 8 +- fs/nfs/flexfilelayout/flexfilelayout.c | 8 +- fs/nfs/inode.c | 54 +--- 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/smb/client/cifsfs.h | 17 -- fs/smb/client/inode.c | 6 +- fs/smb/client/readdir.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 +- include/linux/fs.h | 28 +- include/linux/nfs_fs.h | 10 - include/trace/events/cachefiles.h | 18 +- include/trace/events/ext4.h | 427 +++++++++++++++-------------- include/trace/events/f2fs.h | 172 ++++++------ include/trace/events/filelock.h | 16 +- include/trace/events/filemap.h | 20 +- include/trace/events/fs_dax.h | 20 +- include/trace/events/fsverity.h | 30 +- include/trace/events/hugetlbfs.h | 28 +- include/trace/events/netfs.h | 4 +- include/trace/events/nilfs2.h | 12 +- include/trace/events/readahead.h | 12 +- include/trace/events/timestamp.h | 12 +- include/trace/events/writeback.h | 148 +++++----- kernel/events/uprobes.c | 4 +- net/netrom/af_netrom.c | 4 +- net/rose/af_rose.c | 4 +- net/socket.c | 2 +- net/x25/x25_proc.c | 4 +- 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 | 4 +- security/smack/smack_lsm.c | 12 +- 195 files changed, 1101 insertions(+), 1166 deletions(-) --- base-commit: 2bf35e96cf6c6c3a290b69b777d34be15888e364 change-id: 20260224-iino-u64-b44a3a72543c Best regards, -- Jeff Layton <jlayton(a)kernel.org>

2 months, 4 weeks

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig