Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

99 participants
7051 discussions

THE BEST AND LEGITIMATE HACKER IN THE WORLD // GEO COORDINATES RECOVERY HACKER

by Fate Elena

THE BEST AND LEGITIMATE HACKER IN THE WORLD // GEO COORDINATES RECOVERY HACKER Do you want to hire a hacker to solve your problems in various conditions? If you require the services of a genuine hacker and do not have any idea about how to hire a professional hacker online, you are at the right place. There are many cryptocurrency theft cases and schemes currently in circulation in the whole world so it’s important to be careful before investing with any platform. I lost almost all my savings in a fake investment website but I got rescued through the recovery hacker called GEO COORDINATES RECOVERY HACKER as they recovered my stolen funds completely without hassle or hidden fees. This expert retrieved my stolen funds remotely within a few hours as I got notification on my blockchain wallet my funds had been restored. This is the best help I ever got on the internet and I decided to give them a good review about their good job and how quick they are in helping and standing for individuals in tough situations. Kindly contact them if you are in trouble. Email: geovcoordinateshacker(a)gmail.com Website; https://geovcoordinateshac.wixsite.com/geo-coordinates-hack WhatsApp: +1 ( 318 ) 203-3657 )

6 days, 9 hours

THE BEST AND LEGITIMATE HACKER IN THE WORLD // GEO COORDINATES RECOVERY HACKER

by Fate Elena

6 days, 9 hours

THE BEST AND LEGITIMATE HACKER IN THE WORLD // GEO COORDINATES RECOVERY HACKER

by Fate Elena

6 days, 9 hours

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

by Tian, Kevin

> From: Matt Evans <matt(a)ozlabs.org> > Sent: Tuesday, June 16, 2026 2:04 AM > > On 12/06/2026 09:42, Tian, Kevin wrote: > >> From: Matt Evans <matt(a)ozlabs.org> > >> Sent: Wednesday, June 10, 2026 11:43 PM > >> > >> +int vfio_pci_dma_buf_find_pfn(struct vfio_pci_dma_buf *priv, > >> + struct vm_area_struct *vma, > >> + unsigned long address, > >> + 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: > >> + * - The page would cross the edge of the VMA > >> + * - The page isn't entirely contained within a range > >> + * - We find a range, but the final PFN isn't aligned to the > >> + * requested order. > >> + * > >> + * (Upon failure, the caller is expected to try again with a > >> + * smaller order; the tests above will always succeed for > >> + * order=0 as the limit case.) > >> + * > >> + * It's suboptimal if DMABUFs are created with neigbouring > > > > s/neigbouring/neighboring/ > > Ah, not a typo. :) That is en_GB and AFAIK is permitted. I guess you meant 'neighbouring' and 'neighboring' are both valid. but here lacking a 'h' should be a typo? :) > >> + */ > >> + > >> + const unsigned long pagesize = PAGE_SIZE << order; > >> + unsigned long vma_off = ((vma->vm_pgoff - priv->vma_pgoff_adjust) > >> << > >> + PAGE_SHIFT) & VFIO_PCI_OFFSET_MASK; > >> + unsigned long rounded_page_addr = ALIGN_DOWN(address, > >> pagesize); > >> + unsigned long rounded_page_end = rounded_page_addr + pagesize; > >> + unsigned long page_buf_offset; > >> + unsigned long page_buf_offset_end; > > > > what about "fault_offset[_end]"? page_buf is a bit confusing. > > I went round several times with these names, thanks for the input. Just > tried it out and your suggestion is clearer. > > >> + unsigned long range_buf_offset = 0; > > > > could this be called 'range_start' then the 'range_start' in latter loop > > is renamed to 'phys_start'? > > > > Not strong... just feel such naming helps me understand the logic easier > > Anything that helps helps, thanks. I ended up renaming this to > range_start_offset (as offset is IMHO important). > > I'm a fan of diagrams but this is too large to include in a comment. > But for posterity on the list, and using the new names, an illustration > of a DMABUF with 3 ranges in phys_vec, where a mapping's > faulting page offset lies in range [1]: > > fault_addr--+ > v VMA > +-----------------+----------+-----------------+ > | | Faulting | | > | | (hg)page | | > | | | | > |---- vma_off ---->+-----------------+----------+-----------------+ > | . . > | . . > |--------- fault_offset ------------>. . DMABUF > +-------------------------+---------------------------+--------------+ > | phys_vec[0] | phys_vec[1] . | phys_vec[2] | > | .paddr | . . | | > | .len | . . | | > +-------------------------+---------------------------+--------------+ > 0 : . . : L > |-- range_start_offset -->: . . -->: range_len > : . . : > V . . : > +----------+----------+-----+ > |.paddr | PFN | | > | | | | > | | | | > +----------+----------+-----+ > P > > P = paddr + (fault_offset - range_start_offset) > L = sum(phys_vec[0...2].len) > yes, much clearer now.

6 days, 12 hours

Re: [PATCH v3 9/9] vfio/pci: Add mmap() attributes to DMABUF feature

by Tian, Kevin

> From: Matt Evans <matt(a)ozlabs.org> > Sent: Wednesday, June 10, 2026 11:43 PM > > A new VFIO feature, VFIO_DEVICE_FEATURE_DMA_BUF_MEMATTR, is added > to > set CPU-facing memory type attributes for a DMABUF exported from > vfio-pci. These are used for subsequent mmap()s of the buffer. > > There are two attributes supported: > - The default, VFIO_DEVICE_FEATURE_DMA_BUF_MEMATTR_NC > - VFIO_DEVICE_FEATURE_DMA_BUF_MEMATTR_WC, which results in WC > PTEs for the DMABUF's BAR region. > > Signed-off-by: Matt Evans <matt(a)ozlabs.org> Reviewed-by: Kevin Tian <kevin.tian(a)intel.com>

6 days, 12 hours

Re: [PATCH v3 8/9] vfio/pci: Permanently revoke a DMABUF on request

by Tian, Kevin

> From: Matt Evans <matt(a)ozlabs.org> > Sent: Wednesday, June 10, 2026 11:43 PM > > Expand the VFIO DMABUF revocation state to three states: > Not revoked, temporarily revoked, and permanently revoked. > > The first two are for existing transient revocation, e.g. across a > function reset, and the DMABUF is put into the last in response to a > new VFIO feature VFIO_DEVICE_FEATURE_DMA_BUF. VFIO_DEVICE_FEATURE_DMA_BUF_REVOKE > > VFIO_DEVICE_FEATURE_DMA_BUF passes a DMABUF by fd and requests that > the DMABUF is permanently revoked. On success, it's guaranteed that ditto > the buffer can never be imported/attached/mmap()ed in future, that > dynamic imports have been cleanly detached, and that all mappings have > been made inaccessible/PTEs zapped. > > This is useful for lifecycle management, to reclaim VFIO PCI BAR > ranges previously delegated to a subordinate client process: The > driver process can ensure that the loaned resources are revoked when > the client is deemed "done", and exported ranges can be safely re-used > elsewhere. probably clarify that re-use by creating a new dmabuf fd as the original one is essentially zombie now. > > +/* Set the DMABUF's revocation status (OK or temporarily/permanently > revoked) */ > +static void vfio_pci_dma_buf_set_status(struct vfio_pci_dma_buf *priv, > + enum vfio_pci_dma_buf_status > new_status) > +{ > + bool was_revoked; > + > + lockdep_assert_held_write(&priv->vdev->memory_lock); > + > + if (priv->status == VFIO_PCI_DMABUF_PERM_REVOKED || > + priv->status == new_status) { > + return; > + } the only interface to request PERM_REVOKED is via the new ioctl. vfio_pci_core_feature_dma_buf_revoke() returns -EBADFD if it's already in PERM_REVOKED. so this check shouldn't be reached, suggesting a warning. > + > + dma_buf_invalidate_mappings(priv->dmabuf); > + dma_resv_wait_timeout(priv->dmabuf->resv, > + DMA_RESV_USAGE_BOOKKEEP, false, > + MAX_SCHEDULE_TIMEOUT); > + dma_resv_unlock(priv->dmabuf->resv); It's existing code but while at it let's make above conditional to the actual revoke path. for unrevoked it's not required given the previous revoke already cleans up everything. otherwise, Reviewed-by: Kevin Tian <kevin.tian(a)intel.com>

6 days, 12 hours

Re: [PATCH v3 7/9] vfio/pci: Support mmap() of a VFIO DMABUF

by Tian, Kevin

> From: Matt Evans <matt(a)ozlabs.org> > Sent: Wednesday, June 10, 2026 11:43 PM > + > + /* > + * dma_buf_mmap_internal() has asserted that the VMA is > + * contained within the DMABUF size before calling this. > + */ > + > + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); > + vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot); remove the blank line. Reviewed-by: Kevin Tian <kevin.tian(a)intel.com>

6 days, 12 hours

Re: [PATCH v3 6/9] vfio/pci: Clean up BAR zap and revocation

by Tian, Kevin

> From: Matt Evans <matt(a)ozlabs.org> > Sent: Wednesday, June 10, 2026 11:43 PM > > Previously, vfio_pci_zap_bars() (and the wrapper > vfio_pci_zap_and_down_write_memory_lock()) calls were paired with > calls to vfio_pci_dma_buf_move(). > > This commit replaces them with a unified new function, > vfio_pci_zap_revoke_bars() containing both the vfio_pci_dma_buf_move() > and the unmap_mapping_range(), making it harder for callers to omit > one. It adds a wrapper, vfio_pci_lock_zap_revoke_bars(), which takes > the write memory_lock before zapping, and adds a new > vfio_pci_unrevoke_bars() for the re-enable path. It's unusual to have three verbs (lock/zap/revoke) in one function name. I wonder whether it's simpler to have: vfio_pci_zap_bars_locked() // caller already holds the lock vfio_pci_zap_bars() 'revoke' is just a side-effect of 'zap', not necessarily to highlight it in the name. > > As of "vfio/pci: Convert BAR mmap() to use a DMABUF", the > unmap_mapping_range() to zap is no longer performed for vfio-pci since > the DMABUFs used for BAR mappings already zap PTEs when the > vfio_pci_dma_buf_move() occurs. > > However, it must be assumed that VFIO drivers which override the .mmap > op could create mappings _not_ backed by DMABUFs. So, the zap is > still performed on revoke if .mmap is overridden, using a new > zap_bars_on_revoke flag. A driver can explicitly opt out; the flag is > cleared by the hisi_acc_vfio_pci driver, since its .mmap just wraps > vfio_pci_core_mmap() and so still uses DMABUFs. the cost of unmap_mapping_range() is trivial when there is no mmap on the device fd. so it could be simpler by always doing: vfio_pci_dma_buf_move(); unmap_mapping_range(); and remove the flag.

6 days, 12 hours

Re: [PATCH v3 9/9] vfio/pci: Add mmap() attributes to DMABUF feature

by Pranjal Shrivastava

On Wed, Jun 10, 2026 at 04:43:23PM +0100, Matt Evans wrote: > A new VFIO feature, VFIO_DEVICE_FEATURE_DMA_BUF_MEMATTR, is added to > set CPU-facing memory type attributes for a DMABUF exported from > vfio-pci. These are used for subsequent mmap()s of the buffer. > > There are two attributes supported: > - The default, VFIO_DEVICE_FEATURE_DMA_BUF_MEMATTR_NC > - VFIO_DEVICE_FEATURE_DMA_BUF_MEMATTR_WC, which results in WC > PTEs for the DMABUF's BAR region. > > Signed-off-by: Matt Evans <matt(a)ozlabs.org> > --- > drivers/vfio/pci/vfio_pci_core.c | 2 ++ > drivers/vfio/pci/vfio_pci_dmabuf.c | 57 +++++++++++++++++++++++++++++- > drivers/vfio/pci/vfio_pci_priv.h | 14 ++++++++ > include/uapi/linux/vfio.h | 27 ++++++++++++++ > 4 files changed, 99 insertions(+), 1 deletion(-) > > +int vfio_pci_core_feature_dma_buf_memattr( > + struct vfio_pci_core_device *vdev, u32 flags, > + struct vfio_device_feature_dma_buf_memattr __user *arg, > + size_t argsz) > +{ > + struct vfio_device_feature_dma_buf_memattr db_attr; > + struct vfio_pci_dma_buf *priv; > + struct dma_buf *dmabuf; > + int ret; > + > + if (!vdev->pci_ops || !vdev->pci_ops->get_dmabuf_phys) > + return -EOPNOTSUPP; > + > + ret = vfio_check_feature(flags, argsz, > + VFIO_DEVICE_FEATURE_SET, > + sizeof(db_attr)); > + if (ret != 1) > + return ret; > + > + if (copy_from_user(&db_attr, arg, sizeof(db_attr))) > + return -EFAULT; > + > + dmabuf = dma_buf_get(db_attr.dmabuf_fd); > + if (IS_ERR(dmabuf)) > + return PTR_ERR(dmabuf); > + > + /* Verify DMABUF: see comments in vfio_pci_dma_buf_revoke() */ > + priv = dmabuf->priv; > + if (dmabuf->ops != &vfio_pci_dmabuf_ops || > + READ_ONCE(priv->vdev) != vdev) { > + ret = -ENODEV; > + goto out_put_buf; > + } > + > + switch (db_attr.memattr) { > + case VFIO_DEVICE_FEATURE_DMA_BUF_MEMATTR_NC: > + case VFIO_DEVICE_FEATURE_DMA_BUF_MEMATTR_WC: > + WRITE_ONCE(priv->memattr, db_attr.memattr); > + ret = 0; > + break; > + > + default: > + ret = -ENOENT; Nit: Looks like the agreement [1] was on -EOPNOTSUPP / -EINVAL but we took -ENOENT here and in the doc string? Was that intentional? I tend to agree with Alex's suggestion here, we'd prefer one of those two (-EINVAL / -EOPNOTSUPP) since it clearly communicates to the user that "You sent a wrong arg" or "We don't support this" -ENOENT means no such file or directory [2] to the user. Users may not be kernel engineers who'd wanna peek into the code and they may simply look at the uAPI files which doesn't give them an answer as to what went wrong. > + } > + > out_put_buf: > dma_buf_put(dmabuf); > Apart from that, Reviewed-by: Pranjal Shrivastava <praan(a)google.com> Thanks, Praan [1] https://lore.kernel.org/all/20260602131417.41366391@shazbot.org/ [2] https://elixir.bootlin.com/linux/v7.1-rc6/source/include/uapi/asm-generic/e…

6 days, 13 hours

Re: [PATCH v3 8/9] vfio/pci: Permanently revoke a DMABUF on request

by Pranjal Shrivastava

On Wed, Jun 10, 2026 at 04:43:22PM +0100, Matt Evans wrote: > Expand the VFIO DMABUF revocation state to three states: > Not revoked, temporarily revoked, and permanently revoked. > > The first two are for existing transient revocation, e.g. across a > function reset, and the DMABUF is put into the last in response to a > new VFIO feature VFIO_DEVICE_FEATURE_DMA_BUF. > > VFIO_DEVICE_FEATURE_DMA_BUF passes a DMABUF by fd and requests that > the DMABUF is permanently revoked. On success, it's guaranteed that > the buffer can never be imported/attached/mmap()ed in future, that > dynamic imports have been cleanly detached, and that all mappings have > been made inaccessible/PTEs zapped. > > This is useful for lifecycle management, to reclaim VFIO PCI BAR > ranges previously delegated to a subordinate client process: The > driver process can ensure that the loaned resources are revoked when > the client is deemed "done", and exported ranges can be safely re-used > elsewhere. > > Refactor the revocation code out of vfio_pci_dma_buf_move() to a > function common to move and the new feature request path. > > Signed-off-by: Matt Evans <matt(a)ozlabs.org> > --- > drivers/vfio/pci/vfio_pci_core.c | 6 +- > drivers/vfio/pci/vfio_pci_dmabuf.c | 169 ++++++++++++++++++++++------- > drivers/vfio/pci/vfio_pci_priv.h | 19 +++- > include/uapi/linux/vfio.h | 20 ++++ > 4 files changed, 173 insertions(+), 41 deletions(-) > > diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c > index 508a5eca910a..064906b25467 100644 [...] > > +/* Set the DMABUF's revocation status (OK or temporarily/permanently revoked) */ > +static void vfio_pci_dma_buf_set_status(struct vfio_pci_dma_buf *priv, > + enum vfio_pci_dma_buf_status new_status) > +{ > + bool was_revoked; > + > + lockdep_assert_held_write(&priv->vdev->memory_lock); > + > + if (priv->status == VFIO_PCI_DMABUF_PERM_REVOKED || > + priv->status == new_status) { > + return; > + } > + > + dma_resv_lock(priv->dmabuf->resv, NULL); > + was_revoked = (priv->status == VFIO_PCI_DMABUF_TEMP_REVOKED); > + > + if (new_status != VFIO_PCI_DMABUF_OK) { > + priv->status = new_status; /* Temp or permanently revoked */ > + > + if (was_revoked) { > + /* > + * TEMP_REVOKED is being upgraded to > + * PERM_REVOKED. The buffer is already gone, > + * don't wait on it again. > + */ > + dma_resv_unlock(priv->dmabuf->resv); > + return; > + } > + } > + > + dma_buf_invalidate_mappings(priv->dmabuf); Nit: We seem to be calling this even if new_status == OK, while it works as importers (like IOMMUFD and RDMA core) are immune to a double invalidate / revoke. I'm wondering if we could move this within the if (new_status != VFIO_PCI_DMABUF_OK) block? Since this is only needed to be called when we TEMP/PERM _REVOKE? I'm just worried that this may overload the dma_buf_invalidate_mappings to be a state-change notification instead of a revoke / invalidate notification. > + dma_resv_wait_timeout(priv->dmabuf->resv, > + DMA_RESV_USAGE_BOOKKEEP, false, > + MAX_SCHEDULE_TIMEOUT); > + dma_resv_unlock(priv->dmabuf->resv); > + if (new_status != VFIO_PCI_DMABUF_OK) { > + kref_put(&priv->kref, vfio_pci_dma_buf_done); > + wait_for_completion(&priv->comp); > + unmap_mapping_range(priv->dmabuf->file->f_mapping, > + 0, priv->size, 1); > + /* > + * Re-arm the registered kref reference and the > + * completion so the post-revoke state matches the > + * post-creation state. An un-revoke followed by a > + * new mapping needs the kref to be non-zero before > + * kref_get(), and vfio_pci_dma_buf_cleanup() > + * delegates its drain back through this revoke > + * path on a possibly-already-revoked dma-buf. > + */ > + kref_init(&priv->kref); > + reinit_completion(&priv->comp); > + } else { > + dma_resv_lock(priv->dmabuf->resv, NULL); > + priv->status = VFIO_PCI_DMABUF_OK; > + dma_resv_unlock(priv->dmabuf->resv); > + } > +} > + Otherwise, Reviewed-by: Pranjal Shrivastava <praan(a)google.com> Thanks, Praan

6 days, 13 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig