Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

35 participants
7097 discussions

Letting Off Steam: A Guide to the Delightful Chaos of Kick the Buddy

by jolly.hornet.qnrq＠hidepost.net

Life, as they say, throws a lot at us. From demanding deadlines to unexpected annoyances, it’s easy to feel the pressure build. Sometimes, what we need isn’t a complex strategy game or a deeply engrossing narrative; it’s just a simple, satisfying outlet for that pent-up energy. And that’s where games like kick the buddy come in – a delightfully straightforward experience designed for pure, unadulterated stress relief. https://kickthebuddy.lol/ "Kick the Buddy" isn't about high scores or intricate mechanics; it's about embracing a bit of playful destruction. Imagine a virtual ragdoll, a friendly, if somewhat resilient, dummy named Buddy, who patiently awaits your creative (and often absurd) methods of interaction. It’s a game that understands the primal satisfaction of knocking things around, even if those things are digital. The Art of Playful Punishment: Understanding the Gameplay Loop At its core, "Kick the Buddy" is incredibly simple. You are presented with Buddy, a cheerful, often bandaged character, suspended in a room. Your objective? To unleash a wide array of tools and weapons upon him. The beauty lies in the sheer variety and the freedom to experiment. Upon launching the game, you'll be greeted by Buddy and a UI that, while initially packed with icons, quickly becomes intuitive. Along the bottom or sides of the screen, you'll find categories of weapons: explosives, firearms, sharp objects, heavy objects, and even more bizarre options like elemental powers or exotic creatures. Tapping on a category reveals a carousel of specific items. Want to toss a grenade? Select the explosives category, then pick your boom-maker. Prefer to pepper Buddy with bullets? Head to firearms and choose your weapon of choice, be it a pistol, an assault rifle, or even a mini-gun. The interaction is purely touch-based. Drag your chosen weapon onto Buddy, and it will interact with him in its intended way. Firearms will shoot, bombs will explode, and melee weapons will, well, kick and punch. Buddy reacts to every impact with comical animations and sound effects, his limbs flailing and his body bouncing around the environment. There's no "game over" screen, no health bar to meticulously manage for Buddy (though he does take on more damage and visual wear and tear). The goal isn't to defeat him in a traditional sense, but to simply engage in the cathartic act of unleashing digital mayhem. Beyond the basic weaponry, the game often features special environmental hazards or interactive elements. Perhaps a giant fan you can activate to send Buddy swirling, or a portal that teleports him across the room. These elements add another layer of playful chaos, encouraging you to think creatively about how to maximize Buddy's suffering (in the most lighthearted way possible). What truly sets games like this apart is the sheer variety of tools at your disposal. From conventional firearms like pistols and shotguns to the wonderfully absurd, like a black hole gun that sucks Buddy into oblivion or a rubber duck that somehow inflicts comical damage, the developers clearly revel in imagination. This constant influx of new, often ridiculous, ways to interact with Buddy keeps the experience fresh and encourages repeated play sessions. Beyond the Bang: Tips for Optimal Stress Relief While the game is wonderfully straightforward, a few tips can enhance your stress-busting experience: Embrace the Absurd: Don't limit yourself to conventional weapons. Some of the most satisfying interactions come from the most outlandish items. Experiment with everything – you might be surprised by the sheer hilarity of a giant rubber band or a flock of angry birds. Combine and Conquer: Many weapons have interesting synergies. Try freezing Buddy with an ice gun, then shattering him with a heavy object. Or pepper him with bullets before dropping an explosive on him. The more creative your combinations, the more entertaining the outcome. Sound On, Volume Up: A significant part of the game's charm comes from its sound design. Buddy's comical yelps, the satisfying thwacks of impact, and the explosive roars all contribute to the overall catharsis. Don't be afraid to crank up the volume and fully immerse yourself in the chaotic symphony. Short Bursts are Key: "Kick the Buddy" isn't designed for marathon sessions. Its strength lies in its ability to provide quick, satisfying bursts of stress relief. When you feel a bit overwhelmed or just need a mental break, a few minutes of playful destruction can do wonders. No Right or Wrong Way: There's no leaderboard, no competitive element. The only "goal" is your own enjoyment. Feel free to be as chaotic or as precise as you wish. It’s your sandbox, and Buddy is your patient (and perpetually recovering) subject. A Concluding Whack In a world often filled with complexity, the simplicity and pure, unadulterated fun of "Kick the Buddy" is a refreshing antidote. It's a game that doesn't demand much from you, except a willingness to let go and embrace a bit of lighthearted destruction. So the next time you feel the need to let off some steam, consider giving Buddy a good kicking (or exploding, or freezing, or zapping). You might just find it to be the most satisfying stress reliever you never knew you needed.

3 hours, 19 minutes

Re: [PATCH v4 02/10] PCI/P2PDMA: Add CONFIG_PCI_P2PDMA_CORE

by Matt Evans

Hi Logan, On 02/07/2026 21:34, Logan Gunthorpe wrote: > > > On 2026-07-02 10:44 a.m., Matt Evans wrote: >>> So maybe at this point it's fine to enable this on 32bit systems and we >>> can remove this requirement. However, I think we should do that >>> explicitly in its own patch, not hide it in this refactoring patch. >> >> Your question does prove it's too stealthy as-is. :) PCI_P2PDMA still >> can't be enabled on 32-bit systems because of its ZONE_DEVICE -> >> MEMORY_HOTPLUG -> 64BIT dependency. So we're not enabling 32-bit >> support for PCI_P2PDMA here, but it's not obvious and so I'll re-add the >> `depends on 64BIT`. At least then it won't be enabled without intention >> if someone enables ZONE_DEVICE on 32-bit systems... > > Ok, that all makes sense to me. I would be good with removing the 64BIT > dependency (as it is is a bit confusing as is) but I think adding > another patch would be appropriate with some of the commit message notes > you mentioned in your emails. > > Besides that, I think you can add to this patch: > > Reviewed-by: Logan Gunthorpe <logang(a)deltatee.com> Thanks for that. On second reading, just want to check with you: I'm intending to repost _retaining_ the 64BIT dependency (i.e. revert its removal) for simplicity's sake. Then we can follow up separatey (outside this series) with a cleanup patch to remove 64BIT, explain, examine other dependencies etc. as you suggest. Works for you? (I want to reduce the diff in this series, and revert since this isn't truly necessary && wasn't entirely obvious.) Cheers, Matt

12 hours, 39 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, 16 minutes

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

20 hours, 55 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 day

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 >

1 day, 5 hours

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

1 day, 7 hours

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.

1 day, 8 hours

IRS: Refund Status Update

by IRS.GOV

1 day, 10 hours

[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

1 day, 15 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig