Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

43 participants
6397 discussions

[PATCH v2] drm/virtio: move cursor resv lock acquisition to prepare_fb

by Deepanshu Kartikey

virtio_gpu_cursor_plane_update() allocates a virtio_gpu_object_array, locks its dma_resv, and queues a fenced transfer to the host. The lock acquisition can fail in two ways: - dma_resv_lock_interruptible() returns -EINTR when a signal is delivered while waiting for the reservation lock. - dma_resv_reserve_fences() returns -ENOMEM if it fails to allocate a fence slot; in this case lock_resv unlocks before returning. The return value was ignored, so the cursor path could proceed with the resv lock not held. The queue path then walks the object array and calls dma_resv_add_fence(), which requires the lock; with lockdep enabled this trips dma_resv_assert_held(): WARNING: drivers/dma-buf/dma-resv.c:296 at dma_resv_add_fence+0x71e/0x840 Call Trace: virtio_gpu_array_add_fence virtio_gpu_queue_ctrl_sgs virtio_gpu_queue_fenced_ctrl_buffer virtio_gpu_cursor_plane_update drm_atomic_helper_commit_planes drm_atomic_helper_commit_tail commit_tail drm_atomic_helper_commit drm_atomic_commit drm_atomic_helper_update_plane __setplane_atomic drm_mode_cursor_universal drm_mode_cursor_common drm_mode_cursor_ioctl drm_ioctl __x64_sys_ioctl Beyond the WARN, mutating the dma_resv fence list without the lock races with concurrent readers/writers and can corrupt the list. The DRM atomic helpers do not allow .atomic_update to fail: by the time it runs, the commit has been signed off to userspace and there is no clean rollback path. Move the fallible work -- objs allocation, dma_resv locking, and fence slot reservation -- into virtio_gpu_plane_prepare_fb, which is the designated callback for resource acquisition and may return errors that the framework handles by rolling back the commit. Stash the prepared object array on virtio_gpu_plane_state so the update step can consume it. Make virtio_gpu_plane_cleanup_fb release the objs if the commit was rolled back before update ran (i.e., objs not consumed). The queue path already unlocks the resv after attaching the fence (vq.c:411) and frees the array via put_free_delayed after host completion (vq.c:271), so the update step only needs to clear vgplane_st->objs to transfer ownership. Simplify virtio_gpu_cursor_plane_update to a no-fail queue submission that hands the prepared, locked objs to the queue path. The bug was reported by syzbot, triggered via fault injection (fail_nth) on the DRM_IOCTL_MODE_CURSOR path, which forces the -ENOMEM branch in dma_resv_reserve_fences(). Reported-by: syzbot+72bd3dd3a5d5f39a0271(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=72bd3dd3a5d5f39a0271 Fixes: 5cfd31c5b3a3 ("drm/virtio: fix virtio_gpu_cursor_plane_update().") Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/all/20260510053025.100224-1-kartikey406@gmail.com/T/ [v1] Signed-off-by: Deepanshu Kartikey <kartikey406(a)gmail.com> --- v2: Move resv lock acquisition from .atomic_update (which must not fail) to .prepare_fb (which may), per maintainer review of v1. The previous approach of silently skipping the cursor update on lock failure violated the atomic-commit contract with userspace. --- drivers/gpu/drm/virtio/virtgpu_drv.h | 1 + drivers/gpu/drm/virtio/virtgpu_plane.c | 38 ++++++++++++++++++++------ 2 files changed, 30 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h index f17660a71a3e..e51f959dce46 100644 --- a/drivers/gpu/drm/virtio/virtgpu_drv.h +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h @@ -198,6 +198,7 @@ struct virtio_gpu_framebuffer { struct virtio_gpu_plane_state { struct drm_plane_state base; struct virtio_gpu_fence *fence; + struct virtio_gpu_object_array *objs; }; #define to_virtio_gpu_plane_state(x) \ container_of(x, struct virtio_gpu_plane_state, base) diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c b/drivers/gpu/drm/virtio/virtgpu_plane.c index a126d1b25f46..b0511ace89e6 100644 --- a/drivers/gpu/drm/virtio/virtgpu_plane.c +++ b/drivers/gpu/drm/virtio/virtgpu_plane.c @@ -381,6 +381,23 @@ static int virtio_gpu_plane_prepare_fb(struct drm_plane *plane, goto err_fence; } + if (plane->type == DRM_PLANE_TYPE_CURSOR && bo->dumb) { + struct virtio_gpu_object_array *objs; + + objs = virtio_gpu_array_alloc(1); + if (!objs) { + ret = -ENOMEM; + goto err_fence; + } + virtio_gpu_array_add_obj(objs, vgfb->base.obj[0]); + ret = virtio_gpu_array_lock_resv(objs); + if (ret) { + virtio_gpu_array_put_free(objs); + goto err_fence; + } + vgplane_st->objs = objs; + } + return 0; err_fence: @@ -417,6 +434,12 @@ static void virtio_gpu_plane_cleanup_fb(struct drm_plane *plane, vgplane_st->fence = NULL; } + if (vgplane_st->objs) { + virtio_gpu_array_unlock_resv(vgplane_st->objs); + virtio_gpu_array_put_free(vgplane_st->objs); + vgplane_st->objs = NULL; + } + obj = state->fb->obj[0]; if (drm_gem_is_imported(obj)) virtio_gpu_cleanup_imported_obj(obj); @@ -452,21 +475,18 @@ static void virtio_gpu_cursor_plane_update(struct drm_plane *plane, } if (bo && bo->dumb && (plane->state->fb != old_state->fb)) { - /* new cursor -- update & wait */ - struct virtio_gpu_object_array *objs; - - objs = virtio_gpu_array_alloc(1); - if (!objs) - return; - virtio_gpu_array_add_obj(objs, vgfb->base.obj[0]); - virtio_gpu_array_lock_resv(objs); + /* objs and fence were prepared in virtio_gpu_plane_prepare_fb; + * the resv is already locked. The queue path takes ownership + * of objs and unlocks the resv after attaching the fence. + */ virtio_gpu_cmd_transfer_to_host_2d (vgdev, 0, plane->state->crtc_w, plane->state->crtc_h, - 0, 0, objs, vgplane_st->fence); + 0, 0, vgplane_st->objs, vgplane_st->fence); virtio_gpu_notify(vgdev); dma_fence_wait(&vgplane_st->fence->f, true); + vgplane_st->objs = NULL; } if (plane->state->fb != old_state->fb) { -- 2.43.0

2 hours, 24 minutes

[PATCH RFC 0/5] memcg: dma-buf per-cgroup accounting via pid_fd

by Albert Esteve

This RFC builds on T.J. Mercier's earlier series [1] which added a memory.stat counter for exported dma-bufs and a binder-backed mechanism to transfer charges between cgroups. The first commit is taken almost verbatim from TJ's series: it introduces MEMCG_DMABUF as a dedicated per-cgroup stat, so that the total exported dma-buf footprint is visible both system-wide (via the root cgroup) and per-application (via per-process cgroups). This avoids the overhead of DMABUF_SYSFS_STATS and integrates naturally into the existing cgroup memory hierarchy. The rest of the series departs from TJ's approach. While the first commit introduces the memcg stat infrastructure for dmabufs, the export-time charging it introduces in dma_buf_export() is then superseded: we charge at dma_heap_ioctl_allocate() time, using a new charge_pid_fd field in struct dma_heap_allocation_data. The allocator opens a pidfd for its client (e.g., from binder's sender_pid), passes it to the ioctl, and the kernel charges the buffer directly to the client's cgroup at allocation time, so no transfer step is needed. This decouples the accounting path from binder entirely: any allocator that knows its client's PID can use the pid_fd mechanism regardless of the IPC transport in use. The cross-cgroup charging capability requires access control. Patches #3 and #4 add a generic LSM hook (security_dma_heap_alloc) and an SELinux implementation based on a new dma_heap object class with a charge_to permission, so policy authors can express which domains are allowed to charge memory to another domain's cgroup. Last patch adds some tests to verify the new charge_pid_fd field. We are sending it as an RFC to spark broader discussion. It may or may not be the right path forward, and we welcome feedback on the trade-offs. Collision note: Eric Chanudet's series [2] adds __GFP_ACCOUNT to system_heap page allocations as an opt-in module parameter. That approach charges pages to the allocator's own kmem, which overlaps with MEMCG_DMABUF. This series explicitly removes __GFP_ACCOUNT from system heap allocations and routes all accounting through the MEMCG_DMABUF path to avoid double-counting. [1] https://lore.kernel.org/cgroups/20230109213809.418135-1-tjmercier@google.co… [2] https://lore.kernel.org/r/20260113-dmabuf-heap-system-memcg-v2-0-e85722cc2f… Signed-off-by: Albert Esteve <aesteve(a)redhat.com> --- Albert Esteve (4): dma-heap: charge dma-buf memory via explicit memcg security: dma-heap: Add dma_heap_alloc LSM hook selinux: Restrict cross-cgroup dma-heap charging selftests/dmabuf-heaps: Add dma-buf memcg accounting tests T.J. Mercier (1): memcg: Track exported dma-buffers Documentation/admin-guide/cgroup-v2.rst | 5 + drivers/dma-buf/dma-buf.c | 7 + drivers/dma-buf/dma-heap.c | 54 +++++- drivers/dma-buf/heaps/system_heap.c | 2 - include/linux/dma-buf.h | 4 + include/linux/lsm_hook_defs.h | 1 + include/linux/memcontrol.h | 37 ++++ include/linux/security.h | 7 + include/uapi/linux/dma-heap.h | 6 + mm/memcontrol.c | 19 ++ security/security.c | 16 ++ security/selinux/hooks.c | 7 + security/selinux/include/classmap.h | 1 + tools/testing/selftests/cgroup/Makefile | 2 +- tools/testing/selftests/cgroup/test_memcontrol.c | 143 +++++++++++++- tools/testing/selftests/dmabuf-heaps/config | 1 + tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c | 126 ++++++++++++- tools/testing/selftests/dmabuf-heaps/vmtest.sh | 205 +++++++++++++++++++++ 18 files changed, 633 insertions(+), 10 deletions(-) --- base-commit: 74fe02ce122a6103f207d29fafc8b3a53de6abaf change-id: 20260508-v2_20230123_tjmercier_google_com-f44fcfb16530 Best regards, -- Albert Esteve <aesteve(a)redhat.com>

16 hours, 40 minutes

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

by Matt Evans

Hi all, This series is based on previous RFCs/discussions: Tech topic: https://lore.kernel.org/linux-iommu/20250918214425.2677057-1-amastro@fb.com/ RFCv1: https://lore.kernel.org/all/20260226202211.929005-1-mattev@meta.com/ RFCv2: https://lore.kernel.org/kvm/20260312184613.3710705-1-mattev@meta.com/ The background/rationale is covered in more detail in the RFC cover letters. The TL;DR is: The goal 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. Second, a new ioctl()-based 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.) As well as isolation and revocation, another advantage to accessing a BAR through a VMA backed by a DMABUF is that it's straightforward to create the buffer with access attributes, such as write-combining. Notes on patches ================ 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 has been done for vfio-pci, but not sub-drivers (nvgrace-gpu's special-case mappings are unchanged). vfio/pci: Fix vfio_pci_dma_buf_cleanup() double-put A bug fix to a related are, whose context is a depdency for later patches. 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 is for a DMABUF VMA fault handler to determine arbitrary-sized PFNs from ranges in DMABUF. Secondly, refactor DMABUF export for use by the existing export feature and a new 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, 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 which takes ownership of the device and puts it on release. This 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-zap/unrevoke. NOTE: the nvgrace-gpu driver continues to use its own private vm_ops, fault handler, etc. for its special memregions, and these DO still add PTEs to the VFIO device address_space. So, a temporary flag, vdev->bar_needs_zap, maintains the old behaviour for this use. At least this patch's consolidation makes it easy to remove the remaining zap when this need goes away. A FIXME is added: if nvgrace-gpu is converted to DMABUFs, remove the flag and final zap. 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; no mappings or other access can be performed now. 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. (I decided against the alternative of preventing cleanup by holding the VFIO device open if any DMABUFs exist, because it's both a change of behaviour and less clean overall.) I've added a chonky comment in place, happy to clarify more if you have ideas. vfio/pci: Permanently revoke a DMABUF on request By weight, this is mostly a rename of revoked to an enum, status. There are now 3 states for a buffer, usable and revoked temporary/permanent. A new VFIO device ioctl is added, VFIO_DEVICE_PCI_DMABUF_REVOKE, which passes a DMABUF (exported from that 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. The code doing revocation in vfio_pci_dma_buf_move() is moved, unchanged, to a common function for use by _move() and the new ioctl path. Q: I can't think of a good reason to temporarily revoke/unrevoke buffers from userspace, so didn't add a 'flags' field to the ioctl struct. Easy to add if people think it's worthwhile for future use. vfio/pci: Add mmap() attributes to DMABUF feature Reserves bits [31:28] in vfio_device_feature_dma_buf to allow a (CPU) mapping attribute to be specified for an exported set of ranges. The default is the current UC, and a new flag can specify CPU access as WC. Q: I've taken 4 bits; the intention is for this field to be a scalar not a bitmap (i.e. mutually-exclusive access properties). Perhaps 4 is a bit too many? Testing ======= (The [RFC ONLY] userspace test program, for QEMU edu-plus, has been dropped, but can be found in the GitHub branch below.) 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...). No regressions observed on the VFIO selftests, or on our internal vfio-pci applications. End === This is based on -next (next-20260414 but will merge earlier), as it depends on Leon's series "vfio: Wait for dma-buf invalidation to complete": https://lore.kernel.org/linux-iommu/20260205-nocturnal-poetic-chamois-f566a… These commits are on GitHub, along with "[RFC ONLY] selftests: vfio: Add standalone vfio_dmabuf_mmap_test": https://github.com/metamev/linux/compare/next-20260414...metamev:linux:dev/… Thanks for reading, Matt ================================================================================ Change log: v1: - Cleanup of the common DMABUF-aware VMA vm_ops fault handler and export code. - Fixed a lot of races, particularly faults racing with DMABUF cleanup (if the VFIO device fds close, for example). - Added nicer human-readable names for VFIO mmap() VMAs RFCv2: Respin based on the feedback/suggestions: https://lore.kernel.org/kvm/20260312184613.3710705-1-mattev@meta.com/ - Transform the existing VFIO BAR mmap path to also use DMABUFs behind the scenes, and then simply share that code for explicitly-mapped DMABUFs. Jason wanted to go that direction to enable iommufd VFIO type 1 emulation to pick up a DMABUF for an IO mapping. - Revoke buffers using a VFIO device fd ioctl RFCv1: https://lore.kernel.org/all/20260226202211.929005-1-mattev@meta.com/ Matt Evans (9): vfio/pci: Fix vfio_pci_dma_buf_cleanup() double-put 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 vfio/pci: Add mmap() attributes to DMABUF feature drivers/vfio/pci/Kconfig | 3 +- drivers/vfio/pci/Makefile | 3 +- drivers/vfio/pci/nvgrace-gpu/main.c | 5 + drivers/vfio/pci/vfio_pci_config.c | 30 +- drivers/vfio/pci/vfio_pci_core.c | 224 ++++++++++--- drivers/vfio/pci/vfio_pci_dmabuf.c | 500 +++++++++++++++++++++++----- drivers/vfio/pci/vfio_pci_priv.h | 49 ++- include/linux/vfio_pci_core.h | 1 + include/uapi/linux/vfio.h | 42 ++- 9 files changed, 690 insertions(+), 167 deletions(-) -- 2.47.3

17 hours, 42 minutes

Re: [PATCH 4/8] drm/panthor: Add support for protected memory allocation in panthor

by Boris Brezillon

On Thu, 7 May 2026 11:02:26 +0200 Marcin Ślusarz <marcin.slusarz(a)arm.com> wrote: > On Tue, May 05, 2026 at 06:15:23PM +0200, Boris Brezillon wrote: > > > @@ -277,9 +286,21 @@ int panthor_device_init(struct panthor_device *ptdev) > > > return ret; > > > } > > > > > > + /* If a protected heap name is specified but not found, defer the probe until created */ > > > + if (protected_heap_name && strlen(protected_heap_name)) { > > > > Do we really need this strlen() > 0? Won't dma_heap_find() fail is the > > name is "" already? > > If dma_heap_find() will fail, then the whole probe with fail too. > This check prevents that. Yeah, that's also a questionable design choice. I mean, we can currently probe and boot the FW even though we never setup the protected FW sections, so why should we defer the probe here? Can't we just retry the next time a group with the protected bit is created and fail if we can find a protected heap? > I'm not sure why it's needed at all, but if > it is really needed, then s/strlen(protected_heap_name)/protected_heap_name[0]/ > would simplify this. It's not so much about how you do the test, and more about the case you're trying to protect against. I guess here you assume that panthor.protected_heap_name="" means "I don't have a protected heap for you". If it's deemed acceptable, this should most certainly be described somewhere. > > > > + ptdev->protm.heap = dma_heap_find(protected_heap_name); > > > + if (!ptdev->protm.heap) { > > > + drm_warn(&ptdev->base, > > > + "Protected heap \'%s\' not (yet) available - deferring probe", > > > + protected_heap_name); > > > + ret = -EPROBE_DEFER; > > > + goto err_rpm_put; > > > > If you move the heap retrieval before the rpm enablement, you can get > > rid of this goto err_rpm_put. > > > > > + } > > > + } > > > + > > > ret = panthor_hw_init(ptdev); > > > if (ret) > > > - goto err_rpm_put; > > > + goto err_dma_heap_put; > > > > > > ret = panthor_pwr_init(ptdev); > > > if (ret)

19 hours, 55 minutes

Obtain BCSP certifications without an exam in California

by Jamestoah113＠gmail.com

(certifitasap(a)gmail.com) Certified Safety Professional! #csp #safety #bcsp Certification is a designation awarded by the Board of Certified Safety Professionals (BCSP). We issue legit and verified BCSP certifications online with or without exams. The certificates are all available online. Buy Valid CSP Certification in the USA, Real BCSP Certifications in Mexico - USA BCSP Certifications. Learn how to become a Certified Safety Professional (CSP) with BCSP, a credential that demonstrates comprehensive knowledge and skills in safety practice. Find out the education, experience, examination, and maintenance requirements for CSP certification. Buy a Certified Safety Professional in the USA #csp #bcsp #ehs #safety #hse #workplacesafety #development #certification #growth Contact us via Teams ID-- (Jacob JB) Email....(certifitasap(a)gmail.com) WhatsApp...+1 (226) 894-5014 We are seeking a NEBOSH Diploma holder or equivalent for the role of HSE/Safety Officer on the Riyadh Metro Project. NEBOSH IGC, OSHA, and IOSH certifications with QR codes for easy verification of authenticity. No Exam: When you buy a genuine Certification, there will be no need to take the exams. Convenience: Many people have tight schedules and lack sufficient time to complete the exams or the testing process. https://safetycertificationsonline.blogspot.com/ We provide Official certifications with registration into the database and actual center stamps for customers interested in obtaining the certificate without taking the test. Certifitasap(a)gmail.com Apply for BCSP Certifications without exams 2026, Apply for CSHM Certification without exams, Apply for MSP Certification without exams in Australia, Apply for CSD Certification without exams in Bahrain, Apply for ASP Certification without exams in British, Apply for OHST Certification without exams in Canada, Apply for CHST Certification without exams in Dubai|, Apply for BCSP Certification without exams, Apply for CSP Certification without exams 2026, Apply for STS Certification without exams in Azerbaijan, Apply for CIH Certification without exams, Apply for CHMM without exam, Apply for NEBOSH Certification without exam in Bahrain #safety #bcsp #occupationalsafety #safetyexam #csp #industrialhygiene #safetypro #workersafety #jobsitesafety #osh #safetyprofessional #construction #safeworkplace #constructionsafety #safetymanager #ucm #ucmsafetyscience Certified Safety Professional (CSP) certification is a designation awarded by the Board of Certified Safety Professionals (BCSP) to individuals who demonstrate competency in safety management, occupational health, risk assessment, and regulatory compliance. https://generalhealthandsafety.blogspot.com/ The Certified Safety Professional (CSP) Certificate Course is one of the most sought-after certifications in the field of occupational health and safety. It demonstrates a high level of expertise in safety management. Certified Safety Professional (CSP) certification is a designation awarded by the Board of Certified Safety Professionals (BCSP). We issue legit and verified BCSP certifications online with or without exams. The certificates are all available online. Acquire BCSP certifications online without an Exam in Minnesota Obtain BCSP certifications without an exam in California Order a real, legit (STSC) certification online in Oklahoma Obtain (STS) certification online without an Exam in Nebraska Buy a real, legit CSP certification online in Montana Purchase (ASP) certification online without an Exam in Pennsylvania Apply for (SMS)certification online without an Exam in Massachusetts Apply for Certification without exam in Georgia, Apply for BCSP Certification without exam in Jeddah, Apply for NEBOSH Certification without exam in Jordan, Apply for Diplomas Certification without exam in Lebanon, Apply for IELTS Certification without exam in UK, Apply for BCSP Certification without exam in India, Apply for NEBOSH Diplomas without exam online, Apply for BCSP Certification without exam online in Libya Acquire BCSP Certification Without Exam | CSP Certificate USA without Exam Real BCSP Certifications in India - USA Valid CSD Certification Without Exam - USA Original OHST Certification in UAE - USA Registered CHST Certification Without Exam - Valid CSP Certification in USA - UK Genuine CIH Certification - USA STS Certification Online -USA CHMM Certification in the UK -USA Buy a Certified Safety Professional in the USA Update (CSP) certification online in Alabama, Alaska, Arizona, Arkansas, California, Colorado, Connecticut, Delaware, Florida, Georgia, Hawaii, Idaho, Illinois, Indiana, Iowa, Kansas, Kentucky, Louisiana, Maine, Maryland, Massachusetts, Michigan, Minnesota, Mississippi, Missouri, Montana, Nebraska, Nevada, New Hampshire, New Jersey, New Mexico, New York, North Carolina, North Dakota, Ohio, Oklahoma, Oregon, Pennsylvania, Rhode Island, South Carolina, South Dakota, Tennessee, Texas, Utah, Vermont, Virginia, Washington, West Virginia, Wisconsin, Wyoming. Contact us via Teams ID-- (Jacob JB) Email....certifitasap(a)gmail.com WhatsApp...+1 (226) 894-5014 BCSP operates the following certifications: Certified Safety Professional (CSP) Safety Management Specialist (SMS) Associate Safety Professional® (ASP) Occupational Hygiene and Safety Technologist (OHST) Construction Health and Safety Technician (CHST) Safety Trained Supervisor (STS) Safety Trained Supervisor Construction (STSC) Certified Instructional Trainer (CIT) Designations: Graduate Safety Practitioner (GSP) Transitional Safety Practitioner (TSP) NEBOSH Diplomas Certificates Online in Egypt Original NEBOSH Certificate Without Exam in United Arab Emirates, UAE, Dubai Original NEBOSH course Certificate Without Exam in Jordan neboshigc03(a)yahoo.com original NEBOSH Diplomas Without Exam in Saudi Arabia Original NEBOSH Certificate Without Exam in Jordan NEBOSH Diplomas Certificate Without Exam in Saudi Arabia https://neboshigc03.wixsite.com/website/services https://neboshigc03.wixsite.com/website/about https://neboshigc03.wixs....com/website/book-online https://neboshigc03.wixsite.com/website/contact https://neboshigc03.wixsite.com/website/products Neboshigc03(a)yahoo.com Purchase Original NEBOSH Diplomas Online Exam in Jordan, Apply for Original NEBOSH Certificates Online in United Arab Emirates Acquire Original NEBOSH Certificates Exam Online in Bahrain, Apply for Original NEBOSH Diplomas Exam Online in Algeria, Order Original NEBOSH Certificates Online Exam in Saudi Arabia Obtain Original NEBOSH Diplomas Exam Online in Middle East, Obtain Original NEBOSH IGC online Certificates Exam in Kuwait, Apply for Original NEBOSH Certificates Online Exam in Qatar, Obtain Original NEBOSH IGC Certificates Online Exam in Jordan, Order Original NEBOSH Diplomas Exam Online in Egypt Apply for Original NEBOSH Certificate Exam in UAE, Dubai Order Original NEBOSH Certificate Exam in Jordan, Apply for Original NEBOSH Diplomas Exam in Saudi Arabia Original NEBOSH Certificate Exam in Jordan NEBOSH Diplomas Certificate Exam in Saudi Arabia >>We are fast, reliable and flexible >>We are popular and trusted >>We are highly experienced in documentation >>We have excellent pass into database. https://generalhealthandsafety.blogspot.com/ https://certifiedsafetyprofessional.blogspot.com/ https://safetycertificationsonline.blogspot.com/ https://isc2certified.blogspot.com/ https://buycybersecurity...ifications.blogspot.com/ https://t.me/neboshigcdiploma https://t.me/odkhs https://t.me/+UfhkuxkiJsw5NWEx https://t.me/neboshigcdiploma https://t.me/+9YNbYISd1zo2ZmFh https://t.me/+IKqMHjQRhzllZmUx https://t.me/+LCKaaTSZ0Ws4Njlh https://t.me/+6wM4t3pxC1Q5NTMx https://t.me/modkx https://t.me/iscdk https://t.me/odkhs https://www.tiktok.com/@isc2cissp Contact us via Teams ID-- (Jacob JB) Apply for ASP Certification without exams, Apply for MSP Certification without exams in Saudi Arabia, Apply for CHST Certification without exams, Apply for OHST Certification without exams, Apply for CSD Certification without exams, Apply for Diplomas without exams in Bahrain, Apply for BCSP Certification without exams test in india, Apply for NEBOSH Diplomas without test in London, Apply for Diplomas without test in melbourne, Apply for NEBOSH Certification without test in Riyadh, Apply for CSHM Certification without test in sydney, Apply for CHMM Certification without test online, Apply for CIH Certification without test online in India, Apply for STS Certification without test online in London #ApplyforCSPCertificationwithoutexams #ApplyforCHSTCertificationwithoutexams #ApplyforOHSTCertificationwithoutexams #ApplyforASPCertificationwithoutexams #ApplyforCSDCertificationwithoutexams #ApplyforMSPCertificationwithoutexams #ApplyforNEBOSHCertificationwithouttest #ApplyforNEBOSHDiplomaswithouttest Contact us via Teams ID-- (Jacob JB) Email....certifitasap(a)gmail.com WhatsApp...+1 (226) 894-5014

20 hours, 32 minutes

Obtain BCSP certifications without an exam in California

by Jamestoah113＠gmail.com

20 hours, 32 minutes

Re: [PATCH v3 00/10] Add dmabuf read/write via io_uring

by Pavel Begunkov

On 5/7/26 10:50, Ming Lei wrote: ... >>> BTW, inspired by this approach, I adds similar feature to ublk via UBLK_IO_F_SHMEM_ZC >>> which can maintain long-term vfio dma mapping over registered user-place aligned buffer. >> >> Interesting, just too a glance, and it looks like what David Wei >> was thinking to add to fuse, but IIUC he gave up exactly because the >> client will need to cooperate and that could be troublesome. > > Here the cooperation is minimized, maybe one shmem/hugetlb path, or memfd, > and it is one optimization and opt-in, and fallback to normal path > if application doesn't cooperate. My point is that with widely enough adopted interface the user will be able to opportunistically use it without knowledge about the file, i.e. not knowing whether it's ublk or something else. But as you mentioned below, it'd be cooperative interface in either case. >> Should we try to push everything under the same interface instead of >> keeping a ublk specific one? Again to the point that it requires > > If generic interface can be figured out, it shouldn't be a big deal for > ublk to switch to it, and the usage is simple actually. Sure, you'd just need to maintain both as there is a mismatch between interfaces. > So far, ublk supports both FS and nvme block device. > > And cooperation can't be avoided for this usage no matter if generic or > driver specific implementation is taken, for both fuse & ublk. -- Pavel Begunkov

1 day, 2 hours

[PATCH v3 00/10] Add dmabuf read/write via io_uring

by Pavel Begunkov

The patch set allows to register a dmabuf to an io_uring instance for a specified file and use it with io_uring read / write requests. The infrastructure is not tied to io_uring and there could be more users in the future. A similar idea was attempted some years ago by Keith [1], from where I borrowed a good number of changes, and later was brough up by Tushar and Vishal from Intel. It's an opt-in feature for files, and they need to implement a new file operation to use it. Only NVMe block devices are supported in this series. The user API is built on top of io_uring's "registered buffers", where a dmabuf is registered in a special way, but after it can be used as any other "registered buffer" with IORING_OP_{READ,WRITE}_FIXED requests. It's created via a new file operation and the resulted map is then passed through the I/O stack in a new iterator type. There is some additional infrastructure to bind it all, which also counts requests using a dmabuf map and managing lifetimes, which is used to implement map invalidation. It was tested for GPU <-> NVMe transfers. Also, as it maintains a long-term dma mapping, it helps with the IOMMU cost. The numbers below are for udmabuf reads previously run by Anuj for different IOMMU modes: - STRICT: before = 570 KIOPS, after = 5.01 MIOPS - LAZY: before = 1.93 MIOPS, after = 5.01 MIOPS - PASSTHROUGH: before = 5.01 MIOPS, after = 5.01 MIOPS There are some liburing tests that can serve as an example: git: https://github.com/isilence/liburing.git rw-dmabuf-tests-v3 url: https://github.com/isilence/liburing/tree/rw-dmabuf-tests-v3 [1] https://lore.kernel.org/io-uring/20220805162444.3985535-1-kbusch@fb.com/ v3: - Rework io_uring registration - Move token/map infrastructure code out of blk-mq - Simplify callbacks: remove a separate blk-mq table, which was mostly just forwarding calls (to nvme). - Don't skip dma sync depending on request direction - Fix a couple of hangs - Rename s/dma/dmabuf/ - Other small changes v2: - Don't pass raw dma addresses, wrap it into a driver specific object - Split into two objects: token and map - Implement move_notify Pavel Begunkov (10): file: add callback for creating long-term dmabuf maps iov_iter: add iterator type for dmabuf maps block: move bvec init into __bio_clone block: introduce dma map backed bio type lib: add dmabuf token infrastructure block: forward create_dmabuf_token to drivers nvme-pci: implement dma_token backed requests io_uring/rsrc: introduce buf registration structure io_uring/rsrc: extend buffer update io_uring/rsrc: add dmabuf backed registered buffers block/bio.c | 28 +++- block/blk-merge.c | 14 ++ block/blk.h | 3 +- block/fops.c | 16 ++ drivers/nvme/host/pci.c | 282 ++++++++++++++++++++++++++++++++ include/linux/bio.h | 19 ++- include/linux/blk-mq.h | 9 + include/linux/blk_types.h | 8 +- include/linux/fs.h | 2 + include/linux/io_dmabuf_token.h | 92 +++++++++++ include/linux/io_uring_types.h | 5 + include/linux/uio.h | 11 ++ include/uapi/linux/io_uring.h | 31 +++- io_uring/io_uring.c | 3 +- io_uring/rsrc.c | 266 +++++++++++++++++++++++++----- io_uring/rsrc.h | 30 +++- io_uring/rw.c | 4 +- lib/Kconfig | 4 + lib/Makefile | 2 + lib/io_dmabuf_token.c | 272 ++++++++++++++++++++++++++++++ lib/iov_iter.c | 29 +++- 21 files changed, 1071 insertions(+), 59 deletions(-) create mode 100644 include/linux/io_dmabuf_token.h create mode 100644 lib/io_dmabuf_token.c -- 2.53.0

1 day, 2 hours

Mastering the Quirky Fun of Drive Mad

by cold.puma.etfk＠hidingmail.net

Ever stumbled upon a game that, despite its simple premise, completely hooks you with its pure, unadulterated fun? That’s exactly the experience many players find with Drive Mad. This charmingly addictive browser game offers a delightful blend of physics-based challenges and surprisingly deep vehicle customization, making it a perfect quick pick-up-and-play for a few minutes or an hour. If you’re looking to dive into some lighthearted, yet engaging, gaming, then look no further than learning how to play and truly experience Drive Mad. What is Drive Mad? The Basics of Bouncing and Building https://drivemadfree.com At its core, Drive Mad is a physics-based driving game where your primary goal is to navigate a vehicle through increasingly outlandish courses. The controls are delightfully straightforward: typically just accelerator, brake, and often a way to tilt your vehicle forward or backward. What makes it interesting, however, is the emphasis on building. Before each level, you’re presented with a basic chassis and a limited budget to add various components: wheels of different sizes and grips, engines with varying power, and even structural elements to help you survive a crash or two. The magic lies in experimenting with these parts to create the most effective (or hilariously ineffective) contraption to tackle the upcoming obstacles. You can find this gem at Drive Mad. From Novice to Mad Driver: Gameplay and Progression The journey in Drive Mad starts simply. Early levels introduce you to basic inclines, gaps, and flat surfaces, allowing you to get a feel for the physics and how different vehicle builds respond. As you progress, the challenges escalate dramatically. You’ll encounter massive ramps, precarious bridges, explosive barrels, and even sections that require careful balancing on a single wheel. Each successful completion of a level earns you more in-game currency, which you can then use to unlock new vehicle parts, expanding your creative possibilities. The satisfaction of finally overcoming a particularly tricky level with a custom-built monster truck or a zippy, lightweight dune buggy is truly rewarding. Tips for Taming the Tracks: Your Guide to Success While Drive Mad is easy to pick up, mastering it requires a bit of strategy. Here are a few friendly tips to help you on your way: • Experiment with Wheels: Don't underestimate the power of different wheel types. Larger wheels offer better clearance and absorb impacts, while smaller wheels can be nimble. Experiment with combinations! • Balance is Key: Especially in later levels, maintaining balance is crucial. Use your tilt controls wisely to prevent your vehicle from flipping over, especially on steep ascents or descents. • Budget Wisely: While it's tempting to splurge on the most powerful engine, sometimes a more balanced build with good wheels and a sturdy frame is more effective than a top-heavy speed demon. • Learn from Crashes: Every glorious explosion or comical flip is a learning opportunity. Pay attention to what caused the failure and adjust your vehicle or driving style accordingly. • Sometimes Less is More: Don’t feel obligated to use every component you can. A simpler, more focused design can sometimes be more robust and effective than an over-engineered behemoth. Conclusion: Embrace the Madness Drive Mad is more than just a simple browser game; it's a testament to the joy of creative problem-solving and the sheer fun of physics-based chaos. Whether you're a seasoned gamer looking for a refreshing break or someone new to the world of digital entertainment, its approachable nature and engaging gameplay make it a fantastic choice. So, next time you have a few minutes to spare, why not hop into the driver's seat, build your dream machine, and see just how far you can drive yourself mad?

1 day, 3 hours

Re: [RFC PATCH 04/12] vfio/pci: Allow MMIO regions to be exported through dma-buf

by Alexey Kardashevskiy

On 7/5/26 17:16, Alexey Kardashevskiy wrote: > On 6/5/26 23:16, Jason Gunthorpe wrote: >> On Wed, May 06, 2026 at 12:35:42PM +1000, Alexey Kardashevskiy wrote: >>> Hi! >>> >>> Let's reignite this topic. >>> >>> I've been using these patches + QEMU side hacks for 6+ months. And it's been fine until I got a device where MSIX BAR is in a middle of another BAR marked as TEE in the TDISP interface report. And no trusted MSIX yet. >>> >>> Every time QEMU mmaps a BAR - I request a dmabuf fd from VFIO in QEMU. Since mapping of an entire MSIX BAR is allowed by default, VFIORegion::nr_mmaps==1 and it is an entire BAR. >>> >>> Problem: KVM memslot mismatches the dmabuf fd size >> >> Huh? kvm does not care about dmabuf at all? Are you running other >> patches to hook kvm and dmabuf? > > yup, 06/12 of this patchset. > >> Putting a slice in a dmabuf is a well understood need for MSI, so I >> expect whatever kvm dmabuf interface that gets merged to accomodate >> this? > > good to know. > >>> Solution2: modify logic in VFIO dmabuf to allow multiple KVM memory >>> slots per dmabuf. Now it is kvm_memory_slot::dmabuf_attach with no >>> offset into the dmabuf and one kvm_vfio_dmabuf per dma_buf. >> >> Yes, when kvm learns to take in a dmabuf it needs to take in a slice, >> not the whole buf. Or you need to create multiple dmabufs with the >> necessary slices from the VFIO. The upstream vfio dmabuf creation >> allows creating it with a slice. > > true but either way dmabuf slicing will be directed by QEMU's msix-table emulation MR and this slicing needs to match the TDISP report so I'll have to teach QEMU these reports, right? Or TDISP devices are going to align MSIX BARs to 4K, and QEMU will do the same and it should "just work", and if it does not - the host won't crash. Can this work? Thanks, > I am worried if I miss something obvious, again. Thanks, > > > ps. I like nntp.lore.kernel.org very much for ability to dig out old stuff and then just reply to it :) > >> >> Jason > -- Alexey

1 day, 5 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig