Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

7 participants
6603 discussions

Unlocking Fun, One Block at a Time: A Dive into Block Blast

by loyal.kingfisher.ghlj＠hidingmail.net

In the vast and ever-growing world of mobile gaming, sometimes the simplest concepts deliver the most satisfying experiences. One such gem is Block Blast, a captivating puzzle game that combines the familiar mechanics of Tetris with a fresh, strategic twist. If you're looking for a relaxing yet engaging way to challenge your mind, then Block Blast might just be your next addiction. https://blockblasts.io/ What is Block Blast? Imagine a 10x10 grid, initially empty. Your goal is to fill this grid with various-shaped blocks that appear at the bottom of the screen, one set of three at a time. The catch? You can't rotate the blocks, and you must place all three given blocks before new ones appear. The objective is to clear lines and columns by filling them completely. Once a line or column is full, it disappears, freeing up space for more blocks and earning you points. The game ends when you can no longer place any of the current blocks on the grid. Gameplay: Simple to Grasp, Challenging to Master The beauty of Block Blast lies in its straightforward mechanics. You simply drag and drop the blocks from the bottom onto the grid. There's no time limit, no frantic swiping – just thoughtful placement. However, don't let the simplicity fool you. As the grid fills up, strategic thinking becomes paramount. You'll quickly learn the importance of anticipating future block shapes and planning your placements to create more clearing opportunities. Should you save that long straight piece for a full column clear, or use it now to open up a crucial corner? These are the delightful dilemmas you'll face. The game encourages a flow state, where you’re constantly evaluating and adapting to the evolving grid. Tips for Becoming a Block Blast Master While the game is easy to pick up, a few strategies can significantly boost your scores and enjoyment: Prioritize Clears: Don't be afraid to clear lines or columns, even if it means using a block in a less-than-ideal spot. Clearing space is crucial for longevity. Think Ahead: Always glance at the next set of blocks. This allows you to plan your current placements with future pieces in mind, creating combos and larger clears. Corners are King: Filling corners and edges can be tricky, so try to tackle them early when you have more space. Don't leave isolated blocks in odd spots. The "L" and "T" Block Dilemma: These oddly shaped blocks can be your best friends or worst enemies. Learn how to integrate them into your clears effectively, often by leaving gaps for them. Practice Makes Perfect: Like any puzzle game, consistent play will improve your spatial reasoning and pattern recognition, leading to higher scores. Conclusion Block Blast offers a delightful blend of relaxation and mental stimulation. Its intuitive design makes it accessible to everyone, while its strategic depth keeps players engaged for countless hours. Whether you're looking for a quick brain break or a long, meditative puzzle session, Block Blast provides a satisfying and rewarding experience. Give it a try, and you might just find your new favorite way to unwind and sharpen your mind, one block at a time.

10 minutes

Unleash Your Inner Ninja: A Guide to Slicing Success in Slice Master

by relative.rooster.miqd＠hidingmail.com

Ready to unleash your inner fruit ninja without the mess? Then get ready to dive into the addictively simple, yet surprisingly challenging world of Slice Master. This game, readily available online, is perfect for a quick burst of fun or a more extended gaming session. It’s a testament to the fact that gameplay doesn't need to be complex to be engaging. https://slicemasterfree.com Gameplay: Simple Mechanics, Endless Fun The core concept of Slice Master is refreshingly straightforward. Colorful fruits are launched into the air, and your mission is to slice them into pieces before they fall off the screen. You control a virtual blade with your mouse or finger (depending on the platform), and drawing lines through the fruit initiates the slicing action. The catch? You have limited lives, and letting too many fruits fall untouched will result in a game over. Occasionally, you'll also encounter bombs mixed in with the fruit barrage. Accidentally slicing a bomb will end your run instantly, adding a layer of strategic thinking to the rapid-fire action. As you progress, the game throws different types of fruit at you, some requiring multiple slices, and the speed increases gradually, demanding faster reflexes and more precise movements. Special fruits might offer score multipliers or other benefits, adding further depth to the gameplay. It’s a game where practice truly makes perfect, and mastering the art of fruit slicing is incredibly satisfying. You can try it out now by clicking on Slice Master. Tips for Achieving Fruit-Slicing Mastery While the game seems simple on the surface, a few strategies can significantly improve your score and extend your gameplay. • Focus on Efficiency: Instead of frantically slashing at individual fruits, try to slice multiple fruits with a single, well-aimed swipe. This not only increases your score but also conserves your limited slicing time. • Prioritize High-Value Fruits: Keep an eye out for special fruits that offer bonus points or multipliers. Slicing these at the right moment can dramatically boost your score. • Be Mindful of Bombs: This one is crucial! Always be aware of the position of the bombs and avoid them at all costs. A moment of carelessness can instantly end your game. Try to train yourself to recognize them early and plan your slices accordingly. • Practice Makes Perfect: Like any skill-based game, practice is essential for improving your reflexes and accuracy. The more you play, the better you'll become at predicting fruit trajectories and executing precise slices. So, keep practicing and you'll be reaching new high scores in no time! In Conclusion: A Slice of Addictive Fun Slice Master offers a surprisingly addictive and engaging gaming experience, despite its simple premise. Its accessible gameplay, combined with the escalating challenge, makes it a perfect choice for a quick dose of entertainment or a more extended gaming session. Whether you're looking for a casual distraction or a skill-based challenge, Slice Master provides a satisfying and fun way to test your reflexes and accuracy. So, grab your virtual blade and prepare to unleash your inner fruit-slicing ninja!

31 minutes

[PATCH v5] dma-buf: Fix silent overflow for phys vec to sgt

by David Hu

In case MMIO size is bigger than 4G and peer2peer DMA goes through host bridge, we trigger a code path that assigns the total linked IOVA (which is greater than 4G) to mapped_len. Previously, `mapped_len` was declared as 32-bit `unsigned int`. When accumulating `size_t` lengths, this leads to a silent wrap-around. This truncation causes truncated lengths to be passed to functions like `fill_sg_entry()`. Fix this by changing `mapped_len` to `size_t` (64-bit). While at it, fix similar potential overflow issues in `calc_sg_nents` by using `size_t` for `nents` and checking against `UINT_MAX` and using `unsigned int` for the loop iterator in `fill_sg_entry` to match. Fixes: 3aa31a8bb11e ("dma-buf: provide phys_vec to scatter-gather mapping routine") Cc: stable(a)vger.kernel.org Cc: iommu(a)lists.linux.dev Reviewed-by: Pranjal Shrivastava <praan(a)google.com> Signed-off-by: David Hu <xuehaohu(a)google.com> --- Changes in v5: - Removed WARN_ON_ONCE from calc_sg_nents() to avoid log noise (Jason). - Added explicit check for `!nents` in dma_buf_phys_vec_to_sgt() to cleanly return -EINVAL on overflow (Jason). Changes in v4: - Added WARN_ON_ONCE() to the nents overflow check to prevent silent failures (Claude Bot). Changes in v3: - Removed leftover sentence fragment from the commit message. - Kept `nents = 0` initialization (previously stated as removed in the v2 changelog) as it is strictly required for the `+=` accumulation loop in `calc_sg_nents()`. Changes in v2: - Fixed 'IVOA' -> 'IOVA' typo and expanded commit message (Claude Bot). - Added Reverse Xmas tree formatting (Pranjal). - Folded in extra bounds checking for calc_sg_nents() (Pranjal). - Folded in type consistency fix for fill_sg_entry() (Pranjal). drivers/dma-buf/dma-buf-mapping.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/drivers/dma-buf/dma-buf-mapping.c b/drivers/dma-buf/dma-buf-mapping.c index 794acff2546a..607b7998463d 100644 --- a/drivers/dma-buf/dma-buf-mapping.c +++ b/drivers/dma-buf/dma-buf-mapping.c @@ -10,7 +10,7 @@ static struct scatterlist *fill_sg_entry(struct scatterlist *sgl, size_t length, dma_addr_t addr) { unsigned int len, nents; - int i; + unsigned int i; nents = DIV_ROUND_UP(length, UINT_MAX); for (i = 0; i < nents; i++) { @@ -36,7 +36,7 @@ static unsigned int calc_sg_nents(struct dma_iova_state *state, struct phys_vec *phys_vec, size_t nr_ranges, size_t size) { - unsigned int nents = 0; + size_t nents = 0; size_t i; if (!state || !dma_use_iova(state)) { @@ -51,6 +51,9 @@ static unsigned int calc_sg_nents(struct dma_iova_state *state, nents = DIV_ROUND_UP(size, UINT_MAX); } + if (nents > UINT_MAX) + return 0; + return nents; } @@ -95,9 +98,10 @@ struct sg_table *dma_buf_phys_vec_to_sgt(struct dma_buf_attachment *attach, size_t nr_ranges, size_t size, enum dma_data_direction dir) { - unsigned int nents, mapped_len = 0; struct dma_buf_dma *dma; struct scatterlist *sgl; + size_t mapped_len = 0; + unsigned int nents; dma_addr_t addr; size_t i; int ret; @@ -133,6 +137,11 @@ struct sg_table *dma_buf_phys_vec_to_sgt(struct dma_buf_attachment *attach, } nents = calc_sg_nents(dma->state, phys_vec, nr_ranges, size); + if (!nents) { + ret = -EINVAL; + goto err_free_state; + } + ret = sg_alloc_table(&dma->sgt, nents, GFP_KERNEL | __GFP_ZERO); if (ret) goto err_free_state; -- 2.54.0.929.g9b7fa37559-goog

6 hours, 42 minutes

[PATCH v4] dma-buf: Fix silent overflow for phys vec to sgt

by David Hu

In case MMIO size is bigger than 4G and peer2peer DMA goes through host bridge, we trigger a code path that assigns the total linked IOVA (which is greater than 4G) to mapped_len. Previously, `mapped_len` was declared as 32-bit `unsigned int`. When accumulating `size_t` lengths, this leads to a silent wrap-around. This truncation causes truncated lengths to be passed to functions like `fill_sg_entry()`. Fix this by changing `mapped_len` to `size_t` (64-bit). While at it, fix similar potential overflow issues in `calc_sg_nents` by using `size_t` for `nents` and checking against `UINT_MAX` and using `unsigned int` for the loop iterator in `fill_sg_entry` to match. Fixes: 3aa31a8bb11e ("dma-buf: provide phys_vec to scatter-gather mapping routine") Cc: stable(a)vger.kernel.org Cc: iommu(a)lists.linux.dev Reviewed-by: Pranjal Shrivastava <praan(a)google.com> Signed-off-by: David Hu <xuehaohu(a)google.com> --- Changes in v4: - Added WARN_ON_ONCE() to the nents overflow check to prevent silent failures (Claude Bot). Changes in v3: - Removed leftover sentence fragment from the commit message. - Kept `nents = 0` initialization (previously stated as removed in the v2 changelog) as it is strictly required for the `+=` accumulation loop in `calc_sg_nents()`. Changes in v2: - Fixed 'IVOA' -> 'IOVA' typo and expanded commit message (Claude Bot). - Added Reverse Xmas tree formatting (Pranjal). - Folded in extra bounds checking for calc_sg_nents() (Pranjal). - Folded in type consistency fix for fill_sg_entry() (Pranjal). drivers/dma-buf/dma-buf-mapping.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/dma-buf/dma-buf-mapping.c b/drivers/dma-buf/dma-buf-mapping.c index 794acff2546a..1aabc0ee70bb 100644 --- a/drivers/dma-buf/dma-buf-mapping.c +++ b/drivers/dma-buf/dma-buf-mapping.c @@ -10,7 +10,7 @@ static struct scatterlist *fill_sg_entry(struct scatterlist *sgl, size_t length, dma_addr_t addr) { unsigned int len, nents; - int i; + unsigned int i; nents = DIV_ROUND_UP(length, UINT_MAX); for (i = 0; i < nents; i++) { @@ -36,7 +36,7 @@ static unsigned int calc_sg_nents(struct dma_iova_state *state, struct phys_vec *phys_vec, size_t nr_ranges, size_t size) { - unsigned int nents = 0; + size_t nents = 0; size_t i; if (!state || !dma_use_iova(state)) { @@ -51,6 +51,9 @@ static unsigned int calc_sg_nents(struct dma_iova_state *state, nents = DIV_ROUND_UP(size, UINT_MAX); } + if (WARN_ON_ONCE(nents > UINT_MAX)) + return 0; + return nents; } @@ -95,9 +98,10 @@ struct sg_table *dma_buf_phys_vec_to_sgt(struct dma_buf_attachment *attach, size_t nr_ranges, size_t size, enum dma_data_direction dir) { - unsigned int nents, mapped_len = 0; struct dma_buf_dma *dma; struct scatterlist *sgl; + size_t mapped_len = 0; + unsigned int nents; dma_addr_t addr; size_t i; int ret; -- 2.54.0.929.g9b7fa37559-goog

7 hours, 16 minutes

Re: [PATCH 3/4] rust: Add dma_fence abstractions

by Boris Brezillon

On Mon, 1 Jun 2026 10:36:06 +0000 Alice Ryhl <aliceryhl(a)google.com> wrote: > > +pub trait FenceCtxOps {} > > This empty trait is unused. > > > +/// A dma-fence context. A fence context takes care of associating related fences with each other, > > +/// providing each with raising sequence numbers and a common identifier. > > +#[pin_data(PinnedDrop)] > > +pub struct FenceCtx<F: Send + Sync, C: Send + Sync> { BTW, if you define a FenceCtxOps trait, this should be: pub struct FenceCtx<F: Send + Sync, C: FenceCtxOps + Send + Sync> {

14 hours, 5 minutes

Re: [PATCH 3/4] rust: Add dma_fence abstractions

by Boris Brezillon

On Mon, 01 Jun 2026 13:17:27 +0200 Philipp Stanner <phasta(a)mailbox.org> wrote: > On Mon, 2026-06-01 at 12:59 +0200, Boris Brezillon wrote: > > On Mon, 1 Jun 2026 10:36:06 +0000 > > Alice Ryhl <aliceryhl(a)google.com> wrote: > > > > > > +}; > > > > + > > > > +use bindings::ECANCELED; > > > > + > > > > +use kernel::str::CString; > > > > +use kernel::sync::{ > > > > + aref::{ > > > > + ARef, > > > > + AlwaysRefCounted, // > > > > + }, > > > > + Arc, > > > > + ArcBorrow, // > > > > +}; > > > > + > > > > +/// VTable for dma_fence backend_ops callbacks. > > > > +// > > > > +// Mandatory dma_fence backend_ops are implemented implicitly through > > > > +// [`FenceCtx`]. Additional ones shall get implemented on this trait, which then > > > > +// shall be demanded for the fence context data. > > > > +pub trait FenceCtxOps {} > > > > > > This empty trait is unused. > > > > I had initially suggested to add the F type (AKA FenceData) passed > > around in multiple places type as an associated type > > > > pub trait FenceCtxOps { > > type FenceData: Send + Sync; > > } > > > > so we don't have to pass both F and C. The reasoning here is that: > > > > 1. We expect we'll have to define more methods to the FenceCtxOps trait > > at some point, so adding it now kinda makes sense. > > > > 2. In the current design, we've assumed that a Fence can't live/be > > created outside of a given context, so there's no world where the > > FenceData wouldn't be known by the FenceCtx implementation, and forcing > > users to pass F and C around seems needlessly verbose. > > I had investigated that, but found that this causes us to write things > like > > DriverFence<T> (where T is the FencCtx generic) > > and then in the actual implementation use > > T::FenceData > > which reads very weird IMO. Because now for reasons a fence's own data > are not referred to in its own implementation, but you derive it from > the context. Well, I actually think that's a good thing, because DriverFence and FenceCtx are tightly related: FenceCtx<F, C> instantiates and manages DriverFence<F, C> fences, and DriverFenceData<F, C> has an Arc to a FenceCtx<F, C>. > > I do prefer it in a way where the DriverFence generic does appear in > said fence's actual code, on equal rank with the FenceCtx. Question is, can you really have random <F, C> combination or is C dictating which F you'll get attached to the DriverFence? If a given context can't handle more than one type of fence, I don't really see the point of passing both around when one could be directly derived from the other, and since the trait we consider defining for the future is on the FenceCtx (FenceCtxOps), it makes sense to have FenceData defined as an associated type of FenceCtx. > > I suppose that is actually one use case for which PhantomData does > exist. Yeah, I don't, it just feels weird to pass both around, and it doesn't seem to match what we've been doing in other places (drm::Driver, drm::Object, ...).

14 hours, 7 minutes

Re: [PATCH 3/4] rust: Add dma_fence abstractions

by Boris Brezillon

On Mon, 1 Jun 2026 10:36:06 +0000 Alice Ryhl <aliceryhl(a)google.com> wrote: > > +}; > > + > > +use bindings::ECANCELED; > > + > > +use kernel::str::CString; > > +use kernel::sync::{ > > + aref::{ > > + ARef, > > + AlwaysRefCounted, // > > + }, > > + Arc, > > + ArcBorrow, // > > +}; > > + > > +/// VTable for dma_fence backend_ops callbacks. > > +// > > +// Mandatory dma_fence backend_ops are implemented implicitly through > > +// [`FenceCtx`]. Additional ones shall get implemented on this trait, which then > > +// shall be demanded for the fence context data. > > +pub trait FenceCtxOps {} > > This empty trait is unused. I had initially suggested to add the F type (AKA FenceData) passed around in multiple places type as an associated type pub trait FenceCtxOps { type FenceData: Send + Sync; } so we don't have to pass both F and C. The reasoning here is that: 1. We expect we'll have to define more methods to the FenceCtxOps trait at some point, so adding it now kinda makes sense. 2. In the current design, we've assumed that a Fence can't live/be created outside of a given context, so there's no world where the FenceData wouldn't be known by the FenceCtx implementation, and forcing users to pass F and C around seems needlessly verbose.

15 hours, 43 minutes

[PATCH v3] dma-fence: Clarify external lock use case in dma_fence_init() docs

by Maíra Canal

The kerneldoc comment on dma_fence_init() and dma_fence_init64() describe the legacy reason to pass an external lock as a need to prevent multiple fences "from signaling out of order". However, this wording is a bit misleading: a shared spinlock does not (and cannot) prevent the signaler from signaling out of order. Signaling order is the driver's responsibility regardless of whether the lock is shared or per-fence. Reword both comments to better describe the legacy use cases where a shared lock was needed. Signed-off-by: Maíra Canal <mcanal(a)igalia.com> --- v1 -> v2: https://lore.kernel.org/dri-devel/20260411185756.1887119-4-mcanal@igalia.co… - Be more explicit about not allowing new users to use an external lock. - De-duplicate the explanation in dma_fence_init64() by pointing to the dma_fence_init() documentation. v2 -> v3: https://lore.kernel.org/dri-devel/20260419134943.54833-2-mcanal@igalia.com/… - Apply Christian's suggestion with small readability improvements. --- drivers/dma-buf/dma-fence.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index b3bfa6943a8e..c7ea1e75d38a 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -1102,9 +1102,12 @@ __dma_fence_init(struct dma_fence *fence, const struct dma_fence_ops *ops, * context and seqno are used for easy comparison between fences, allowing * to check which fence is later by simply using dma_fence_later(). * - * It is strongly discouraged to provide an external lock because this couples - * lock and fence life time. This is only allowed for legacy use cases when - * multiple fences need to be prevented from signaling out of order. + * External locks are a relic of legacy use cases that needed a shared lock + * to serialize signaling when no out-of-order signaling was possible through + * &dma_fence_ops.signaled. Drivers have abandoned this concept since the + * introduction of the callback, but the external lock is still around. New + * users MUST NOT use external locks, as they force the issuer to outlive all + * fences that reference the lock. */ void dma_fence_init(struct dma_fence *fence, const struct dma_fence_ops *ops, @@ -1129,9 +1132,8 @@ EXPORT_SYMBOL(dma_fence_init); * Context and seqno are used for easy comparison between fences, allowing * to check which fence is later by simply using dma_fence_later(). * - * It is strongly discouraged to provide an external lock because this couples - * lock and fence life time. This is only allowed for legacy use cases when - * multiple fences need to be prevented from signaling out of order. + * New users MUST NOT use external locks. Check the documentation in + * dma_fence_init() to understand the motives behind the legacy use cases. */ void dma_fence_init64(struct dma_fence *fence, const struct dma_fence_ops *ops, -- 2.54.0

18 hours, 18 minutes

Skaffa polskt körkort

by lopezolivert1＠gmail.com

1 day, 18 hours

Acheter une carte d'identité polonaise

by lopezolivert1＠gmail.com

1 day, 18 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig