Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

28 participants
8000 discussions

[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)

3 minutes

Re: [PATCH v6 4/6] rust: xarray: Add support for index reservations

by Philipp Stanner

On Wed, 2026-08-05 at 10:50 +0200, Andreas Hindborg wrote: > "Philipp Stanner" <phasta(a)kernel.org> writes: > > > One often cannot allocate in the kernel with the desired flags, most > > notably in atomic context. Pre-allocating the memory is the preferred > > solution in such situations. > > > > Add support for xa_reserve() in the Rust abstractions of xarray. Create > > a Reservation object similar to a lock-guard, that can be dropped once > > the reservation is no longer needed or once the index was stored to. > > > > Signed-off-by: Philipp Stanner <phasta(a)kernel.org> > > --- > > Please regard this more as an RFC. > > > > I need pre-allocating in XArray for DmaFence. How exactly we achieve > > this is open for discussion. > > Do you need to actually reserve a key, or do you just need atomic > allocation? I would just have needed a position to store to, but the fence sequence number would be the only reasonable index, so you'd also reserve a key. Anyways, please forget about this for now, we abstained from using the XArray in the current revision (v8) of this patch series. Thx P.

5 hours, 9 minutes

Re: [PATCH v4 01/14] dma-buf: introduce initial file I/O infrastructure

by Christian König

On 7/28/26 23:29, Pavel Begunkov wrote: > The goal is to be able to natively use dma-buf in the read-write / IO > path. This patch adds basic building blocks serving as a glue and API > between drivers and upper layer subsystems providing the uAPI. Later > patches implement it for NVMe raw block devices and expose it to the > user space via io_uring. > > There are two main objects. struct dma_buf_io_ctx and struct > dma_buf_io_map. The ctx is used during initial registration and serves > as an interface between the upper layer user like io_uring and to the > importer subsystem / driver. The map represents the actual dma map > established for the target device[s] with dma_buf_map_attachment() and > stored in a device specific format. The context is created via a new > file operation ->init_dma_buf_io_ctx. > > The ctx-map separation exists to support map invalidation (see > dma_buf_io_invalidate_mappings()). A ctx can create > multiple maps during its lifetime, but there can only be no more than > one (active) map attached to it. Invalidation drops the active map > if present, and the next map will only be attempted to be created > once there is a new request that wants to use the dma-buf IO ctx. > > The primary task of the dma_buf_io_map object is to count requests > using it and to wait for their completion when we want to destroy the > DMA map. Invalidation is delayed by inserting a dma fence, which is > signaled when all flight requests are completed. > > [un]mapping and any work with dma addresses is delegated to the > importer driver via an ops table stored in the ctx, see struct > dma_buf_io_ops. Only the target driver / subsystem knows about devices > it wants to use the dma-buf with, especially in case of multi-device > filesystems or stacking in the future. > > Signed-off-by: Pavel Begunkov <asml.silence(a)gmail.com> > --- > drivers/dma-buf/Makefile | 2 +- > drivers/dma-buf/dma-buf-io.c | 275 +++++++++++++++++++++++++++++++++++ > include/linux/dma-buf-io.h | 91 ++++++++++++ > include/linux/fs.h | 2 + > 4 files changed, 369 insertions(+), 1 deletion(-) > create mode 100644 drivers/dma-buf/dma-buf-io.c > create mode 100644 include/linux/dma-buf-io.h > > diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile > index b25d7550bacf..523731b0f83e 100644 > --- a/drivers/dma-buf/Makefile > +++ b/drivers/dma-buf/Makefile > @@ -1,6 +1,6 @@ > # SPDX-License-Identifier: GPL-2.0-only > obj-y := dma-buf.o dma-fence.o dma-fence-array.o dma-fence-chain.o \ > - dma-fence-unwrap.o dma-resv.o dma-buf-mapping.o > + dma-fence-unwrap.o dma-resv.o dma-buf-mapping.o dma-buf-io.o > obj-$(CONFIG_DMABUF_HEAPS) += dma-heap.o > obj-$(CONFIG_DMABUF_HEAPS) += heaps/ > obj-$(CONFIG_SYNC_FILE) += sync_file.o > diff --git a/drivers/dma-buf/dma-buf-io.c b/drivers/dma-buf/dma-buf-io.c > new file mode 100644 > index 000000000000..5f545a1bcf32 > --- /dev/null > +++ b/drivers/dma-buf/dma-buf-io.c > @@ -0,0 +1,275 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * Common infrastructure for supporing dma-buf in the I/O path. > + * > + * Copyright (C) 2026 Pavel Begunkov <asml.silence(a)gmail.com> > + */ > +#include <linux/dma-buf-io.h> > +#include <linux/dma-resv.h> > + > +struct dma_buf_io_fence { > + struct dma_fence base; > + spinlock_t lock; > +}; Upstream has change to allow embedding the spinlock into the dma_fence, so this structure here is most likely not necessary any more. > + > +static const char *dma_buf_io_fence_drv_name(struct dma_fence *fence) > +{ > + /* default fence release kfree's the base pointer */ > + BUILD_BUG_ON(offsetof(struct dma_buf_io_fence, base)); > + > + return "dma-buf-io-ctx"; > +} > + > +static const char *dma_buf_io_fence_timeline_name(struct dma_fence *fence) > +{ > + return "dma-buf-io-ctx"; > +} > + > +const struct dma_fence_ops dma_buf_io_fence_ops = { > + .get_driver_name = dma_buf_io_fence_drv_name, > + .get_timeline_name = dma_buf_io_fence_timeline_name, > +}; > + > +static void dma_buf_io_ctx_destroy_work(struct work_struct *work) > +{ > + struct dma_buf_io_ctx *ctx = container_of(work, struct dma_buf_io_ctx, > + release_work); > + > + if (WARN_ON_ONCE(refcount_read(&ctx->refs))) > + return; > + > + ctx->dev_ops->release(ctx); > + dma_buf_put(ctx->dmabuf); > + kfree(ctx); > +} > + > +static void dma_buf_io_map_release_work(struct work_struct *work) > +{ > + struct dma_buf_io_map *map = container_of(work, struct dma_buf_io_map, > + release_work); > + struct dma_buf_io_fence *fence = map->fence; > + struct dma_buf_io_ctx *ctx = map->ctx; > + struct dma_buf *dmabuf = ctx->dmabuf; > + > + /* the release path must wait for fences */ > + if (WARN_ON_ONCE(refcount_read(&ctx->refs) == 0)) > + return; Stuff like that is usually illegal. And why are you using refcount directly instead of kref? > + > + /* Prevent from destoying the ctx while unmapping */ > + refcount_inc(&ctx->refs); > + > + /* > + * There are no more requests using the map, we can signal the fence. > + * It should be done before taking the resv lock as someone could be > + * waiting for the fence while holding the lock. > + */ > + dma_fence_signal(&fence->base); Signaling fences has a whole bunch of very strict rules associated with it. E.g. you can't alocate memory for example. Are you sure you actually need and want a dma_fence here? > + > + dma_resv_lock(dmabuf->resv, NULL); > + ctx->dev_ops->unmap(ctx, map); > + dma_resv_unlock(dmabuf->resv); > + > + dma_fence_put(&fence->base); You should probably set map->fence to NULL after that. > + percpu_ref_exit(&map->refs); > + kfree(map); > + > + if (refcount_dec_and_test(&ctx->refs)) { > + /* > + * Destruction needs to wait for I/O and dma fences. Defer it to > + * simplify locking. > + */ > + INIT_WORK(&ctx->release_work, dma_buf_io_ctx_destroy_work); > + queue_work(system_wq, &ctx->release_work); > + } > +} > + > +static void dma_buf_io_map_refs_release(struct percpu_ref *ref) > +{ > + struct dma_buf_io_map *map = container_of(ref, struct dma_buf_io_map, refs); > + > + /* might sleep, use a worker */ > + INIT_WORK(&map->release_work, dma_buf_io_map_release_work); > + queue_work(system_wq, &map->release_work); > +} > + > +int dma_buf_io_init_map(struct dma_buf_io_ctx *ctx, struct dma_buf_io_map *map) > +{ > + struct dma_buf_io_fence *fence = NULL; > + int ret; > + > + fence = kzalloc(sizeof(*fence), GFP_KERNEL); > + if (!fence) > + return -ENOMEM; > + > + ret = percpu_ref_init(&map->refs, dma_buf_io_map_refs_release, 0, GFP_KERNEL); > + if (ret) { > + kfree(fence); > + return ret; > + } > + > + spin_lock_init(&fence->lock); > + dma_fence_init(&fence->base, &dma_buf_io_fence_ops, &fence->lock, > + ctx->fence_ctx, atomic_inc_return(&ctx->fence_seq)); > + map->fence = fence; > + map->ctx = ctx; > + return 0; > +} > +EXPORT_SYMBOL_NS_GPL(dma_buf_io_init_map, "DMA_BUF"); > + > +struct dma_buf_io_map *dma_buf_io_create_map(struct dma_buf_io_ctx *ctx) > +{ > + struct dma_buf *dmabuf = ctx->dmabuf; > + struct dma_buf_io_map *map; > + long ret; > + > +retry: > + /* > + * ->dmabuf_map() will be calling dma_buf_map_attachment(), for which > + * we'll need to wait for fences. Do a bit nicer and try to wait > + * without the resv lock first. > + */ Clear NAK to that. Always wait while holding the resv lock if you can! It is absolutely not beneficial to do this outside of the lock and usually just hides problems instead and prevent fixing them. > + ret = dma_resv_wait_timeout(dmabuf->resv, DMA_RESV_USAGE_KERNEL, > + true, MAX_SCHEDULE_TIMEOUT); > + if (!ret) > + ret = -EAGAIN; > + if (ret < 0) > + return ERR_PTR(ret); > + > + ret = dma_resv_lock_interruptible(dmabuf->resv, NULL); > + if (ret) > + return ERR_PTR(ret); > + > + map = dma_buf_io_get_map(ctx); > + if (map) { > + ret = 0; > + goto out; > + } > + > + if (dma_resv_wait_timeout(dmabuf->resv, DMA_RESV_USAGE_KERNEL, > + true, 0) < 0) { > + dma_resv_unlock(dmabuf->resv); > + goto retry; > + } > + > + map = ctx->dev_ops->map(ctx); > + if (IS_ERR(map)) { > + ret = PTR_ERR(map); > + goto out; > + } > + > + percpu_ref_get(&map->refs); > + rcu_assign_pointer(ctx->map, map); > +out: > + dma_resv_unlock(dmabuf->resv); > + if (ret < 0) > + return ERR_PTR(ret); > + return map; > +} > + > +static void dma_buf_io_drop_map(struct dma_buf_io_ctx *ctx) > +{ > + struct dma_buf *dmabuf = ctx->dmabuf; > + struct dma_buf_io_map *map; > + int ret; > + > + dma_resv_assert_held(dmabuf->resv); > + > + map = rcu_dereference_protected(ctx->map, > + dma_resv_held(dmabuf->resv)); > + if (!map) > + return; > + rcu_assign_pointer(ctx->map, NULL); > + > + ret = dma_resv_reserve_fences(dmabuf->resv, 1); > + if (WARN_ON_ONCE(ret)) { > + struct dma_fence *fence = &map->fence->base; > + > + dma_fence_get(fence); > + percpu_ref_kill(&map->refs); > + dma_fence_wait(fence, false); > + dma_fence_put(fence); > + return; > + } > + > + dma_resv_add_fence(dmabuf->resv, &map->fence->base, > + DMA_RESV_USAGE_KERNEL); That sequence is clearly incorrect! The fence must be created after dma_resv_reserve_fences(), otherwise you definately have an illegal memory operation here. Regards, Christian. > + /* > + * Delay destruction until all inflight requests using the map arefence-> > + * gone. It'll also signal the fence then. > + */ > + percpu_ref_kill(&map->refs); > +} > + > +void dma_buf_io_invalidate_mappings(struct dma_buf_io_ctx *ctx) > +{ > + dma_buf_io_drop_map(ctx); > +} > +EXPORT_SYMBOL_NS_GPL(dma_buf_io_invalidate_mappings, "DMA_BUF"); > + > +static void dma_buf_io_ctx_release_work(struct work_struct *work) > +{ > + struct dma_buf_io_ctx *ctx = container_of(work, struct dma_buf_io_ctx, > + release_work); > + struct dma_buf *dmabuf = ctx->dmabuf; > + long ret; > + > + dma_resv_lock(dmabuf->resv, NULL); > + /* Remove the last map, there should be no new ones going forward. */ > + dma_buf_io_drop_map(ctx); > + dma_resv_unlock(dmabuf->resv); > + > + /* Wait until all maps are destroyed. */ > + ret = dma_resv_wait_timeout(dmabuf->resv, DMA_RESV_USAGE_KERNEL, > + false, MAX_SCHEDULE_TIMEOUT); > + > + if (WARN_ON_ONCE(ret <= 0)) > + return; > + if (WARN_ON_ONCE(rcu_dereference_protected(ctx->map, true))) > + return; > + > + if (refcount_dec_and_test(&ctx->refs)) > + dma_buf_io_ctx_destroy_work(&ctx->release_work); > +} > + > +void dma_buf_io_ctx_release(struct dma_buf_io_ctx *ctx) > +{ > + /* > + * Destruction needs to wait for I/O and dma fences. Defer it to > + * simplify locking. > + */ > + INIT_WORK(&ctx->release_work, dma_buf_io_ctx_release_work); > + queue_work(system_wq, &ctx->release_work); > +} > + > +int dma_buf_io_ctx_create(struct file *file, > + struct dma_buf_io_ctx *ctx, > + struct dma_buf *dmabuf, > + enum dma_data_direction dir) > +{ > + int ret; > + > + if (!file->f_op->init_dma_buf_io_ctx) > + return -EOPNOTSUPP; > + > + memset(ctx, 0, sizeof(*ctx)); > + ctx->fence_ctx = dma_fence_context_alloc(1); > + ctx->dir = dir; > + ctx->dmabuf = dmabuf; > + refcount_set(&ctx->refs, 1); > + get_dma_buf(dmabuf); > + > + ret = file->f_op->init_dma_buf_io_ctx(file, ctx); > + if (ret) { > + memset(ctx, 0, sizeof(*ctx)); > + dma_buf_put(dmabuf); > + return ret; > + } > + > + if (WARN_ON_ONCE(!ctx->dev_ops || > + !ctx->dev_ops->map || > + !ctx->dev_ops->unmap || > + !ctx->dev_ops->release)) > + return -EINVAL; > + > + return ret; > +} > diff --git a/include/linux/dma-buf-io.h b/include/linux/dma-buf-io.h > new file mode 100644 > index 000000000000..bcffc6202556 > --- /dev/null > +++ b/include/linux/dma-buf-io.h > @@ -0,0 +1,91 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +#ifndef __DMA_BUF_IO_H__ > +#define __DMA_BUF_IO_H__ > + > +#include <linux/dma-buf.h> > + > +struct dma_buf_io_fence; > +struct dma_buf_io_ctx; > +struct dma_buf_io_map; > + > +struct dma_buf_io_ops { > + /* > + * Create a new map for the given ctx. Called with the reservation > + * lock held. > + */ > + struct dma_buf_io_map *(*map)(struct dma_buf_io_ctx *ctx); > + > + /* > + * Clean up device specific parts of the @map. Called with the > + * reservation lock held. > + */ > + void (*unmap)(struct dma_buf_io_ctx *ctx, struct dma_buf_io_map *map); > + > + /* > + * The user tries to destroy the ctx. Release all device specific > + * parts of the token. > + */ > + void (*release)(struct dma_buf_io_ctx *); > +}; > + > +struct dma_buf_io_map { > + /* > + * Counts attached requests and other users. Device specific unmapping > + * is deferred until all refs are dropped. > + */ > + struct percpu_ref refs; > + > + struct work_struct release_work; > + struct dma_buf_io_fence *fence; > + struct dma_buf_io_ctx *ctx; > +}; > + > +struct dma_buf_io_ctx { > + struct dma_buf_io_map __rcu *map; > + struct dma_buf *dmabuf; > + enum dma_data_direction dir; > + > + atomic_t fence_seq; > + u64 fence_ctx; > + struct work_struct release_work; > + refcount_t refs; > + > + void *dev_priv; > + const struct dma_buf_io_ops *dev_ops; > +}; > + > +int dma_buf_io_ctx_create(struct file *file, > + struct dma_buf_io_ctx *ctx, > + struct dma_buf *dmabuf, > + enum dma_data_direction dir); > +void dma_buf_io_ctx_release(struct dma_buf_io_ctx *ctx); > + > +struct dma_buf_io_map *dma_buf_io_create_map(struct dma_buf_io_ctx *ctx); > + > +static inline struct dma_buf_io_map * > +dma_buf_io_get_map(struct dma_buf_io_ctx *ctx) > +{ > + struct dma_buf_io_map *map; > + > + guard(rcu)(); > + > + map = rcu_dereference(ctx->map); > + if (unlikely(!map || !percpu_ref_tryget_live_rcu(&map->refs))) > + return NULL; > + > + return map; > +} > + > +static inline void dma_buf_io_map_drop(struct dma_buf_io_map *map) > +{ > + percpu_ref_put(&map->refs); > +} > + > +/* > + * Device API > + */ > + > +void dma_buf_io_invalidate_mappings(struct dma_buf_io_ctx *ctx); > +int dma_buf_io_init_map(struct dma_buf_io_ctx *ctx, struct dma_buf_io_map *map); > + > +#endif > diff --git a/include/linux/fs.h b/include/linux/fs.h > index d10897b3a1e3..9fe349a279c7 100644 > --- a/include/linux/fs.h > +++ b/include/linux/fs.h > @@ -1914,6 +1914,7 @@ struct dir_context { > #define COPY_FILE_SPLICE (1 << 0) > > struct io_uring_cmd; > +struct dma_buf_io_ctx; > struct offset_ctx; > > typedef unsigned int __bitwise fop_flags_t; > @@ -1962,6 +1963,7 @@ struct file_operations { > int (*uring_cmd_iopoll)(struct io_uring_cmd *, struct io_comp_batch *, > unsigned int poll_flags); > int (*mmap_prepare)(struct vm_area_desc *); > + int (*init_dma_buf_io_ctx)(struct file *, struct dma_buf_io_ctx *); > } __randomize_layout; > > /* Supports async buffered reads */

5 hours, 34 minutes

Re: [PATCH v8 4/5] rust: Add dma_fence abstractions

by Philipp Stanner

On Tue, 2026-08-04 at 14:54 -0300, Daniel Almeida wrote: > > Hi Phillip :) > > Tested-by: Daniel Almeida <daniel.almeida(a)collabora.com> Hi, thx for the test I address your major feedback below; minor points like renaming I will address in the next revision. > > > On 31 Jul 2026, at 05:04, Philipp Stanner <phasta(a)kernel.org> wrote: > > […] > > An additional issue discovered during the review process of this code is > > that there is (currently) no mechanism in Rust to prevent someone from > > circumventing the DriverFence's FenceContext-reference's lifetime by > > "forgetting" the fence, e.g. with core::mem::forget(). Since this > > apparently can also happen with recfounting cycles, it's quite likely > > that it would enable UAF bugs on the FenceContext. Print warnings if > > this or other misuse of the fence API happens. > > I think cycles are fine, if anything they make things live longer than intended > (possibly leaking them forever), but at no point they lead to UAFs. And for the > mem::forget() point, there seems to be precedent in other patches pointing to > unsafe constructors, where the safety requirement is basically "don't > mem::forget() this". > > In fact, if you mem::forget() in the previous Arc approach, it seems like you leak > the context, while mem::forget() on the current solution does seem to allow UAF > by ending the borrow as you said yourself: > > let ctx = .... // FenceContext in some driver queue structure > let fence = ctx.fence_alloc(...).new_fence() // DriverFence<'_, T> // borrows ctx > mem::forget(fence); // ends the borrow > drop(ctx); // DriverFenceData contains a dangling &FenceContext, and that allocation is managed by C > > versus: > > let ctx: Arc<FenceCtx<...>> = ...; // same as above, assume refcount==1 > let fence = ctx.new_fence_allocation(..).new_fence(); // ctx refcount==2 > mem::forget(fence); // ctx refcount==2 > drop(ctx) //ctx refcount==1 > > I noticed that you added a counter to catch the first case, but that assumes that > signaled fences won’t reach into the context anymore, IIUC? More on that below. Answering on that further down below > > > […] > > SPDX is being used here, > > > + > > +/* > > + * Copyright (C) 2025, 2026 Red Hat Inc.: > > + * Author: Philipp Stanner <pstanner(a)redhat.com> > > + */ > > So perhaps SPDX-CopyrightText should be used here? What does that look like? I think I never saw it anywhere. > > > + > > […] > > > + // happening. > > + // > > + // However, we cannot fully guarantee in Rust that `DriverFence`s will not > > + // be forgotten, e.g., through refcounting. This could circumvent the > > + // lifetime which intends to enforce that all fences disappear before their > > + // context. > > + nr_of_unsignaled_fences: Atomic<u64>, > > Why are we tracking the number of unsignaled fences, specifically? Is it not > possible for the C side (which controls the actual allocation) to reach back > into the Rust side via the callbacks even after the context drops, regardless > of their signaled status? Tracking the number was agreed on as a compromise to move the abstraction forward. It only exists for a warning-print. The signaled status is absolutely decisive for preventing that both the DriverFence::data and FenceContext cannot be reached anymore by both C *and* Rust code consuming a Fence. The reason is that the fence backend ops can reach the DriverFence and the FenceContext. Only signalling the fence decouples them, and then you still have to wait for an RCU grace period to be sure that all accessors are gone. This is what the C backend forces on us, but it also applies for someone doing (future implementations of) Fence::get_driver_name() or Fence::is_signaled(). > > And in any case, even side stepping this signaled vs unsignaled dilemma that > this counter is trying to check, the end result seems to be "sorry, you misused > the API and now a UAF is possible". In this specific sense, it doesn't sound > that much better than what we are trying to move away from in C. > > The more I think about this borrow design, the more I believe a simple refcount > would be way safer. I mean, this field would go away to begin with, IIUC, and > that’s not even considering the point above. Refcounting does not solve the fundamental issue. A dma_fence must always correctly represent the state of the associated job on the GPU. If you forget a fence, you might deadlock. If you signal a fence for a job that is still running on the GPU, you might get unnoticed memory corruptions. Refcounting the fctx was also my solution, but was objected to by various parties (IIRC at least Boris and Danilo) who argue that the life time is the proper solution. If I understood correctly the major objection is that the refcount enables the device resources in FenceContext::data to arbitrarily outlive its device, which is something Danilo is very concerned about. Anyways, as we discussed in the call, and as also my code comment in FenceContext::drop() highlights, this atomic is only there for printing a warning, because the proper solution we actually want is to have the FenceContext signal all forgotten fences when it drops. *Then* you are really completely safe, because then the forgotten fences get decoupled from the fence context. So no UAF, although a driver that forgets fences would still be broken. The reason why (IIRC) Alice proposed doing the counter + warning and a TODO entry is to move forward faster with the fence implementation, which I understood is also in Tyr's interest (regarding this unlikely bug). The reason why it is not solved right now is that you need a data structure in FenceContext that keeps track of unsignaled fences. Entries in that data structure then have to be pre-allocated. And you have to remove entries from the data structure *whenever a fence signals*. The only good data structure we have in Rust currently is XArray, which we cannot use because: * it uses `usize` as an index, but dma_fence seqno is u64, so this could become a problem for Tyr, supporting 32-bit architectures. * We'd need to wait for Andreas' reservation mechanism for XArray. * XArray is not a good data structure for ever-increasing seqnos like the u64 of dma_fence. It quickly performance-degrades because it preserves index order, resulting in like a dozen pointer indirections for large indices. So I had investigated using a List, but the list would force you then to shove another refcounting mechanism (ListArc) on top of the stored fences, and Rust's list implementation is really not trivial to be used. At least not for me. Getting this right would take time. Note that with the JobQueue design we're aiming at right now, DriverFence and FenceContext would all be owned by JobQueue, so the driver couldn't ever forget a DriverFence whithout also forgetting the FenceContext. Hence, for the forseeable future, no one will encounter that bug. So, long story short, this is a solvable TODO, but we need a good data structure for it. Preferably a hash table? Or the list implementation needs to be improved so that it can take an ARef<Fence> instead of a ListArc<Fence>. But someone needs to do that work. Please tell me whether you agree with proceeding like this and make FenceContext::drop() completely waterproof later, or whether you want to suggest to do that now – but then I'd need help with the data structures. > > > > […] > > + /// The `data` you pass here must not perform any operations that are illegal > > + /// in atomic context in its [`Drop`] implementation. > > + pub fn fence_alloc(&self, data: T::FenceDataType) -> Result<DriverFenceAllocation<'_, T>> { > > ^ In the same spirit as the last iteration, can we please rename this? > > We don’t need to shorten methods and types IMHO. We can just say > “new_allocation” or a some other variation without “alloc”. Well, the name IMO needs to reflect that this method creates some fency object. So just "new_allocation" is not good I think because you want to see *what* is being allocated. new_fence_allocation() maybe? > > > […] > > +/// The receiving counterpart of a [`DriverFence`]. > > +/// > > +/// The Rust DMA fence implementation has a dualistic design: [`DriverFence`]s > > +/// are the producer-side, intended to be always owned by only one party. That > > +/// party has the monopoly on signalling the fence. > > +/// > > +/// A [`Fence`] is the counterpart for consumers. Thus, [`Fence`]s are always > > +/// refcounted and can shared with an arbitrary number of parties, including > > +/// userspace. Hereby, a [`Fence`] can only be used for actions such as checking > > +/// the fence's status or for registering callbacks on it. > > +/// > > +/// Once the associated [`DriverFence`] signals, all > > +/// [`FenceCallbackRegistration`]s registered on the [`Fence`] will be executed. > > +/// > > +/// A [`Fence`] can arbitrarily outlive its [`DriverFence`] and the > > +/// [`FenceContext`]. Signalling a [`DriverFence`] decouples it from its > > +/// [`Fence`]s. > > +#[repr(transparent)] > > +pub struct Fence { > > + /// The actual dma_fence passed to C. > > + inner: Opaque<bindings::dma_fence>, > > +} > > + > > +/// Guard helper for locking within this module. > > Is this new? Needs a bit more documentation. It is new, yes. Changelog mentions it. > > OTOH I think we shouldn’t come up with a new guard type. IIRC from > Lyude’s et al previous work, there’s already a way to build a Rust lock > from a C lock (Lock::from_raw()). In fact, I think this whole implementation > can boil down to: > > pub fn lock(&self) -> SpinLockIrqGuard<‘_, ()> { > let ptr = unsafe {bindings::dma_fence_spinlock(…)}; > unsafe { SpinLockIrq::<()>::from_raw(ptr)}.lock() > } > > This has a few advantages: > > a) doesn’t introduce its own guard type, instead reusing something that was > previously tested, > > b) you get the right behavior with the included NotThreadSafe token. > > c) the guard is now borrowed. Your guard is owned, which can easily lead to UB > because the lifetime is detached from the &self that originated it. This little helper is only used internally, and where it is used other code bits have to operate on the rawpointer with other unsafe blocks. At other places we use the fence rawpointer without taking the lock. So I'm not sure whether this will ever be clean. The only reason I added it was that I by now had 3 places where I do unsafe { } lock and unlock. Lyude's code is not yet merged. […] > > > +/// > > +/// let mut fctx = KBox::pin_init(FenceContext::new(0, driver_name, timeline_name, fctx_data), GFP_KERNEL)?; > > Missing rustfmt? I do run rustfmt. It doesn't do anything about this line. P.

5 hours, 54 minutes

Slope Unblocked: The Addictive 3D Runner That’s Taking Over Study Halls Everywhere

by constant.quelea.lmkv＠hidepost.net

Hey there, fellow digital adventurers and keyboard warriors! If you’ve ever found yourself staring at a blank browser tab during a free period, wondering how to turn five minutes of boredom into a heart-pumping, reflex-testing, neon-soaked thrill ride, then pull up a chair. We need to talk about Slope Unblocked. You might have seen it. You might have even played it on a friend’s laptop when the teacher wasn’t looking. But let me tell you, this isn’t just another endless runner. This is a beautiful, chaotic, and surprisingly deep test of your spatial awareness, your reaction time, and your ability to stay calm while a glowing ball hurtles down a digital death trap at Mach speed. And the best part? You can access it right now for free at slopefree.org, no downloads, no logins, just pure unadulterated momentum. So, grab your favorite beverage, get comfortable, and let’s take a deep dive into why this seemingly simple game has become a cultural phenomenon in schools, offices, and anywhere else with a strict firewall and a weak spot for addictive gameplay. Visit: https://slopefree.org/ 1. How to Play Slope Unblocked Alright, let’s get down to business. How do you actually play this thing? I promise it’s easier than it looks, but mastering it is another story entirely. The Core Mechanic The entire game is controlled with just two keys (or one, if you’re feeling lazy). You use the Left Arrow and Right Arrow keys (or the A and D keys) to steer the ball. That’s it. There’s no jump button, no boost, no brake. Once you start, you’re committed to the roll until you either hit a red block or fly off the edge into the void. The Art of Steering The first mistake everyone makes is treating the game like a racing game. You don’t want to "correct" your path. You want to make smooth, sweeping adjustments. The ball has momentum and inertia. If you tap the right arrow, the ball starts drifting right. If you hold it, you’ll curve sharply. The key is to look ahead of the ball, not at it. Your eyes should be focused on the middle-distance, scanning for the next cluster of obstacles. The Obstacles The world of Slope is a harsh place. You’ll encounter two main types of hazards: Red Blocks: These are solid, geometric barriers. Hitting one is instant death. They come in various sizes and configurations, sometimes forming narrow corridors, sometimes scattered randomly like a minefield. The Void: The path has no guardrails. If you oversteer or mistime a turn, you’ll slip off the edge into the abyss below. This is actually more common than hitting a block, especially at higher speeds. Reading the Path The path isn't just flat. It tilts. Sometimes you’ll go over a hump, which sends you airborne for a split second. This is terrifying because you have no control while in the air. The best advice is to keep your ball steady during these moments, as landing off-center can spin you out. The floor also has a subtle purple/blue grid that gets dizzying if you stare too long. Focus on the solid colors and the red blocks. 2. Top Tips and Tricks from a Veteran Roller Alright, you’ve got the basics. You know how to steer. But you want to actually get a high score, right? You want to last more than a minute without spiraling off into the neon void. Here are some battle-tested tips that I’ve picked up from losing hours of my life to this beautiful game. Tip 1: Listen to Your Ears This is the most underrated tip in the game. Yes, the music is a driving synthwave track that fits the aesthetic perfectly. But the sound effects are your best friend. The ball makes a rolling sound that gets faster and breaks up when you hit a bump. More importantly, listening helps with anticipation. You can hear the rhythm of the track, which surprisingly syncs up with the flow of the level in the early stages. Take your headphones off at your own risk. Tip 2: Use the Full Width of the Track Many beginners instinctively stay in the center. This is a fatal error. The center is full of blocks. The edges are your friend. Try to weave in a sine-wave pattern across the width of the path. This gives you more room to maneuver around obstacles. When you see a block coming, don’t panic. Steer wide around it, swing to the opposite side, and then come back to the middle. Being comfortable on the edge of the void is key to going far. Tip 3: Small Taps, Not Long Presses Huge sweeping movements will kill you. If the ball is drifting slightly left and you need to go right, do a quick tap. The less time you spend holding the key, the more stable your trajectory. The game is about finesse, not brute force. Think of it like steering a shopping cart; if you yank the wheel too hard, you’re going to tip over. Tip 4: When in Doubt, Speed Up This sounds counter-intuitive, but I’ve found it to be true. The game speeds up over time regardless, but if you are coming out of a turn and you have a clear straightaway, let it roll. Don’t try to slow down (you can’t) and don’t try to brake. Slower speeds make you feel like you have control, but actually, dragging the ball makes it twitchy. Trust the momentum and keep it flowing. Tip 5: Master the "Wiggle" Once you get to high scores (200+), the path becomes incredibly cramped. You’ll have to navigate slalom courses that seem impossible. The secret is to use the "wiggle" technique. This is where you tap left and right rapidly to thread the needle through tight gaps. It looks frantic, but it allows you to make micro-adjustments without committing to a full turn. 3. Ready to Roll? So, there you have it. The lowdown on one of the greatest browser games ever conceived. Whether you’re looking to set a new personal best, show off to your friends, or just want to feel the wind in your digital hair while navigating a geometric nightmare, Slope Unblocked has got you covered. Don’t just take my word for it. The proof is in the rolling. If you’re stuck at your desk right now, bored out of your mind, do yourself a favor. Open a new tab. Head over to Slope Unblocked. Click play. And try not to blink. I guarantee that by your third run, you’ll be hooked. Go ahead, see how long you can last. I’ll be waiting at the top of the high-score table. Or, more likely, I’ll be falling off the edge right next to you. See you on the neon track! Have any amazing high scores? Or a story about getting caught playing this during class? Drop a comment below. I want to hear your chaos! Visit: https://slopefree.org/

6 hours, 24 minutes

Slope Unblocked: The Addictive 3D Runner That’s Taking Over Study Halls Everywhere

by constant.quelea.lmkv＠hidepost.net

Hey there, fellow digital adventurers and keyboard warriors! If you’ve ever found yourself staring at a blank browser tab during a free period, wondering how to turn five minutes of boredom into a heart-pumping, reflex-testing, neon-soaked thrill ride, then pull up a chair. We need to talk about Slope Unblocked. You might have seen it. You might have even played it on a friend’s laptop when the teacher wasn’t looking. But let me tell you, this isn’t just another endless runner. This is a beautiful, chaotic, and surprisingly deep test of your spatial awareness, your reaction time, and your ability to stay calm while a glowing ball hurtles down a digital death trap at Mach speed. And the best part? You can access it right now for free at slopefree.org, no downloads, no logins, just pure unadulterated momentum. So, grab your favorite beverage, get comfortable, and let’s take a deep dive into why this seemingly simple game has become a cultural phenomenon in schools, offices, and anywhere else with a strict firewall and a weak spot for addictive gameplay. Visit: https://slopefree.org/ 1. How to Play Slope Unblocked Before we get into the nitty-gritty, let’s define our subject. Slope Unblocked is a 3D endless runner game where you control a glowing ball rolling down an endless, procedurally generated corridor. The path is tilted, twisting, and full of obstacles. Your job? Don’t crash. That’s it. That’s the whole game. But here’s the kicker: the game speeds up the further you go. What starts as a leisurely roll down a geometric rainbow quickly becomes a white-knuckle, split-second decision-making simulator. The camera is positioned behind the ball, giving you a slightly elevated third-person perspective. The aesthetic is pure neon wireframe, think Tron legacy if it was designed by a minimalist with a love for 80s synthwave. Why is it so popular? It’s accessible. You don’t need a gaming PC. You don’t need to create an account. You just open a tab, click, and you’re rolling. It’s the digital equivalent of a stress ball, but way more fun and with a lot more flying off the edge of a digital cliff. 2. How to Play Slope Unblocked Alright, let’s get down to business. How do you actually play this thing? I promise it’s easier than it looks, but mastering it is another story entirely. The Core Mechanic The entire game is controlled with just two keys (or one, if you’re feeling lazy). You use the Left Arrow and Right Arrow keys (or the A and D keys) to steer the ball. That’s it. There’s no jump button, no boost, no brake. Once you start, you’re committed to the roll until you either hit a red block or fly off the edge into the void. The Art of Steering The first mistake everyone makes is treating the game like a racing game. You don’t want to "correct" your path. You want to make smooth, sweeping adjustments. The ball has momentum and inertia. If you tap the right arrow, the ball starts drifting right. If you hold it, you’ll curve sharply. The key is to look ahead of the ball, not at it. Your eyes should be focused on the middle-distance, scanning for the next cluster of obstacles. The Obstacles The world of Slope is a harsh place. You’ll encounter two main types of hazards: Red Blocks: These are solid, geometric barriers. Hitting one is instant death. They come in various sizes and configurations, sometimes forming narrow corridors, sometimes scattered randomly like a minefield. The Void: The path has no guardrails. If you oversteer or mistime a turn, you’ll slip off the edge into the abyss below. This is actually more common than hitting a block, especially at higher speeds. Reading the Path The path isn't just flat. It tilts. Sometimes you’ll go over a hump, which sends you airborne for a split second. This is terrifying because you have no control while in the air. The best advice is to keep your ball steady during these moments, as landing off-center can spin you out. The floor also has a subtle purple/blue grid that gets dizzying if you stare too long. Focus on the solid colors and the red blocks. 3. Top Tips and Tricks from a Veteran Roller Alright, you’ve got the basics. You know how to steer. But you want to actually get a high score, right? You want to last more than a minute without spiraling off into the neon void. Here are some battle-tested tips that I’ve picked up from losing hours of my life to this beautiful game. Tip 1: Listen to Your Ears This is the most underrated tip in the game. Yes, the music is a driving synthwave track that fits the aesthetic perfectly. But the sound effects are your best friend. The ball makes a rolling sound that gets faster and breaks up when you hit a bump. More importantly, listening helps with anticipation. You can hear the rhythm of the track, which surprisingly syncs up with the flow of the level in the early stages. Take your headphones off at your own risk. Tip 2: Use the Full Width of the Track Many beginners instinctively stay in the center. This is a fatal error. The center is full of blocks. The edges are your friend. Try to weave in a sine-wave pattern across the width of the path. This gives you more room to maneuver around obstacles. When you see a block coming, don’t panic. Steer wide around it, swing to the opposite side, and then come back to the middle. Being comfortable on the edge of the void is key to going far. Tip 3: Small Taps, Not Long Presses Huge sweeping movements will kill you. If the ball is drifting slightly left and you need to go right, do a quick tap. The less time you spend holding the key, the more stable your trajectory. The game is about finesse, not brute force. Think of it like steering a shopping cart; if you yank the wheel too hard, you’re going to tip over. Tip 4: When in Doubt, Speed Up This sounds counter-intuitive, but I’ve found it to be true. The game speeds up over time regardless, but if you are coming out of a turn and you have a clear straightaway, let it roll. Don’t try to slow down (you can’t) and don’t try to brake. Slower speeds make you feel like you have control, but actually, dragging the ball makes it twitchy. Trust the momentum and keep it flowing. Tip 5: Master the "Wiggle" Once you get to high scores (200+), the path becomes incredibly cramped. You’ll have to navigate slalom courses that seem impossible. The secret is to use the "wiggle" technique. This is where you tap left and right rapidly to thread the needle through tight gaps. It looks frantic, but it allows you to make micro-adjustments without committing to a full turn. 4. Ready to Roll? So, there you have it. The lowdown on one of the greatest browser games ever conceived. Whether you’re looking to set a new personal best, show off to your friends, or just want to feel the wind in your digital hair while navigating a geometric nightmare, Slope Unblocked has got you covered. Don’t just take my word for it. The proof is in the rolling. If you’re stuck at your desk right now, bored out of your mind, do yourself a favor. Open a new tab. Head over to Slope Unblocked. Click play. And try not to blink. I guarantee that by your third run, you’ll be hooked. Go ahead, see how long you can last. I’ll be waiting at the top of the high-score table. Or, more likely, I’ll be falling off the edge right next to you. See you on the neon track! Have any amazing high scores? Or a story about getting caught playing this during class? Drop a comment below. I want to hear your chaos! Visit: https://slopefree.org/

6 hours, 36 minutes

Currency and Resource Management in 67 Clicker

by hermanlamb911＠gmail.com

Most clicker games include one or more forms of in-game currency. Currency serves as the foundation of progression because nearly every upgrade requires players to spend their accumulated resources. Players must decide how to invest their earnings wisely. Spending currency immediately provides quick improvements, while saving for expensive upgrades may offer greater long-term benefits. This creates meaningful decision-making despite the game's simple mechanics. As players advance, additional currencies may become available through special events, rebirth systems, or premium areas. Multiple currencies increase the complexity of progression while giving experienced players additional goals to pursue. Effective resource management often separates faster progression from slower advancement. Upgrade Mechanics Upgrades represent one of the most important gameplay systems. Without upgrades, progression would remain slow and repetitive. The 67 Clicker Game offers various improvements that increase efficiency. Common upgrade categories include: Higher click power. Faster resource generation. Increased movement speed. Better inventory capacity. Automatic clicking. Bonus multipliers. Improved luck. Reduced upgrade costs. Choosing which upgrades to purchase first becomes an important strategic decision. Some upgrades provide immediate benefits, while others become more valuable during later stages of the game. Players gradually learn the most efficient upgrade paths through experimentation and experience. Pets and Companions Pets are a defining feature of many Roblox clicker games. Instead of serving only as cosmetic companions, pets provide gameplay bonuses that improve progression. Players usually obtain pets by opening eggs purchased with in-game currency. Each egg contains pets with different rarity levels. Rare pets provide stronger bonuses, encouraging players to continue collecting and upgrading their collections. Typical pet bonuses include: Increased clicking power. Higher currency earnings. Improved luck. Faster experience gain. Event bonuses. Special abilities. Collecting pets introduces an element of randomness that keeps gameplay exciting. Every new egg creates anticipation because players hope to obtain rare or legendary companions. Many games also allow pets to be upgraded or combined into stronger versions, providing additional long-term objectives. Rebirth Mechanics One of the most important systems in clicker games is the rebirth mechanic. After reaching certain milestones, players can choose to restart much of their progress in exchange for permanent bonuses. At first glance, resetting progress may seem disadvantageous. However, rebirth rewards permanently increase earning potential, allowing players to progress much faster during future playthroughs. Benefits of rebirth often include: Permanent multipliers. Exclusive currencies. Special upgrades. Access to advanced worlds. Rare pets. Prestige rewards. The rebirth system creates a satisfying gameplay loop where each reset results in faster progression than before. Players continuously become stronger even after restarting their basic statistics. World Exploration World progression adds variety to gameplay by introducing new environments with stronger rewards. Each world generally requires players to achieve certain goals before unlocking access. New worlds often feature: Better rewards. Stronger upgrades. New eggs. Unique pets. Exclusive achievements. Higher earning potential. Exploration gives players reasons to continue improving beyond simple numerical growth. Every unlocked area introduces fresh objectives and visual changes that prevent gameplay from becoming repetitive. Achievements and Quests https://67clicker.io Achievements reward players for reaching specific milestones. Rather than focusing solely on clicking, achievements encourage players to explore every aspect of the game. Examples include: Total clicks completed. Currency earned. Pets collected. Eggs opened. Rebirths performed. Worlds unlocked. Time spent playing. Special event participation. Quests provide additional short-term goals that guide progression. Completing quests rewards players with currency, boosts, exclusive items, or experience. Together, achievements and quests create structured objectives that motivate players to continue playing.

6 hours, 37 minutes

Snow Rider: A Fun and Addictive Winter Adventure Game

by hermanlamb911＠gmail.com

Introduction In today's digital world, online games have become one of the most popular forms of entertainment. People of all ages enjoy games that are easy to access, simple to play, and exciting enough to keep them engaged for hours. Among the many browser games available, Snow Rider has earned a reputation as one of the most enjoyable endless running games. With its snowy landscapes, smooth controls, and fast-paced gameplay, Snow Rider offers players an exciting winter adventure that challenges both their reflexes and concentration. Unlike games that require expensive hardware or lengthy downloads, Snow Rider can usually be played directly through a web browser. This accessibility makes it a favorite among students, office workers, and casual gamers who want a quick gaming session during their free time. Despite its simple design, the game provides endless entertainment because every run is different, and every player strives to beat their previous high score. What Is Snow Rider? Snow Rider is an endless sledding game where players guide a sled down an icy mountain while avoiding various obstacles. The goal is straightforward: survive for as long as possible without crashing. The farther the player travels, the higher the score becomes. As the sled moves downhill, players encounter trees, rocks, fences, snowmen, giant snowballs, and many other hazards. Players must quickly steer left or right and jump over obstacles to continue their journey. A single collision immediately ends the game, encouraging players to improve their skills and try again. The endless format means there is no final level or ending. Instead, players continuously challenge themselves to travel farther than before. Simple Yet Engaging Gameplay One reason Snow Rider has become so popular is its simple gameplay. Most players learn the controls within a minute. The left and right arrow keys move the sled, while the spacebar or up arrow allows the sled to jump over obstacles. Although the controls are easy, surviving for a long distance requires excellent timing and concentration. As the sled gains speed, players have less time to react to obstacles. This gradual increase in difficulty creates excitement and encourages players to improve after every attempt. The game successfully demonstrates that complicated mechanics are not necessary for creating an enjoyable experience. Instead, smooth gameplay and balanced difficulty keep players entertained. Beautiful Winter Atmosphere One of the most attractive features of Snow Rider is its winter-themed environment. Snow-covered mountains, evergreen trees, icy paths, and festive decorations create a peaceful yet adventurous atmosphere. The bright colors and clean graphics make the game visually appealing without overwhelming the player. Many versions include holiday-inspired decorations such as gift boxes and cheerful snowmen, adding personality to the environment. The snowy scenery creates a relaxing mood while the increasing speed keeps players alert. The combination of calm visuals and exciting gameplay makes Snow Rider enjoyable throughout the year, even during warmer seasons. Endless Challenge Unlike traditional games with fixed levels, Snow Rider offers an endless challenge. Since the game never truly ends until the player crashes, every run feels unique. The random placement of obstacles prevents the gameplay from becoming repetitive. Even experienced players cannot memorize the course because each attempt presents new situations requiring quick decisions. This endless design motivates players to improve continuously. Every new personal record becomes an achievement, encouraging one more attempt to go even farther. Skill Development Although Snow Rider is primarily designed for entertainment, it also helps players develop several useful skills. Faster Reflexes The increasing speed requires quick reactions. Players learn to recognize obstacles rapidly and respond immediately with accurate movements. Improved Hand-Eye Coordination Controlling the sled while observing the changing environment strengthens coordination between visual perception and physical response. Better Concentration Maintaining focus is essential during longer runs. A brief moment of distraction can end the game instantly. Decision-Making in https://snow-rider3d.io Players constantly choose whether to steer left, steer right, or jump. Making the correct decision within a fraction of a second is key to survival.

6 hours, 39 minutes

Block Blast: The Puzzle Game That Challenges the Mind

by tynsareatger＠gmail.com

Introduction Mobile games have become an important part of modern entertainment. People play them while traveling, relaxing at home, or taking short breaks from work and school. Among the thousands of games available today, puzzle games remain some of the most popular because they combine fun with mental challenges. One game that has attracted millions of players is Block Blast. Its simple design, strategic gameplay, and satisfying mechanics make it enjoyable for children, teenagers, adults, and even older players. Unlike games that depend on fast reactions or complex controls, Block Blast rewards careful thinking and planning. Every move matters, and players must use logic to keep the board clear while earning as many points as possible. The game is easy to begin but difficult to master, making it appealing to both casual players and puzzle enthusiasts. Beyond entertainment, Block Blast also helps develop important thinking skills such as concentration, problem-solving, and patience. This essay discusses the gameplay, popularity, benefits, challenges, strategies, and future of Block Blast, showing why it has become one of the most successful puzzle games on mobile devices. Understanding the Game Block Blast is a single-player puzzle game in which players place blocks of different shapes onto a square grid. The objective is to fill complete rows or columns so they disappear from the board. Each cleared line earns points and creates more room for additional blocks. At any time, players receive several block pieces and decide where each one should be placed. Since the game does not usually allow pieces to be rotated, every decision becomes important. If the board fills up and no available space remains for the next block, the game ends. Although the rules are simple, each move affects future possibilities. Players who think ahead generally achieve much higher scores than those who place blocks without a plan. Why People Enjoy Block Blast One of the biggest reasons for Block Blast's popularity is its accessibility. New players can understand the basic rules within minutes without reading long instructions or watching tutorials. The drag-and-drop controls are intuitive, making the game suitable for all age groups. Another reason is the satisfying feeling of clearing lines. Watching several rows disappear at once creates a rewarding experience that encourages players to continue improving. Since every game presents different block combinations, each session feels fresh and unique. The game also offers flexibility. Some people play for only five minutes during a break, while others spend much longer trying to beat their personal best scores. Because there is no fixed ending, players can continue challenging themselves indefinitely. https://blockblast-free.io

6 hours, 40 minutes

Snow Rider 3D

by tynsareatger＠gmail.com

Gameplay The gameplay is straightforward yet highly addictive. The sled automatically moves forward, while the player controls only the left and right movement using the keyboard arrow keys or the A and D keys. As players progress, they encounter numerous obstacles such as: Trees Snowmen Giant candy canes Rolling snowballs Wooden fences Rocks Ice barriers The player must react quickly to avoid collisions. Hitting even one obstacle immediately ends the game. Along the course, players collect gift boxes that serve as in-game rewards. These gifts can be used to unlock different sled designs, giving players additional goals beyond simply achieving a high score. The farther the player travels, the faster the sled moves, making the game increasingly challenging. This gradual increase in speed keeps players engaged and encourages repeated attempts to beat previous records. Graphics and Sound One of Snow Rider 3D's strongest features is its attractive visual presentation. Although the graphics are relatively simple compared to modern console games, they effectively create a cheerful winter atmosphere. The game features: Bright white snow-covered landscapes Colorful holiday decorations Smooth animations Realistic lighting Three-dimensional environments The snowy scenery creates a relaxing yet exciting environment. The obstacles are designed clearly, allowing players to identify them quickly while maintaining the game's festive appearance. Sound effects also contribute to the overall experience. The sounds of sliding across snow, collecting gifts, and crashing into obstacles provide satisfying feedback. Background music, when available, enhances the winter adventure without distracting players. Controls and Accessibility One reason for Snow Rider 3D's popularity is its simple controls. Unlike many games requiring multiple buttons or complicated combinations, Snow Rider 3D can be mastered within minutes. Basic controls include: Left Arrow or A key – Move left Right Arrow or D key – Move right Because the controls are so simple, players of nearly all ages can enjoy the game immediately. The game is also highly accessible because it runs directly in web browsers on most computers. Many versions even support mobile devices, making it easy to play anywhere. Challenges and Difficulty Although Snow Rider 3D is easy to learn, it becomes increasingly difficult over time. As players travel farther, several factors increase the challenge: Higher sled speed More frequent obstacles Narrow pathways Faster reaction times required This gradual difficulty curve keeps the game exciting. Players often believe they can improve with just "one more try," which contributes to its addictive nature. High-score competition is another important feature. Many players challenge their friends to beat their longest distance or highest number of collected gifts. Educational Benefits While Snow Rider 3D is primarily designed for entertainment, it also offers several educational and cognitive benefits. Improved Reflexes Players must react quickly to sudden obstacles. This constant practice improves reaction speed and hand-eye coordination. Better Concentration Maintaining focus is essential because losing concentration for even a second can result in crashing. Regular play strengthens attention skills. Decision-Making Players constantly decide which path offers the safest route. Quick decision-making becomes essential as the game speed increases. Patience and Persistence Since players often fail many times before achieving a new record, they learn perseverance and the importance of continuous improvement. Advantages Snow Rider 3D offers many advantages that explain its popularity. First, it is free to play on many websites, making it accessible to everyone. Second, the game loads quickly without requiring installation. Third, its controls are simple enough for beginners. Fourth, every run is different, providing endless replay value. Finally, unlocking new sleds gives players long-term goals that encourage continued play. https://snowrider3d.com

6 hours, 42 minutes

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig