Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

7268 discussions

Re: [PATCH net-next v6 3/3] selftests/net: devmem.py: add check_rx_large_niov

by Jakub Kicinski

On Fri, 31 Jul 2026 15:01:01 -0700 Bobby Eshleman wrote: > Meanwhile, do we want drivers/net/hw/config to workaround by carrying > something like SYNC_FILE or DMABUF_HEAPS, or wait and see about the > udmabuf kconfig change? Let's enable SYNC_FILE for now and pursue the UDMABUF change in parallel. It will land in another tree if at all, so we'll have to wait a while before it propagates to us.

1 hour, 28 minutes

Re: [PATCH v5 3/9] vfio/pci: Add a helper to look up PFNs for DMABUFs

by Matt Evans

Hi Praan, On 30/07/2026 23:55, Pranjal Shrivastava wrote: > On Wed, Jul 15, 2026 at 06:47:26PM +0100, Matt Evans wrote: >> Add vfio_pci_dma_buf_find_pfn(), which a VMA fault handler can use to >> find a PFN. >> >> This supports multi-range DMABUFs, which typically would be used to >> represent scattered spans but might even represent overlapping or >> aliasing spans of PFNs. >> >> Because this is intended to be used in vfio_pci_core.c, we also need >> to expose the struct vfio_pci_dma_buf in the vfio_pci_priv.h header. >> >> Signed-off-by: Matt Evans <matt(a)ozlabs.org> >> --- >> drivers/vfio/pci/vfio_pci_dmabuf.c | 153 ++++++++++++++++++++++++++--- >> drivers/vfio/pci/vfio_pci_priv.h | 20 ++++ >> 2 files changed, 160 insertions(+), 13 deletions(-) >> >> diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c b/drivers/vfio/pci/vfio_pci_dmabuf.c >> index c16f460c01d6..7c047400dfd1 100644 >> --- a/drivers/vfio/pci/vfio_pci_dmabuf.c >> +++ b/drivers/vfio/pci/vfio_pci_dmabuf.c >> @@ -9,19 +9,6 @@ >> >> MODULE_IMPORT_NS("DMA_BUF"); >> >> -struct vfio_pci_dma_buf { >> - struct dma_buf *dmabuf; >> - struct vfio_pci_core_device *vdev; >> - struct list_head dmabufs_elm; >> - size_t size; >> - struct phys_vec *phys_vec; >> - struct p2pdma_provider *provider; >> - u32 nr_ranges; >> - struct kref kref; >> - struct completion comp; >> - u8 revoked : 1; >> -}; >> - >> static int vfio_pci_dma_buf_attach(struct dma_buf *dmabuf, >> struct dma_buf_attachment *attachment) >> { >> @@ -106,6 +93,146 @@ static const struct dma_buf_ops vfio_pci_dmabuf_ops = { >> .release = vfio_pci_dma_buf_release, >> }; >> >> +int vfio_pci_dma_buf_find_pfn(struct vfio_pci_dma_buf *priv, >> + struct vm_area_struct *vma, >> + unsigned long fault_addr, >> + unsigned int order, >> + unsigned long *out_pfn) >> +{ >> + /* >> + * Given a VMA (start, end, pgoffs) and a fault address, >> + * search the corresponding DMABUF's phys_vec[] to find the >> + * range representing the address's offset into the VMA, and >> + * its PFN. >> + * >> + * The phys_vec[] ranges represent contiguous spans of VAs >> + * upwards from the buffer offset 0; the actual PFNs might be >> + * in any order, overlap/alias, etc. Calculate an offset of >> + * the desired page given VMA start/pgoff and address, then >> + * search upwards from 0 to find which span contains it. >> + * >> + * On success, a valid PFN for a page sized by 'order' is >> + * returned into out_pfn. >> + * >> + * Failure occurs if: >> + * - A hugepage would cross the edge of the VMA, >> + * - A hugepage isn't entirely contained within a range >> + * (including where it straddles the boundary between >> + * ranges), >> + * - We find a range, but the final PFN isn't aligned to the >> + * requested order. >> + * >> + * Upon failure, -EAGAIN is returned and the caller is >> + * expected to try again with a smaller order, which will >> + * eventually succeed (order=0 will always work). >> + * >> + * It's suboptimal if DMABUFs are created with neighbouring >> + * ranges that are physically contiguous, since hugepages >> + * can't straddle range boundaries. (The construction of the >> + * ranges should merge them in this case.) >> + * >> + * Finally, vma_pgoff_adjust is used with a DMABUF created for >> + * a VFIO BAR mmap: a BAR mapped with vm_pgoff > 0 creates a >> + * DMABUF such that byte 0 of the VMA corresponds to byte 0 of >> + * the DMABUF and byte 'vm_pgoff << PAGE_SHIFT' into the BAR. >> + * To avoid double-offsetting in this scenario, subtracting >> + * vma_pgoff_adjust from this (non-zero) vm_pgoff generates >> + * the effective offset. >> + */ >> + >> + const unsigned long pagesize = PAGE_SIZE << order; >> + unsigned long vma_off = ((vma->vm_pgoff - priv->vma_pgoff_adjust) << >> + PAGE_SHIFT) & VFIO_PCI_OFFSET_MASK; > > Maybe I'm getting ahead of myself here.. but it seems like this > restricts us to only mapping DMABUFs at offsets < 1TB due to the > VFIO_PCI_OFFSET_MASK (since we have HBMs on PCI devices now, hitting 1TB > may not be a very distant future). This is a really good question, thanks for raisiing it. It is not too forward-thinking at all. > While I understand this mask is needed to drop the BAR encoding in the > high bits. > > My worry is, if in the future a user were to export a massive > contiguous DMABUF (e.g., >1TB of aggregated HBM) and tried to mmap deep > into it (passing an offset >= 1TB), this bitwise AND would silently drop > the high bits, leading to silent data corruption. One of the big advantages of DMABUF export was that the range could be huge and unencumbered by the VFIO_PCI_OFFSET_SHIFT of the traditional mmap() interface. It's a way to mmap huge BARs without having to change the user-visible shift). So definitely this is a relevant concern. > I think we should explicitly reject such an mmap with -EINVAL like: > > +const unsigned long pagesize = PAGE_SIZE << order; > +unsigned long vma_off = (vma->vm_pgoff - priv->vma_pgoff_adjust) << PAGE_SHIFT; > > +/* > + * Prevent silent wrap-around if the user mmaps a DMABUF at an > + * offset greater than the VFIO index mask allows. > + */ > +if (unlikely(vma_off > VFIO_PCI_OFFSET_MASK)) > + return -EINVAL; > > +vma_off &= VFIO_PCI_OFFSET_MASK; Agreed, for now this absolutely should not silently wrap if the offset is > 1TB, and we live with the restriction that a DMABUF sized >1TB can't be mapped with such an offset. (We can still, say, map all of a 16TB DMABUF with offset=0, which is good.). I'll add a check, thanks for pointing this out. I suggest as something to revisit later, we flag for a DMABUF (maybe an evolution of vma_pgoff_adjust) to differentiate whether this masking needs to be applied (traditional mmap() path) or not (DMABUF mmap()), and then offsets can be arbitrarily large. Cheers, Matt >> + unsigned long rounded_page_addr = ALIGN_DOWN(fault_addr, pagesize); >> + unsigned long rounded_page_end = rounded_page_addr + pagesize; >> + unsigned long fault_offset; >> + unsigned long fault_offset_end; >> + unsigned long range_start_offset = 0; >> + unsigned int i; >> + int ret; >> + > > > Thanks, > Praan

7 hours, 1 minute

Re: [PATCH v5 3/4] drm/prime: use dma_buf_fd_install() to preserve export tracing

by T.J. Mercier

On Wed, Jul 29, 2026 at 11:27 PM Baineng Shou <shoubaineng(a)gmail.com> wrote: > > drm_gem_prime_handle_to_fd() open-codes fd reservation and install > using get_unused_fd_flags() + fd_install() directly. This bypasses > the DMA_BUF_TRACE() call that dma_buf_fd() emits, so observability > tools relying on the trace_dma_buf_fd tracepoint silently miss all > DRM PRIME exports. > > Replace the bare fd_install() with dma_buf_fd_install(), which wraps > fd_install() together with DMA_BUF_TRACE(), restoring full tracepoint > coverage. No functional change; the fd lifecycle (get_unused_fd_flags > → work → install) is already correct. > > Note: this patch depends on dma_buf_fd_install() introduced in > "dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds" > [1]. > > [1] https://lore.kernel.org/dri-devel/20260714114654.3885457-2-shoubaineng@gmai… > > Suggested-by: Christian König <christian.koenig(a)amd.com> > Signed-off-by: Baineng Shou <shoubaineng(a)gmail.com> Reviewed-by: T.J. Mercier <tjmercier(a)google.com> > --- > drivers/gpu/drm/drm_prime.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c > index 9b44c78cd77f..fe3436d1235d 100644 > --- a/drivers/gpu/drm/drm_prime.c > +++ b/drivers/gpu/drm/drm_prime.c > @@ -524,7 +524,7 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev, > return PTR_ERR(dmabuf); > } > > - fd_install(fd, dmabuf->file); > + dma_buf_fd_install(dmabuf, fd); > *prime_fd = fd; > return 0; > } > -- > 2.34.1 >

7 hours, 29 minutes

Re: [PATCH v5 4/4] selftests: dmabuf-heaps: add fd-leak-on-EFAULT regression test

by T.J. Mercier

On Wed, Jul 29, 2026 at 11:27 PM Baineng Shou <shoubaineng(a)gmail.com> wrote: > > Add a test case that verifies no file descriptor is leaked when > DMA_HEAP_IOCTL_ALLOC succeeds internally but copy_to_user() fails > to deliver the fd number back to userspace. > > The failure is triggered by placing the ioctl argument in a private > anonymous page and flipping it to PROT_READ (via mprotect) between > the kernel's copy_from_user() and copy_to_user() calls. With the > buggy kernel the ioctl returns -EFAULT but leaves an extra open fd > in the process's fd table; with the fixed kernel the fd count is > unchanged. > > This serves as a regression test for: > "dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds" > > Suggested-by: Sumit Semwal <sumit.semwal(a)linaro.org> > Signed-off-by: Baineng Shou <shoubaineng(a)gmail.com> > --- > .../selftests/dmabuf-heaps/dmabuf-heap.c | 115 +++++++++++++++++- > 1 file changed, 114 insertions(+), 1 deletion(-) > > diff --git a/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c > index fc9694fc4e89..bd58e5b06c8b 100644 > --- a/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c > +++ b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c > @@ -390,6 +390,118 @@ static void test_alloc_errors(char *heap_name) > close(heap_fd); > } > > +/* > + * test_alloc_no_fd_leak_on_efault - verify no fd is leaked when > + * copy_to_user() fails during DMA_HEAP_IOCTL_ALLOC. > + * > + * The bug: dma_buf_fd() called fd_install() before copy_to_user(). > + * If copy_to_user() then failed (e.g. via mprotect), the fd was > + * silently installed in the fd table but never returned to userspace. > + * > + * The fix: reserve the fd with get_unused_fd_flags() first, attempt > + * copy_to_user(), and only call fd_install() on success. > + * > + * We trigger the failure by placing the ioctl argument in a page, > + * flipping it to PROT_READ between copy_from_user and copy_to_user, > + * and counting open file descriptors before and after. > + */ > +static void test_alloc_no_fd_leak_on_efault(char *heap_name) > +{ > + int heap_fd = -1; > + int fd_before, fd_after; > + int ret; > + long page_size; > + struct dma_heap_allocation_data *req; > + > + ksft_print_msg("Testing no fd leak when copy_to_user() fails:\n"); > + > + heap_fd = dmabuf_heap_open(heap_name); > + > + page_size = sysconf(_SC_PAGESIZE); > + > + /* > + * Place the ioctl argument in its own private anonymous page so > + * we can flip its protection independently. > + */ > + req = mmap(NULL, page_size, PROT_READ | PROT_WRITE, > + MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); > + if (req == MAP_FAILED) { > + ksft_test_result_fail("mmap failed: %s\n", strerror(errno)); > + goto out; > + } > + > + memset(req, 0, sizeof(*req)); > + req->len = page_size; > + req->fd_flags = O_RDWR | O_CLOEXEC; > + > + /* Count open fds before the ioctl */ > + fd_before = 0; > + { > + DIR *d = opendir("/proc/self/fd"); > + struct dirent *de; > + > + if (!d) { > + ksft_test_result_fail("opendir /proc/self/fd: %s\n", > + strerror(errno)); > + munmap(req, page_size); > + goto out; > + } > + while ((de = readdir(d))) > + if (de->d_name[0] != '.') > + fd_before++; > + closedir(d); > + /* subtract the fd opened by opendir itself */ But no actual subtraction? > + } > + > + /* > + * Make the page read-only: copy_from_user() in the kernel will > + * still succeed (it already ran), Huh? copy_from_user hasn't run yet. That happens inside the ioctl(). > but copy_to_user() that writes > + * the fd number back will fault. > + */ > + mprotect(req, page_size, PROT_READ); > + > + ret = ioctl(heap_fd, DMA_HEAP_IOCTL_ALLOC, req); > + > + /* Re-allow writes so munmap can clean up */ > + mprotect(req, page_size, PROT_READ | PROT_WRITE); > + munmap(req, page_size); > + > + if (ret != -1 || errno != EFAULT) { This looks like you meant &&, but I think we should just fail if ret != -1. Either the mprotect is broken, or dma-heap didn't actually try to copy_to_user. > + /* > + * If the ioctl didn't fail with EFAULT, either the kernel > + * handled it differently or mprotect raced. mprotect is synchronous, how could it race with anything here? > Skip rather > + * than giving a false pass/fail. > + */ > + ksft_test_result_skip( > + "ioctl did not return EFAULT (ret=%d errno=%d), skipping\n", > + ret, errno); > + goto out; > + } > + > + /* Count open fds after the failed ioctl */ > + fd_after = 0; > + { > + DIR *d = opendir("/proc/self/fd"); > + struct dirent *de; > + > + if (!d) { > + ksft_test_result_fail("opendir /proc/self/fd: %s\n", > + strerror(errno)); > + goto out; > + } > + while ((de = readdir(d))) > + if (de->d_name[0] != '.') > + fd_after++; > + closedir(d); > + } > + > + ksft_test_result(fd_before == fd_after, > + "no fd leak on EFAULT: before=%d after=%d\n", This is for the failure case, so I don't think the "no" should be in the string. > + fd_before, fd_after); > +out: > + close(heap_fd); > +} > + > static int numer_of_heaps(void) > { > DIR *d = opendir(DEVPATH); > @@ -420,7 +532,7 @@ int main(void) > return KSFT_SKIP; > } > > - ksft_set_plan(11 * numer_of_heaps()); > + ksft_set_plan(12 * numer_of_heaps()); > > while ((dir = readdir(d))) { > if (!strncmp(dir->d_name, ".", 2)) > @@ -435,6 +547,7 @@ int main(void) > test_alloc_zeroed(dir->d_name, ONE_MEG); > test_alloc_compat(dir->d_name); > test_alloc_errors(dir->d_name); > + test_alloc_no_fd_leak_on_efault(dir->d_name); > } > closedir(d); > > -- > 2.34.1 >

7 hours, 34 minutes

Cybersecurity Is Built on Preparation, Not Luck

by surayamadelin＠gmail.com

The strongest cybersecurity strategy isn't measured by how a company responds after an attack—it's measured by how well it prepares before one ever happens. Every day, organizations and individuals face phishing campaigns, ransomware, credential theft, and other cyber threats. While no security program can eliminate every risk, preparation can significantly reduce the likelihood and impact of an incident. Many people believe cyberattacks only target large corporations. In reality, small businesses, freelancers, cryptocurrency investors, and private individuals are frequently targeted because attackers assume they may have fewer security controls in place. A single compromised password or overlooked software update can provide an opportunity for unauthorized access. At **MUYERN TRUST**, we help clients understand their digital risks through cybersecurity consulting, digital forensics, blockchain investigations, cloud security, and incident response services. Information about our professional services is available at (http://www.muyerntrust.com), and confidential inquiries can also be sent to (muyerntrusted((a))mail-me(.)c o m) One of the most valuable investments any organization can make is a security assessment. Understanding where weaknesses exist allows those issues to be addressed before they become security incidents. Regular reviews of authentication methods, backup procedures, employee awareness, and network security often reveal opportunities for improvement that might otherwise go unnoticed. Another overlooked aspect of cybersecurity is documentation. Knowing how systems are configured, where important information is stored, and who is responsible for responding during an incident helps reduce confusion when time matters most. A well-prepared response plan can often limit disruption and support a faster recovery. Technology continues to evolve rapidly, but the fundamentals remain the same. Strong passwords, multi-factor authentication, software updates, encrypted backups, and user awareness continue to provide meaningful protection against many common threats. These practices may appear simple, yet they remain among the most effective security measures available. Cybersecurity is not only about protecting computers—it is about protecting people, businesses, and the information they depend on every day. Building a culture of security awareness is an ongoing process that benefits everyone connected to an organization. At MUYERN TRUST, we are committed to providing professional cybersecurity services backed by careful analysis, ethical practices, and practical solutions. Whether assisting with a cybersecurity incident, conducting a blockchain investigation, or helping improve an organization's security posture, our focus remains the same: delivering reliable technical expertise with professionalism and integrity. **Whats App:** +1 2.0.2 7.0.3 2.2.3.9

10 hours, 58 minutes

Drift Hunters: Master the Art of Drifting

by grannygame.org＠gmail.com

https://drifthuntersonline.io Drift Hunters is an immersive drifting game that puts players behind the wheel of powerful sports cars on a variety of detailed tracks. Instead of simply racing to the finish, the challenge comes from maintaining long, controlled drifts, earning points, and mastering each corner with precise steering and throttle control. Every successful run rewards practice, making the driving feel both satisfying and skill-based. Beyond its realistic driving physics, Drift Hunters features a wide selection of customizable vehicles, performance upgrades, and visually appealing environments that keep each session fresh. Players can fine-tune their cars, experiment with different setups

17 hours, 2 minutes

IMAP Deactivation Error

by Email Support

20 hours, 2 minutes

Re: [PATCH net-next v6 3/3] selftests/net: devmem.py: add check_rx_large_niov

by Jakub Kicinski

On Thu, 30 Jul 2026 14:39:37 -0700 Bobby Eshleman wrote: > Poking around, it looks like 231.1.167.0 and above should support > everything, so fw should be okay AFAICT. > > Looks like the config is missing CONFIG_NET_DEVMEM and CONFIG_UDMABUF? Ah, damn, you're right. I grepped for DEVMEM and didn't look closely on a hit. Turns out there's a non-NET DEVMEM, too. Could you send a patch to add the missing config options to tools/testing/selftests/drivers/net/hw/config ? Can be separate or part of this series, doesn't matter. > Sorry, took me a while... was certain it was a bug in my code. > > Not the failure here, but wondering if this was on ARM led to seeing > that 16K hardcoded rx_page_size in run_rx_large_niov() may fail on ARM > with 64K pages because it will fail the IS_ALIGN(16K, 64K) check... Ah, good thought. We've been meaning to get an ARM64 server for NIPA (our current server supplier is out). If it's not too hard could be nice to guard against that. But also not a huge deal for HW tests if they fail instead of skipping.

1 day, 2 hours

[PATCH v5 0/9] vfio/pci: Add mmap() for DMABUFs

by Matt Evans

Hi all, The goal of this series is to enable userspace driver designs that use VFIO to export DMABUFs representing subsets of PCI device BARs, and "vend" those buffers from a primary process to other subordinate processes by fd. These processes then mmap() the buffers and their access to the device is isolated to the exported ranges. This is an improvement on sharing the VFIO device fd to subordinate processes, which would allow unfettered access. This is achieved by enabling mmap() of vfio-pci DMABUFs, passed by fd to subordinate processes. Second, a new revocation mechanism is added to allow the primary process to forcibly revoke access to previously-shared BAR spans, even if the subordinate processes haven't cleanly exited. (The related topic of safe delegation of iommufd control to the subordinate processes is not addressed here, and is follow-up work.) The background/rationale is covered in more detail in the RFC cover letters. Feedback from the RFCs requested that, instead of creating DMABUF-specific vm_ops and .fault paths, to go the whole way and migrate the existing VFIO PCI BAR mmap() to be backed by a DMABUF too, resulting in a common vm_ops and fault handler for mmap()s of both the VFIO device and explicitly-exported DMABUFs. This will help future iommufd emulation of VFIO Type1 peer-to-peer, making it easier to get a DMABUF for a VFIO BAR as a DMA target. mmap() conversion to use DMABUF underneath has been done for vfio-pci, but not sub-drivers: nvgrace-gpu's mmap() override path is unchanged; I kept this out of scope for now not least because I don't have a thorough test setup for this system. I would prefer to help the nvgrace-gpu maintainers enable BAR mmap() DMABUFs themselves. Notes on patches ================ PCI/P2PDMA: Split pool-related cleanup out of pci_p2pdma_release() PCI/P2PDMA: Add CONFIG_PCI_P2PDMA_CORE Later in the series, vfio-pci's mmap() is going to depend on pcim_p2pdma_provider() which depended on CONFIG_PCI_P2PDMA, which in turn depended on ZONE_DEVICE. That isn't available on 32-bit and some archs, because they lack MEMORY_HOTPLUG and friends. VFIO does _not_ require actual P2P to be present for basic mmap() functionality, only for the optional CONFIG_DMA_SHARED_BUFFER feature. These split out p2pdma_core.c under CONFIG_PCI_P2PDMA_CORE (which currently contains pcim_p2pdma_provider()), and an optional CONFIG_PCI_P2PDMA which depends on ZONE_DEVICE etc. providing P2P functionality in the existing p2pdma.c. The first splits out pool cleanup from the release path, and the second does the refactor/code move to the new file. vfio/pci: Add a helper to look up PFNs for DMABUFs vfio/pci: Add a helper to create a DMABUF for a BAR-map VMA The first adds a DMABUF VMA fault handler helper to determine arbitrary-sized PFNs from ranges in DMABUF. The second refactors DMABUF export for use by the existing export feature, and adds a helper that creates a DMABUF corresponding to a VFIO BAR mmap() request. vfio/pci: Convert BAR mmap() to use a DMABUF The vfio-pci core mmap() creates a DMABUF with the helper above, and the vm_ops fault handler uses the other helper to resolve the fault. Because this depends on DMABUF structs/code, CONFIG_VFIO_PCI_CORE needs to depend on CONFIG_DMA_SHARED_BUFFER. The CONFIG_VFIO_PCI_DMABUF still conditionally enables the export support code. NOTE: The user mmap()s a device fd, but the resulting VMA's vm_file becomes that of the DMABUF. The DMABUF takes ownership of the device file and put()s it on release, which maintains the existing behaviour of a VMA keeping the VFIO device open. BAR zapping then happens via the existing vfio_pci_dma_buf_move() path, which now needs to unmap PTEs in the DMABUF's address_space. vfio/pci: Provide a user-facing name for BAR mappings There was a request for decent debug naming in /proc/<pid>/maps etc. comparable to the existing VFIO names: since the VMAs are DMABUFs, they have a "dmabuf:" prefix and can't be 100% identical to before. This is a user-visible change, but this patch at least now gives us extra info on the BDF & BAR being mapped. vfio/pci: Clean up BAR zap and revocation In general (see NOTE!) the vfio_pci_zap_bars() is now obsolete, since it unmaps PTEs in the VFIO device address_space which is now unused. This consolidates all calls (e.g. around reset) with the neighbouring vfio_pci_dma_buf_move()s into new functions, to revoke/unrevoke (making the steps clearer). NOTE: Because drivers can use their own vm_ops and override .mmap, the core must conservatively assume an overridden .mmap might still add PTEs to the VFIO device address_space and therefore still does the zap. A new flag, zap_bars_on_revoke, enables the zap when .mmap is overridden. A driver that does not need the zap can clear this to opt-out, e.g. if the driver calls down to the common mmap (and so uses DMABUFs). hisi-acc-vfio-pci does just this, and thus sets the opt-out flag. vfio/pci: Support mmap() of a VFIO DMABUF Adds mmap() for a DMABUF fd exported from vfio-pci. It was a goal to keep the VFIO device fd lifetime behaviour unchanged with respect to the DMABUFs. An application can close all device fds, and this will revoke/clean up all DMABUFs; then, no mappings or other access can be performed. When enabling mmap() of the DMABUFs, this means access through the VMA is also revoked. This complicates the fault handler because whilst the DMABUF exists, it has no guarantee that the corresponding VFIO device is still alive. Adds synchronisation ensuring the vdev is available before vdev->memory_lock is touched; this holds the device registration so that even if the buffer has been cleaned up, vdev hasn't been freed and so the lock can be safely taken. vfio/pci: Permanently revoke a DMABUF on request This is mostly a rename of `revoked` to an enum, `status`, and adding a third state for a buffer: usable, revoked temporary, revoked permanent. A new VFIO feature is added, VFIO_DEVICE_FEATURE_DMA_BUF_REVOKE, which takes a DMABUF (exported from the same device) and permanently revokes it. Thus a userspace driver can guarantee any downstream consumers of a shared fd are prevented from accessing a BAR range, and that range can be reused. NOTE: This might block userspace, waiting on importers to detach. The code doing revocation in vfio_pci_dma_buf_move() is moved, to a common function for use by ..._move() and this new feature. NOTE: See changelog, by request v4 added a condition to the existing code to elide the unnecessary invalidation/sync on the un-revoke path.) NOTE: Previous versions contained an additional feature patch, "vfio/pci: Add mmap() attributes to DMABUF feature". This has been dropped in v5 because: - The mechanism simply set vma->vm_page_prot. This would be sufficient for arm64 and other architectures. - However, (locally-run claude-opus-4-8) Sashiko flagged that, on x86, additional memtype handling is required to set up the PAT. Without this, the memtype is returned back to UC- by pfnmap_setup_cachemode() upon PTE creation. Most other sources of userspace WC mappings create PTEs eagerly with e.g. io_remap_pfn_range() which memtype_reserve() WC for the range. Getting them with lazy-fault used by vfio-pci is more complicated (e.g. perhaps registering WC for BARs with PAT/MTRRs, and deciding how to deal with aliasing...). Since this feature is not critical for this series to be useful, I've decided for now to drop it in favour of a simpler series now and revisiting this separ*ately. Testing ======= (The [RFC ONLY] userspace test program, for QEMU edu-plus, can be found in the GitHub branch below. It at least illustrates how the export, map, revoke, and close semantics interoperate.) This code has been tested in mapping DMABUFs of single/multiple ranges from multiple BARs, aliasing mmap()s, aliasing ranges across DMABUFs, vm_pgoff > 0, revocation, shutdown/cleanup scenarios, and hugepage mappings. No regressions observed on the VFIO selftests, or on our internal vfio-pci applications. VFIO on i386 has been build-tested. Dear Reviewers, =============== I was grateful for the reviews and Reviewed-Bys on previous versions. Thanks; I've added some Reviewed-Bys/Acks. I have NOT included your tags where the patch has materially changed after your review (or where requested changes ended up more than super-trivial). I hope that's okay. End === This is based on v7.2-rc3. These commits are on GitHub for easier browsing, along with "[RFC ONLY] selftests: vfio: Add standalone vfio_dmabuf_mmap_test": https://github.com/metamev/linux/compare/v7.2-rc3...dev/mev/vfio-dmabuf-mma… Thanks for reading, Matt ================================================================================ Changelog: v5: - Rebased on 7.2-rc3 - Dropped the memattr/WC feature (see explanation above). - "vfio/pci: Convert BAR mmap() to use a DMABUF": Fixed a potentially-nasty bug (which (locally-run) Sashiko found!) whereby the unmap_mapping_range() performed in cleanup was passed a range up from offset zero for the DMABUF size. Initially this was how all DMABUFs were created and an appropriate zap, but a new version kept the VFIO region index encoded in the offset -- for BAR > 0 the unmap span would then mismatch. Instead, pass size 0 to mean an "all" range. Because the goal is to shoot down everything relating to one DMABUF and the address_space can only contain things relating to that DMABUF, this is equivalent and has the bonus of never failing to match mappings... Praan, Kevin, I kept your R-Bs on this fix. - The revoke patch converts vfio_pci_dma_buf_cleanup()'s priv->vdev = NULL to a WRITE_ONCE, corresponding to the revoke function's READ_ONCE (performed to test that the VFIO and DMABUF are related). - Clarified the VFIO_DEVICE_FEATURE_DMA_BUF_REVOKE UAPI comments, documenting previously-missing error cases and their reasons. v4: https://lore.kernel.org/all/20260701171245.90111-1-matt@ozlabs.org/ v3: https://lore.kernel.org/all/20260610154327.37758-1-matt@ozlabs.org/ v2: https://lore.kernel.org/all/20260527102319.100128-1-mattev@meta.com/ v1: https://lore.kernel.org/kvm/20260416131815.2729131-1-mattev@meta.com/ RFCv2: https://lore.kernel.org/kvm/20260312184613.3710705-1-mattev@meta.com/ RFCv1: https://lore.kernel.org/all/20260226202211.929005-1-mattev@meta.com/ Tech topic: https://lore.kernel.org/linux-iommu/20250918214425.2677057-1-amastro@fb.com/ Matt Evans (9): PCI/P2PDMA: Split pool-related cleanup out of pci_p2pdma_release() PCI/P2PDMA: Add CONFIG_PCI_P2PDMA_CORE vfio/pci: Add a helper to look up PFNs for DMABUFs vfio/pci: Add a helper to create a DMABUF for a BAR-map VMA vfio/pci: Convert BAR mmap() to use a DMABUF vfio/pci: Provide a user-facing name for BAR mappings vfio/pci: Clean up BAR zap and revocation vfio/pci: Support mmap() of a VFIO DMABUF vfio/pci: Permanently revoke a DMABUF on request MAINTAINERS | 2 +- drivers/pci/Kconfig | 5 + drivers/pci/Makefile | 1 + drivers/pci/p2pdma.c | 113 +--- drivers/pci/p2pdma.h | 29 + drivers/pci/p2pdma_core.c | 122 +++++ drivers/vfio/pci/Kconfig | 5 +- drivers/vfio/pci/Makefile | 3 +- .../vfio/pci/hisilicon/hisi_acc_vfio_pci.c | 8 + drivers/vfio/pci/vfio_pci_config.c | 30 +- drivers/vfio/pci/vfio_pci_core.c | 210 +++++-- drivers/vfio/pci/vfio_pci_dmabuf.c | 515 +++++++++++++++--- drivers/vfio/pci/vfio_pci_priv.h | 53 +- include/linux/pci-p2pdma.h | 24 +- include/linux/pci.h | 2 +- include/linux/vfio_pci_core.h | 1 + include/uapi/linux/vfio.h | 25 + 17 files changed, 875 insertions(+), 273 deletions(-) create mode 100644 drivers/pci/p2pdma.h create mode 100644 drivers/pci/p2pdma_core.c -- 2.50.1 (Apple Git-155)

1 day, 7 hours

+97158 994 3206} Abortion Pills in Dubai | Abu Dhabi | Sharjah

by celik burak

+97158 994 3206} Abortion Pills in Dubai | Abu Dhabi | Sharjah Whatsapp +97158 994 3206 We have Abortion Pills / Cytotec Tablets /mifegest kit Available in Dubai, Sharjah, Abudhabi, Ajman, Alain, Fujairah, Ras Al Khaimah, Umm Al Quwain, UAE, buy cytotec in Dubai +97158 994 3206 “”Abortion Pills near me DUBAI | ABU DHABI|UAE. Price of Misoprostol, Cytotec” +97158 994 3206 Dr.Leen “BUY ABORTION PILLS MIFEGEST KIT, MISOPROTONE, CYTOTEC PILLS IN DUBAI, ABU DHABI,UAE” Contact me now via whatsapp…… abortion Pills Cytotec also available Oman Qatar Doha Saudi Arabia Bahrain Above all, Cytotec Abortion Pills are Available In Dubai / UAE, you will be very happy to do abortion in dubai Buy abortion pills in Dubai Buy abortion pills in Oman Buy abortion pills in Abu Dhabi Buy abortion pills in Sharjah Fujairah Buy abortion pills in Ras Al Khaimah (RAK) Buy abortion pills in Ajman Buy abortion pills in Al Ain Buy abortion pills in Umm Al Quwain (UAQ) Buy abortion pills in Kuwait Abortion Pills Available In Dubai Abortion Pills Available In UAE Abortion Pills Available In Abu Dhabi Abortion Pills Available In Sharjah Abortion Pills Available In Fujairah Abortion Pills Available In Alain Abortion Pills Available In Qatar Cytotec Available In Dubai Cytotec in Dubai Cyotec Pills Dubai Abortion Cytotec Pills In Dubai whatsapp us at ?? +97158 994 3206 ?Buy abortion pills in Dubai, Buy abortion pills in Abudhabi, Buy abortion pills in Sharja, Buy abortion pills in Abu az Zuluf, Buy abortion pills in Ras Al Khaimah (RAK), Buy abortion pills in Ajman, Buy abortion pills in Al Ain, abortion pills in DOHA, abortion pills in Abu Thaylah, abortion pills in kuwait city, abortion pills in muscat, abortion pills in jeddah,abortion pills in qatar,abortion pills in hawally,abortion pills in salmiyah,abortion pills in al wakrah,abortion pills in riyadh,abortion pills in manama,abortion pills in isa town,abortion pills in hamad town, Buy abortion pills in Umm Al Quwain (UAQ), Buy abortion pills in Kuwait, Abortion Pills Available In Dubai, Abortion Pills Available In UAE, Abortion Pills Available In Abu Dhabi, Abortion Pills Available In Sharjah, Abortion Pills Available In Fujairah, Abortion Pills Available In Alain, Abortion Pills Available In Qatar, Cytotec Available In Dubai, Cytotec in Dubai, Cytotec Pills Dubai, Abortion Cytotec Pills In Dubai UAE we are providing cytotec 200mg abortion pill in Dubai, UAE. Medication abortion offers an alternative to Surgical Abortion for women in the early weeks of pregnancy. We only offer abortion pills from 1 week-6 Months. We then advise you to use surgery if its beyond 6 months. Our Abu Dhabi, Ajman, Al Ain, Dubai, Fujairah, Ras Al Khaimah (RAK), Sharjah, Umm Al Quwain (UAQ) United Arab Emirates Abortion Clinic provides the safest and most advanced techniques for providing non-surgical, medical and surgical abortion methods for early through late second trimester, including the Abortion By Pill Procedure (RU 486, Mifeprex, Mifepristone, early options French Abortion Pill), Tamoxifen, Methotrexate and Cytotec (Misoprostol). The Abu Dhabi, United Arab Emirates Abortion Clinic performs Same Day Abortion Procedure using medications that are taken on the first day of the office visit and will cause the abortion to occur generally within 4 to 6 hours (as early as 30 minutes) for patients who are 3 to 12 weeks pregnant. When Mifepristone and Misoprostol are used, 50% of patients complete in 4 to 6 hours; 75% to 80% in 12 hours; and 90% in 24 hours. We use a regimen that allows for completion without the need for surgery 99% of the time. All advanced second trimester and late term pregnancies at our Tampa clinic (17 to 24 weeks or greater) can be completed within 24 hours or less 99% of the time without the need surgery. The procedure is completed with minimal to no complications. Our Women's Health Center located in Abu Dhabi, United Arab Emirates, uses the latest medications for medical abortions (RU486, Mifeprex, Mifegyne, Mifepristone, early options French abortion pill), Methotrexate and Cytotec (Misoprostol). The safety standards of our Abu Dhabi, United Arab Emirates Abortion Doctors remain unparalleled. They consistently maintain the lowest complication rates throughout the nation. Our Physicians and staff are always available to answer questions and care for women in one of the most difficult times in their lives. The decision to have an abortion at the Abortion Clinic in Abu Dhabi, United Arab Emirates, involves moral, ethical, religious, family, financial, health and age considerations. Buy abortion pills in Dubai, Buy abortion pills in Oman, Buy abortion pills in Abu Dhabi, Buy abortion pills in Sharjah Fujairah, Buy abortion pills in Ras Al Khaimah (RAK), Buy abortion pills in Ajman, Buy abortion pills in Al Ain, Buy abortion pills in Umm Al Quwain (UAQ), Buy abortion pills in Kuwait, Abortion Pills Available In Dubai, Abortion Pills Available In UAE, Abortion Pills Available In Abu Dhabi, Abortion Pills Available In Sharjah, Abortion Pills Available In Fujairah, Abortion Pills Available In Alain, Abortion Pills Available In Qatar, Cytotec Available In Dubai Cytotec in Dubai, abortion pills in Dubai for sale. +97158 994 3206 Cytotec Pills Dubai, Abortion Cytotec Pills In Dubai UAE, PRICE OF MIFE-KIT IN UAE HOW TO GET ABORTION PILLS IN DUBAI Safe Abortion in the UAE MIFEPRISTONE IN UAE MIFEPRISTONE IN DUBAI LEVONORGESTRAL IN UAE RU 486 IN DUBAI RU 486 IN ABU DHABI RU 486 IN UAE ABORTION PILLS ONLINE DELIVERY IN DUBAI ABORTION PILLS ON AMAZON IN UAE SURGICAL ABORTION IN DUBAI SURGICAL ABORTION IN ABU DHABI Surgical Abortion in the UAE COST OF SURGICAL ABORTION IN DUBAI/UAE HOW MUCH IS SURGICAL ABORTION IN DUBAI D & C IN DUBAI COST OF D&C IN DUBAI/UAE/ABU DHABI PRICE OF D & C PROCEDURE IN UAE DILATION & CURETTAGE IN DUBAI/UAE COST OF D & C IN DUBAI PRIVATE HOSPITAL Whatsapp +97158 994 3206 Question Tags: +97158 994 3206 “Legit & Safe ABORTION PILLS, ABU DHABI Sharjah Alain RAK city Satwa Jumeirah Al barsha, CYTOTEC, MIFEGEST KIT IN DUBAI, Misoprostol, UAE” Contact me now via whatsapp…………. +97158 994 3206

1 day, 9 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig