Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

33 participants
7095 discussions

Re: [PATCH v3 06/11] mm/cma: Allow dynamically creating CMA areas

by Marek Szyprowski

On 08.07.2026 10:35, David Hildenbrand (Arm) wrote: > On 7/7/26 12:02, Marek Szyprowski wrote: >> On 01.07.2026 18:08, Thierry Reding wrote: >>> From: Thierry Reding <treding(a)nvidia.com> >>> >>> There is no technical reason why there should be a limited number of CMA >>> regions, so extract some code into helpers and use them to create extra >>> functions (cma_create() and cma_free()) that allow creating and freeing, >>> respectively, CMA regions dynamically at runtime. >> >> Well, the technical reason for not creating cma regions dynamically at >> runtime is that on some architectures (like 32bit ARM) the early fixup >> for the region is needed to make it functional for DMA. > Can you point me at the code that does that? Thanks! Check dma_contiguous_early_fixup() and dma_contiguous_remap() in arch/arm/mm/dma-mapping.c. Those functions ensures that the CPU mappings for the CMA reserved region in linear map are remapped with 4k pages instead of the 1M sections, so later, it will be possible to alter the mappings and change them to coherent when needed (altering 1M sections is not possible, because each process has it's own level-1 array even for the kernel linear mapping). However, in the use case in this patchset the reserved region is only shared with buddy allocator by using the CMA infrastructure, not registered to the regular DMA-mapping API, so it would work fine. I'm not convinced that this is the right API to use for this though. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland

11 minutes

A Guide to Mastering Slope

by sarahcolter＠wshu.net

Have you ever felt the exhilarating rush of speed, the focus demanded by precision, and the utter satisfaction of overcoming a seemingly impossible challenge? If so, then you might just be ready to tackle Slope. This deceptively simple online game has captivated players with its addictive gameplay and endless potential for improvement. It's a perfect little escape for a quick break or a dedicated practice session. Let's dive into how to play and, more importantly, how to experience the thrill of Slope. Introduction: What is Slope? At its core, Slope is a rolling ball game. You control a ball that’s constantly moving downhill, navigating a procedurally generated landscape of interconnected platforms. Sounds straightforward, right? Don’t be fooled! The platforms narrow, the speed increases relentlessly, and the gaps between platforms widen as you progress. One wrong move and you’re plummeting into the abyss. https://slopegame-online.com The brilliance of Slope lies in its accessibility and its learning curve. It's incredibly easy to pick up and play, yet fiendishly difficult to master. You don't need complicated controllers or extensive tutorials. Just a keyboard, a steady hand, and a determined spirit. It's a perfect example of a simple concept executed brilliantly. Gameplay: Navigating the Perilous Path The controls are as minimal as the aesthetic: the left and right arrow keys are all you need to guide your ball. Use the left arrow key to steer the ball left, and the right arrow key to steer it right. That's it! But mastering those two keys is the key to survival. Your objective is to stay on the platforms for as long as possible. As you roll further down the slope, your speed increases, and the environment becomes increasingly challenging. Red blocks appear, acting as obstacles that instantly end your run if touched. The platforms themselves will start to shift and move, adding another layer of complexity to the game. The game ends when your ball falls off the platform. Your score is determined by the distance you travelled before your demise. The higher the score, the better! The goal is to constantly improve your score, pushing yourself to see just how far you can go. Tips and Tricks for Conquering the Slope While the controls are simple, mastering Slope requires practice and a good understanding of the game's mechanics. Here are a few tips to help you improve your game: Smooth Movements Are Key: Avoid jerky, panicked movements. Small, controlled adjustments are far more effective than large, sweeping ones. Think less about reacting and more about anticipating. Look Ahead: Try to focus a little further down the slope. Anticipating the next turn or gap will give you more time to react and adjust your trajectory. This is easier said than done when the speed is high, but it's a crucial skill to develop. Embrace the Momentum: Understand how your ball's momentum affects its movement. Learn how to use the slight curve of the platforms to your advantage, especially when approaching tight turns. Don't Fear the Edges: Sometimes, the safest route is to ride along the edge of the platform. This allows you to make small corrections and avoid potential obstacles in the center. Practice, Practice, Practice: There's no substitute for practice. The more you play, the better you'll become at anticipating the challenges and reacting accordingly. Don't get discouraged by early failures. Everyone starts somewhere. You can visit Slope to begin practicing! Learn from Your Mistakes: Analyze your failures. What caused you to fall off the platform? Were you too slow to react? Did you misjudge the turn? Understanding your mistakes will help you avoid them in the future. Conclusion: The Enduring Appeal of an Endless Game Slope isn't about complicated storylines, stunning graphics, or intricate controls. It's about the pure, unadulterated challenge of pushing your skills to the limit. It's about the satisfaction of mastering a seemingly impossible task. It's about the addictive loop of playing, failing, learning, and improving. And its accessible nature means anyone can jump in and experience that thrill. So, go ahead, give it a try. You might just find yourself hooked on the endless decline. The simple controls and challenging gameplay make it a strangely addictive experience. It's a testament to the idea that sometimes, the simplest games are the most engaging.

1 hour, 39 minutes

Re: [PATCH v3 06/11] mm/cma: Allow dynamically creating CMA areas

by T.J. Mercier

On Wed, Jul 1, 2026 at 9:09 AM Thierry Reding <thierry.reding(a)kernel.org> wrote: > > From: Thierry Reding <treding(a)nvidia.com> > > There is no technical reason why there should be a limited number of CMA > regions, so extract some code into helpers and use them to create extra > functions (cma_create() and cma_free()) that allow creating and freeing, > respectively, CMA regions dynamically at runtime. > > The static array of CMA areas cannot be replaced by dynamically created > areas because for many of them, allocation must not fail and some cases > may need to initialize them before the slab allocator is even available. > To account for this, keep these "early" areas in a separate list and > track the dynamic areas in a separate list. Hi, It looks like you'll also need to update the CMA dma-buf heap's add_cma_heaps init function so that it adds all the CMA areas, not just the early ones. > > Signed-off-by: Thierry Reding <treding(a)nvidia.com> > --- > Changes in v3: > - rebase on top of recent linux-next, update kernel/dma/contiguous.c > - use kzalloc_obj() instead of kzalloc() with sizeof() > > Changes in v2: > - rename fixed number of CMA areas to reflect their main use > - account for pages in dynamically allocated regions > --- > arch/arm/mm/dma-mapping.c | 2 +- > arch/s390/mm/init.c | 2 +- > include/linux/cma.h | 8 +- > kernel/dma/contiguous.c | 2 +- > mm/cma.c | 187 +++++++++++++++++++++++++++++++++++++--------- > mm/cma.h | 5 +- > 6 files changed, 165 insertions(+), 41 deletions(-) > > diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c > index f9bc53b60f99..934952ab2102 100644 > --- a/arch/arm/mm/dma-mapping.c > +++ b/arch/arm/mm/dma-mapping.c > @@ -254,7 +254,7 @@ struct dma_contig_early_reserve { > unsigned long size; > }; > > -static struct dma_contig_early_reserve dma_mmu_remap[MAX_CMA_AREAS] __initdata; > +static struct dma_contig_early_reserve dma_mmu_remap[MAX_EARLY_CMA_AREAS] __initdata; > > static int dma_mmu_remap_num __initdata; > > diff --git a/arch/s390/mm/init.c b/arch/s390/mm/init.c > index f07168a0d3dd..f8f78f1434ea 100644 > --- a/arch/s390/mm/init.c > +++ b/arch/s390/mm/init.c > @@ -241,7 +241,7 @@ static int s390_cma_mem_notifier(struct notifier_block *nb, > mem_data.start = arg->start_pfn << PAGE_SHIFT; > mem_data.end = mem_data.start + (arg->nr_pages << PAGE_SHIFT); > if (action == MEM_GOING_OFFLINE) > - rc = cma_for_each_area(s390_cma_check_range, &mem_data); > + rc = cma_for_each_early_area(s390_cma_check_range, &mem_data); > return notifier_from_errno(rc); > } > > diff --git a/include/linux/cma.h b/include/linux/cma.h > index 8555d38a97b1..fb7a4923c3ba 100644 > --- a/include/linux/cma.h > +++ b/include/linux/cma.h > @@ -7,7 +7,7 @@ > #include <linux/numa.h> > > #ifdef CONFIG_CMA_AREAS > -#define MAX_CMA_AREAS CONFIG_CMA_AREAS > +#define MAX_EARLY_CMA_AREAS CONFIG_CMA_AREAS > #endif > > #define CMA_MAX_NAME 64 > @@ -57,8 +57,14 @@ struct page *cma_alloc_frozen_compound(struct cma *cma, unsigned int order); > bool cma_release_frozen(struct cma *cma, const struct page *pages, > unsigned long count); > > +extern int cma_for_each_early_area(int (*it)(struct cma *cma, void *data), void *data); > extern int cma_for_each_area(int (*it)(struct cma *cma, void *data), void *data); > extern bool cma_intersects(struct cma *cma, unsigned long start, unsigned long end); > > extern void cma_reserve_pages_on_error(struct cma *cma); > + > +extern struct cma *cma_create(phys_addr_t base, phys_addr_t size, > + unsigned int order_per_bit, const char *name); > +extern void cma_free(struct cma *cma); > + > #endif > diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c > index f754079a287d..7975551f69b3 100644 > --- a/kernel/dma/contiguous.c > +++ b/kernel/dma/contiguous.c > @@ -52,7 +52,7 @@ > #define CMA_SIZE_MBYTES 0 > #endif > > -static struct cma *dma_contiguous_areas[MAX_CMA_AREAS]; > +static struct cma *dma_contiguous_areas[MAX_EARLY_CMA_AREAS]; > static unsigned int dma_contiguous_areas_num; > > static int dma_contiguous_insert_area(struct cma *cma) > diff --git a/mm/cma.c b/mm/cma.c > index a13ce4999b39..f989e2e98594 100644 > --- a/mm/cma.c > +++ b/mm/cma.c > @@ -34,7 +34,12 @@ > #include "internal.h" > #include "cma.h" > > -struct cma cma_areas[MAX_CMA_AREAS]; > +static DEFINE_MUTEX(cma_lock); > + > +struct cma cma_early_areas[MAX_EARLY_CMA_AREAS]; > +unsigned int cma_early_area_count; > + > +static LIST_HEAD(cma_areas); > unsigned int cma_area_count; > > phys_addr_t cma_get_base(const struct cma *cma) > @@ -198,7 +203,6 @@ static void __init cma_activate_area(struct cma *cma) > free_reserved_page(pfn_to_page(pfn)); > } > } > - totalcma_pages -= cma->count; > cma->available_count = cma->count = 0; > pr_err("CMA area %s could not be activated\n", cma->name); > } > @@ -207,8 +211,8 @@ static int __init cma_init_reserved_areas(void) > { > int i; > > - for (i = 0; i < cma_area_count; i++) > - cma_activate_area(&cma_areas[i]); > + for (i = 0; i < cma_early_area_count; i++) > + cma_activate_area(&cma_early_areas[i]); > > return 0; > } > @@ -219,41 +223,77 @@ void __init cma_reserve_pages_on_error(struct cma *cma) > set_bit(CMA_RESERVE_PAGES_ON_ERROR, &cma->flags); > } > > +static void __init cma_init_area(struct cma *cma, const char *name, > + phys_addr_t size, unsigned int order_per_bit) > +{ > + if (name) > + strscpy(cma->name, name); > + else > + snprintf(cma->name, CMA_MAX_NAME, "cma%d\n", cma_area_count); > + > + cma->available_count = cma->count = size >> PAGE_SHIFT; > + cma->order_per_bit = order_per_bit; > + > + INIT_LIST_HEAD(&cma->node); > +} > + > static int __init cma_new_area(const char *name, phys_addr_t size, > unsigned int order_per_bit, > struct cma **res_cma) > { > struct cma *cma; > > - if (cma_area_count == ARRAY_SIZE(cma_areas)) { > + if (cma_early_area_count == ARRAY_SIZE(cma_early_areas)) { > pr_err("Not enough slots for CMA reserved regions!\n"); > return -ENOSPC; > } > > + mutex_lock(&cma_lock); > + > /* > * Each reserved area must be initialised later, when more kernel > * subsystems (like slab allocator) are available. > */ > - cma = &cma_areas[cma_area_count]; > - cma_area_count++; > + cma = &cma_early_areas[cma_early_area_count]; > + cma_early_area_count++; > > - if (name) > - strscpy(cma->name, name); > - else > - snprintf(cma->name, CMA_MAX_NAME, "cma%d\n", cma_area_count); > + cma_init_area(cma, name, size, order_per_bit); > > - cma->available_count = cma->count = size >> PAGE_SHIFT; > - cma->order_per_bit = order_per_bit; > - *res_cma = cma; > totalcma_pages += cma->count; > + *res_cma = cma; > + > + mutex_unlock(&cma_lock); > > return 0; > } > > static void __init cma_drop_area(struct cma *cma) > { > + mutex_lock(&cma_lock); > totalcma_pages -= cma->count; > - cma_area_count--; > + cma_early_area_count--; > + mutex_unlock(&cma_lock); > +} > + > +static int __init cma_check_memory(phys_addr_t base, phys_addr_t size) > +{ > + if (!size || !memblock_is_region_reserved(base, size)) > + return -EINVAL; > + > + /* > + * CMA uses CMA_MIN_ALIGNMENT_BYTES as alignment requirement which > + * needs pageblock_order to be initialized. Let's enforce it. > + */ > + if (!pageblock_order) { > + pr_err("pageblock_order not yet initialized. Called during early boot?\n"); > + return -EINVAL; > + } > + > + /* ensure minimal alignment required by mm core */ > + if (!IS_ALIGNED(base | size, CMA_MIN_ALIGNMENT_BYTES)) > + return -EINVAL; > + > + return 0; > } > > /** > @@ -276,22 +316,9 @@ int __init cma_init_reserved_mem(phys_addr_t base, phys_addr_t size, > struct cma *cma; > int ret; > > - /* Sanity checks */ > - if (!size || !memblock_is_region_reserved(base, size)) > - return -EINVAL; > - > - /* > - * CMA uses CMA_MIN_ALIGNMENT_BYTES as alignment requirement which > - * needs pageblock_order to be initialized. Let's enforce it. > - */ > - if (!pageblock_order) { > - pr_err("pageblock_order not yet initialized. Called during early boot?\n"); > - return -EINVAL; > - } > - > - /* ensure minimal alignment required by mm core */ > - if (!IS_ALIGNED(base | size, CMA_MIN_ALIGNMENT_BYTES)) > - return -EINVAL; > + ret = cma_check_memory(base, size); > + if (ret < 0) > + return ret; > > ret = cma_new_area(name, size, order_per_bit, &cma); > if (ret != 0) > @@ -444,7 +471,7 @@ static int __init __cma_declare_contiguous_nid(phys_addr_t *basep, > pr_debug("%s(size %pa, base %pa, limit %pa alignment %pa)\n", > __func__, &size, &base, &limit, &alignment); > > - if (cma_area_count == ARRAY_SIZE(cma_areas)) { > + if (cma_early_area_count == ARRAY_SIZE(cma_early_areas)) { > pr_err("Not enough slots for CMA reserved regions!\n"); > return -ENOSPC; > } > @@ -1051,12 +1078,12 @@ bool cma_release_frozen(struct cma *cma, const struct page *pages, > return true; > } > > -int cma_for_each_area(int (*it)(struct cma *cma, void *data), void *data) > +int cma_for_each_early_area(int (*it)(struct cma *cma, void *data), void *data) > { > int i; > > - for (i = 0; i < cma_area_count; i++) { > - int ret = it(&cma_areas[i], data); > + for (i = 0; i < cma_early_area_count; i++) { > + int ret = it(&cma_early_areas[i], data); > > if (ret) > return ret; > @@ -1065,6 +1092,25 @@ int cma_for_each_area(int (*it)(struct cma *cma, void *data), void *data) > return 0; > } > > +int cma_for_each_area(int (*it)(struct cma *cma, void *data), void *data) > +{ > + struct cma *cma; > + > + mutex_lock(&cma_lock); > + > + list_for_each_entry(cma, &cma_areas, node) { > + int ret = it(cma, data); > + > + if (ret) { > + mutex_unlock(&cma_lock); > + return ret; > + } > + } > + > + mutex_unlock(&cma_lock); > + return 0; > +} > + > bool cma_intersects(struct cma *cma, unsigned long start, unsigned long end) > { > int r; > @@ -1147,3 +1193,74 @@ void __init *cma_reserve_early(struct cma *cma, unsigned long size) > > return ret; > } > + > +struct cma *__init cma_create(phys_addr_t base, phys_addr_t size, > + unsigned int order_per_bit, const char *name) > +{ > + struct cma *cma; > + int ret; > + > + ret = cma_check_memory(base, size); > + if (ret < 0) > + return ERR_PTR(ret); > + > + cma = kzalloc_obj(*cma, GFP_KERNEL); > + if (!cma) > + return ERR_PTR(-ENOMEM); > + > + cma_init_area(cma, name, size, order_per_bit); > + cma->ranges[0].base_pfn = PFN_DOWN(base); > + cma->ranges[0].early_pfn = PFN_DOWN(base); > + cma->ranges[0].count = cma->count; > + cma->nranges = 1; > + > + cma_activate_area(cma); > + > + mutex_lock(&cma_lock); > + list_add_tail(&cma->node, &cma_areas); > + totalcma_pages += cma->count; > + cma_area_count++; > + mutex_unlock(&cma_lock); > + > + return cma; > +} > + > +void cma_free(struct cma *cma) > +{ > + unsigned int i; > + > + /* > + * Safety check to prevent a CMA with active allocations from being > + * released. > + */ > + for (i = 0; i < cma->nranges; i++) { > + unsigned long nbits = cma_bitmap_maxno(cma, &cma->ranges[i]); > + > + if (!bitmap_empty(cma->ranges[i].bitmap, nbits)) { > + WARN(1, "%s: range %u not empty\n", cma->name, i); > + return; > + } > + } > + > + /* free reserved pages and the bitmap */ > + for (i = 0; i < cma->nranges; i++) { > + struct cma_memrange *cmr = &cma->ranges[i]; > + unsigned long end_pfn, pfn; > + > + end_pfn = cmr->base_pfn + cmr->count; > + for (pfn = cmr->base_pfn; pfn < end_pfn; pfn++) > + free_reserved_page(pfn_to_page(pfn)); > + > + bitmap_free(cmr->bitmap); > + } > + > + mutex_destroy(&cma->alloc_mutex); > + > + mutex_lock(&cma_lock); > + totalcma_pages -= cma->count; > + list_del(&cma->node); > + cma_area_count--; > + mutex_unlock(&cma_lock); > + > + kfree(cma); > +} > diff --git a/mm/cma.h b/mm/cma.h > index c70180c36559..ae4db9819e38 100644 > --- a/mm/cma.h > +++ b/mm/cma.h > @@ -41,6 +41,7 @@ struct cma { > unsigned long available_count; > unsigned int order_per_bit; /* Order of pages represented by one bit */ > spinlock_t lock; > + struct list_head node; > struct mutex alloc_mutex; > #ifdef CONFIG_CMA_DEBUGFS > struct hlist_head mem_head; > @@ -71,8 +72,8 @@ enum cma_flags { > CMA_ACTIVATED, > }; > > -extern struct cma cma_areas[MAX_CMA_AREAS]; > -extern unsigned int cma_area_count; > +extern struct cma cma_early_areas[MAX_EARLY_CMA_AREAS]; > +extern unsigned int cma_early_area_count; > > static inline unsigned long cma_bitmap_maxno(struct cma *cma, > struct cma_memrange *cmr) > > -- > 2.54.0 >

6 hours, 18 minutes

Re: [PATCH v3 01/11] dt-bindings: reserved-memory: Document Tegra VPR

by Rob Herring

On Thu, Jul 2, 2026 at 7:58 AM Thierry Reding <thierry.reding(a)kernel.org> wrote: > > On Wed, Jul 01, 2026 at 02:53:10PM -0500, Rob Herring (Arm) wrote: > > > > On Wed, 01 Jul 2026 18:08:12 +0200, Thierry Reding wrote: > > > From: Thierry Reding <treding(a)nvidia.com> > > > > > > The Video Protection Region (VPR) found on NVIDIA Tegra chips is a > > > region of memory that is protected from CPU accesses. It is used to > > > decode and play back DRM protected content. > > > > > > It is a standard reserved memory region that can exist in two forms: > > > static VPR where the base address and size are fixed (uses the "reg" > > > property to describe the memory) and a resizable VPR where only the > > > size is known upfront and the OS can allocate it wherever it can be > > > accomodated. > > > > > > Reviewed-by: Rob Herring (Arm) <robh(a)kernel.org> > > > Signed-off-by: Thierry Reding <treding(a)nvidia.com> > > > --- > > > Changes in v2: > > > - add examples for fixed and resizable VPR > > > --- > > > .../nvidia,tegra-video-protection-region.yaml | 76 ++++++++++++++++++++++ > > > 1 file changed, 76 insertions(+) > > > > > > > My bot found errors running 'make dt_binding_check' on your patch: > > > > yamllint warnings/errors: > > > > dtschema/dtc warnings/errors: > > /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra-video-protection-region.example.dtb: protected@2a8000000 (nvidia,tegra-video-protection-region): reg: [[2, 2818572288], [0, 1879048192]] is too long > > from schema $id: http://devicetree.org/schemas/reserved-memory/nvidia,tegra-video-protection… > > /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra-video-protection-region.example.dtb: protected@2a8000000 (nvidia,tegra-video-protection-region): Unevaluated properties are not allowed ('no-map', 'reg' were unexpected) > > from schema $id: http://devicetree.org/schemas/reserved-memory/nvidia,tegra-video-protection… > > Any ideas why that second error shows up? It turns out that it goes away > when the first one is fixed (which admittedly is a stupid mistake), but > I spent quite a bit of time looking for a fix before realizing that it's > only a side-effect of the first. If a property fails validation in a referenced schema, then everything in that referenced schema is considered not evaluated. So then unevaluatedProperties is applied to the properties only in the referenced schema. That's why 'no-map' is also unevaluated. Just a quirk of how json-schema works... Rob

8 hours, 50 minutes

Assignment Help Canada

by lilywilson792＠gmail.com

Looking for a professional [url=https://www.assignmenthelpcanada.ca/essay-writing-service/]Essay Writing Service[/url]? AssignmentHelpCanada.ca provides custom-written essays that meet Canadian university standards. Every paper is plagiarism-free, well-researched, and delivered before the deadline.

9 hours, 42 minutes

IRS: Refund Status Update

by IRS.GOV

11 hours, 32 minutes

[PATCH v2 0/2] drm/drm_crtc: dma_fence_ops fixes

by André Draszik

Hi, These patches fix two issues in the drm/drm_crtc driver. Initially I was hitting the BUG_ON() in a scenario as explained in the commit message of what is now the second patch in this series. For the reasons outlines there, the BUG_ON() should just be removed. After posting, sashiko.dev noticed another issue, that was previously masked by the now-removed BUG_ON(). Since we can't have a loud BUG() be replaced with silent data corruption or worse, I've also added a patch to address this issue highlighted by sashiko.dev. I believe its observation and analysis to be correct. Cheers, Andre' Signed-off-by: André Draszik <andre.draszik(a)linaro.org> --- Changes in v2: - add new patch 1 to address sashiko observation - original patch 1 becomes patch 2 - patch 2: - don't turn fence_to_crtc() into macro (Jani, Philipp) - update commit message to include reference to deprecated use of BUG - Link to v1: https://lore.kernel.org/r/20260618-linux-drm_crtc_fix2-v1-1-c03e77b36f34@li… --- André Draszik (2): drm/drm_crtc: ensure dma_fence_ops remain valid during device unbind drm/drm_crtc: fix race with dma_fence_signal() in ::get_driver_name() drivers/gpu/drm/drm_crtc.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) --- base-commit: b9810cd75b9fb56a3425d391cba3f608502bd474 change-id: 20260618-linux-drm_crtc_fix2-23a7c354a412 Best regards, -- André Draszik <andre.draszik(a)linaro.org>

14 hours, 46 minutes

[PATCH v5 0/5] rust / dma_buf: Add abstractions for dma_fence

by Philipp Stanner

Changes since v4: - Fix an uninitialized memory bug for FenceCbRegistration with ManuallyDrop. - Return FenceCtx as impl PinInit - Make FenceCtx return an impl PinInit<T, Error> (Danilo) - Reformat some comments - Adjust the docu for rcu_barrier(), so that it matches the C side's docu and our docu for rcu::synchronize_rcu(). Changes since v3: - Add a FIXME for an encountered Rust compiler bug. (Gary) - Add new Rust files also to DRM drivers & common infrastructure MAINTAINERS file. (Danilo) - Reposition ECANCELED error code. (Miguel) - Replace refcounted FenceCtx in DriverFenceData with a reference plus life time. (Boris) - Re-add rcu_barrier() patch, since we now can use it for dropping the fence context. (Danilo) - Add forgotten R-b from Alice, and Acks for MAINTAINERS from Christian and Sumit. Changes since v2: - Don't drop DriverFenceData as a whole, but only the members we really want to drop. Gives more robustness. (Gary). - Break apart large pin_init_from_closure(). (Danilo, Onur) - Remove rcu_barrier() and synchronize_rcu() from FenceCtx::drop(). FenceCtx might drop in atomic context, where you must not perform those operations. With the current way C dma_fence is designed, the driver must wait for a grace period manually until it unloads. - Repair the DriverFenceBorrow implementation, properly injecting a life time into it. (Danilo) - Fix memory layout bug for rcu_head. (Onur) - Drop RCU patches, since this series doesn't need them anymore. Changes since v1: - Remove unnecessary mutable references (Alice) - Split up unsafe comments where possible (Danilo) - Remove PhantomData + implement FenceCtx ops trait (Boris) - Consistently call FenceCtx generic data `T`. FenceDataType is derived from that. (Boris) - Add abstractions for call_rcu() and synchronize_rcu() (Danilo) - Add ECANCELED error code in Rust (Alice) - Remove the rcu_barrier() from FenceCtx::drop() – because we now use call_rcu(), there can be no UAF access to the FenceCtx anymore. In any case, it is illegal to use either call_rcu() or synchronize_rcu() in FenceCtx::drop(), because our new drop_driver_fence_data() can run in atomic context and might put the last fence_ctx reference. So we now only have to guard against module unload, which it seems either the driver or Rust driver-core / module unload infrastructure must solve. - Minor formatting etc. changes - Add C helpers to MAINTAINERS. (Danilo) - Ensure that `Fence::is_signaled()` is fully synchronized, i.e., all callbacks really have run. See [1] and [2]. (Myself, Christian König) Changes since the RFCs: - Include support for ForeignOwnable for ARef, so that a Fence can be stuffed into an XArray et al. (Code by Danilo) - Implement ForeignOwnable (with new borrow type) for DriverFence, so that it can be stuffed into an XArray. - Include the rcu::RcuBox data type to defer dropping data with RCU (Cody by Alice) - Port DmaFence to RcuBox to make UAF bugs through later, new dma_fence callbacks (backend_ops) impossible. - Force users to pass their fence data in an RcuBox (or have it not need drop()) through a Sealed trait. - Document the rules for the user's DriverFence::data's drop implementation very clearly (deadlock danger). - rustfmt, Clippy. - Various style suggestions, safety comments, etc. (Önur) - Add __rust_helper prefix to helper functions. (Önur) Changes in RFC v3: - Omit JobQueue patches for now - Completely redesign the memory layout: Instead of a Fence refcounting a DriverFence, both now live in the same allocation to allow for future support the dma_fence backend_ops callbacks which need to do container_of. (mostly Boris's feedback) - Allow for pre-allocating fences to avoid deadlocks when submitting jobs to a GPU. (Boris) - Simultaneously, allow for pre-preparing fence callback objects, so the driver can allocate them when it sees fit. (code largely stolen and inspired by Daniel). - Signal fences on drop, ensure synchronization. - Force users to set an error code when signalling. - Write more documentation - A ton of minor other changes. [1] https://lore.kernel.org/dri-devel/20260608142436.265820-2-phasta@kernel.org/ [2] https://lore.kernel.org/dri-devel/20260612104251.2264707-2-phasta@kernel.or… Alright, so since the last RFCs did not reveal significant design issues, I decided to transition this series to a v1 and hope that we can get it upstream. This now includes code for more common infrastructure that dma_fence needs, contributed by Danilo and Alice. --- Old cover letter for RFC: So, this is the spiritual successor of the first / second RFC [1]. v2 also contained code for drm::JobQueue, but mostly to show how the fence code would be used. JobQueue is under heavy rework right now, so I don't want to bother your eyes with it. The docstring examples should show how Rust fences are supposed to be used, though. This v3 contains a huge amount of highly valuable feedback from a variety of people, notably Boris, but also from Alice, Gary and Danilo. There are some TODOs open (a better trait for fence backend_ops and RCU support), but my hope is that this effort is now finally approaching its end. I would greatly appreciate feedback and especially more information about what might be missing to make this usable, which is obviously where Daniel's and Boris's feedback will be valuable once more. Please regard this patch just as what it's titled: an RFC, to discuss a bit more and to inform a broader community about what the current state is and where this is heading at. Many regards, Philipp [1] https://lore.kernel.org/rust-for-linux/20260203081403.68733-2-phasta@kernel… Danilo Krummrich (1): rust: types: implement ForeignOwnable for ARef<T> Philipp Stanner (4): rust: error: Add ECANCELED error code rust: sync: Add abstraction for rcu_barrier() rust: Add dma_fence abstractions MAINTAINERS: Add entry for Rust dma-buf MAINTAINERS | 5 + rust/bindings/bindings_helper.h | 1 + rust/helpers/dma_fence.c | 48 ++ rust/helpers/helpers.c | 1 + rust/kernel/dma_buf/dma_fence.rs | 894 +++++++++++++++++++++++++++++++ rust/kernel/dma_buf/mod.rs | 14 + rust/kernel/error.rs | 1 + rust/kernel/lib.rs | 1 + rust/kernel/sync/aref.rs | 40 ++ rust/kernel/sync/rcu.rs | 20 + 10 files changed, 1025 insertions(+) create mode 100644 rust/helpers/dma_fence.c create mode 100644 rust/kernel/dma_buf/dma_fence.rs create mode 100644 rust/kernel/dma_buf/mod.rs base-commit: a73a398a68ca9b9e5116a617562471f16b8310c4 -- 2.54.0

16 hours, 38 minutes

Geometry Jump 101: Rhythm, Reflexes, and the Art of Not Dying

by extensive.armadillo.wiiq＠hidepost.net

https://geometrydash-pc.com/ If you've ever tapped your foot to a beat and thought, "I bet I could time a square's mid-air landing to this," then you're ready for the world of rhythm-based platformers—specifically, the wild, colorful, and frustratingly addictive universe of Geometry Dash. At its core, it's simple: a square moves forward automatically, and you tap to jump. In practice, it's a full-body workout for your brain's timing center. Let's break down how to actually experience—and eventually enjoy—this kind of geometric jump challenge without throwing your keyboard across the room. Part One: What Even Is This? Before we talk about tricks, let's set the stage. The core experience of Geometry Dash revolves around a single action: tap to jump. The square—or spider, or ball, or UFO, or wave—moves on its own, sliding across a track filled with spikes, blocks, and gravity portals. Your job is to tap at exactly the right moment to avoid instant death. Sounds easy? It's not. But that's also the point. The beauty of this kind of gameplay—a "geometry jump" style, where everything is angles, symmetry, and sudden death—is that it strips away complexity. There's no health bar. No power-ups. No second chances. You die in one hit and restart immediately. This design forces you into a flow state: your eyes lock onto the screen, your ears lock onto the beat, and your thumb becomes a metronome. The key insight? You're not playing a platformer. You're playing a song with visual obstacles. Every spike, every jump, every gravity flip is mapped to the rhythm. If you're tapping without hearing the music, you will fail. If you're listening but not watching the trail ahead, you will also fail. True mastery happens when both senses merge. Part Two: The Gameplay Loop – Death, Respawning, and the Grind Here's what a typical round looks like for a beginner: 1. You press play. The music starts. Your square begins moving. 2. First obstacle appears. You jump over it. You feel like a god. 3. Second obstacle appears. You jump. You die. 4. You respawn instantly. 5. Repeat steps 1-4 about forty-seven times. 6. You make it past the second obstacle. 7. Third obstacle kills you. 8. You realize you've been playing for thirty minutes and have progressed exactly 2% of the level. This loop sounds miserable on paper, but in practice, it's hypnotic. The instant restart is the secret sauce. There's no loading screen, no "Game Over" animation, no time wasted. You die, you're back in under a second, and the music is still playing. This keeps your brain in a learning groove. Each death teaches your fingers something—a slightly earlier tap, a slightly shorter hold. As you play more levels, you'll encounter different game modes within the same geometry jump framework: The Cube: Basic. Tap to jump. Land on platforms. The Ship: Hold to fly up, release to drop. Think of it as a gravity-defying seesaw. The Ball: Tap to flip gravity. Stay on ceilings or floors. The UFO: Tap to do a small hop. Needs rapid, rhythmic tapping. The Wave: Hold and release to move diagonally. Pure chaos. The Spider: Tap to teleport from floor to ceiling. Each mode demands a different kind of timing, but the core rule remains: the music tells you when. The beat of the song is your guide—the spikes are almost always placed on the downbeat or the offbeat. Part Three: Tips for Surviving (and Maybe Even Enjoying) You will die. A lot. That's not a failure; that's the game working as intended. But here's how to make the experience less "angry quitting" and more "addictive progression." 1. Listen First, Watch Second Before you even try a level, just listen to the song. The best Geometry Jump levels are designed by people who choreographed obstacles to the track. If you know when the drop hits, you'll know when a tricky section is coming. Let the rhythm enter your bones. 2. Memorize, Don't React Beginners try to react to obstacles. That doesn't work. By the time you see a spike, it's too late. Instead, memorize the level in chunks. "Okay, after the blue portal, there are three jumps in quick succession, then a short gap." Play the same ten-second section over and over until your fingers move automatically. You're building muscle memory, not reflexes. 3. Use Practice Mode (Seriously) Every level has a practice mode with checkpoints. Use it. There's no shame in placing a checkpoint right before a hard section and practicing it twenty times in a row. The pros do the same thing. "Practicing" isn't cheating—it's learning. 4. Calibrate Your Offset If you feel like you're tapping exactly on the beat but still dying, check your audio/visual offset. Every setup has a tiny delay between when the game processes your tap and when you hear the sound. Adjusting this can turn an impossible level into a challenging one. 5. Take Breaks There's a phenomenon called "nervous fatigue" where, after playing for an hour, your timing gets worse, not better. Your hands shake. You tap too early. Walk away for ten minutes. Make tea. Stretch. Come back fresh. Often, the section that killed you fifty times will click on your first attempt after a break. 6. Recognize the "Flow Zone" When you hit the sweet spot, something magical happens: time slows down. Your taps become effortless. You're not thinking about the obstacles anymore—you're just dancing through them. This is the flow state. It's rare at first, but the more you practice, the easier it is to access. The key is to relax your hand. A death grip on the mouse or keyboard tenses your whole arm and messes up your timing. Breathe. 7. Don't Compare Yourself You'll see people online beating the hardest levels in minutes. Ignore them. They have thousands of hours. Your journey is your own. Celebrate small wins: making it 10% further, beating a level that took you an hour, finally nailing that one jump. Every player, even the best, started exactly where you are: dying on the first obstacle. Conclusion: The Joy of the Jump At first glance, a geometry jump game like Geometry Dash looks like a simple time-waster. A square. Some spikes. A song. How deep could it possibly be? But if you give it real time—not just ten minutes, but an afternoon, a week, a month—you'll discover something surprising. It's not about finishing the level. It's about the moment when your brain and the music and the visual pattern finally click into alignment. That fraction of a second where you're not thinking, you're just doing. That's the real reward. So open up the game, put on headphones, and let the beat guide you. Fail spectacularly. Restart instantly. And when you finally clear that one impossible section, you'll realize why people keep coming back. Because sometimes, the only way forward is a well-timed jump into the unknown.

20 hours, 38 minutes

Drive Mad unblocked

by Williamia Hight

Exploring the World of Vehicle Engineering in Drive Mad Drive Mad changes how we think about traditional racing games. You are not just pushing a gas pedal to win. You are managing the weight and the center of gravity of your machine. Every car has a different personality in this game. Some are heavy and stable while others are light and bouncy. Choosing the right vehicle for the level is your first strategic step. The levels in Drive Mad are more like mechanical puzzles than race tracks. You have to understand the triggers that move the obstacles. A platform might drop only when you reach a certain point. You must time your approach to avoid the trap. It requires you to observe the environment before you take action. This brain work makes the game much more satisfying than simple racing titles. You will encounter many moments of frustration during your progress. This is the main appeal of the game for many players. You learn from every mistake you make on the road. Eventually you find the perfect rhythm to clear the most difficult gaps. The feeling of success after a hard level is unmatched. Keep your focus sharp and your hands ready to drive. https://drivinggames.io

22 hours, 55 minutes

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig