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!
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
The reason for this is to properly support the spi nor chip on the
Jetson Xavier NX module. Prior to this, it would time out on all
transfers and sometimes even trigger a cbb fault, locking up the entire
unit. With this, reading and writing to the flash memory works as
expected.
This also fixes the tegra210-quad spi driver to properly use the dma
memory space instead of the spi controllers. Without this, enabling dma
on the controllers results in mmu faults.
The driver change has only been tested on tegra210 / p3450 and tegra194
/ p3518 as that is the only available test platforms. Tegra234 and
Tegra241 should also be verified. I have p3766 for tegra234, but the
qspi flash memory is firewalled by mb1 on all publicly available
bootloaders, and no other spi devices are part of the devkit.
---
Changes in v2:
- Drop bindings patches
- Add patch to use dma memory space instead of the spi controllers when
dma is enabled.
- Drop iommu properties from final patch
- Link to v1: https://lore.kernel.org/r/20260515-tegra194-qspi-iommu-v1-0-57dfb63cd3d6@gm…
---
Aaron Kling (2):
spi: tegra210-quad: Allocate DMA memory for DMA engine
arm64: tegra: Enable DMA Support on Tegra194 QSPI
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 4 ++++
drivers/spi/spi-tegra210-quad.c | 29 ++++++++++++++++++-----------
2 files changed, 22 insertions(+), 11 deletions(-)
---
base-commit: c1ecb239fa3456529a32255359fc78b69eb9d847
change-id: 20260515-tegra194-qspi-iommu-e4e4644d5fdf
Best regards,
--
Aaron Kling <webgeek1234(a)gmail.com>
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