On Wed, 2026-07-22 at 18:38 +0000, Timur Tabi wrote:
> On Wed, 2026-07-22 at 16:49 +0200, Philipp Stanner wrote:
> > The Rust dma_fence abstractions need the ECANCELED error code.
> >
> > Add ECANCELED error code.
> >
> > Signed-off-by: Philipp Stanner <phasta(a)kernel.org>
> > Tested-by: Daniel Almeida <daniel.almeida(a)collabora.com>
>
> No need for this, all remaining codes are being added via
>
> https://lore.kernel.org/rust-for-linux/20260629183022.2709524-1-ttabi@nvidi…
>
> Please pick up that patch instead.
Ok, pulled it in my local branch for now, thx for the heads-up.
I see that your patch is from June. If it lands in drm-rust-next
soonish I'd simply rebase.
Regards
P.
On Wed, Jul 22, 2026 at 11:39:32PM +0000, dhu(a)x6u.co wrote:
> From: David Hu <xuehaohu(a)google.com>
>
> Currently, `fill_sg_entry()` splits the scatterlist using `UINT_MAX`.
> This creates a non-page-aligned DMA length (`0xFFFFFFFF`) for the
> first entry, resulting in non-page-aligned DMA addresses for all
> subsequent entries.
>
> While the underlying IOMMU mapping may be contiguous, hardware
> DMA engines often require explicit address alignment (e.g., page,
> cacheline, or storage sector boundaries). Passing unaligned
> addresses and lengths can cause explicit failures in DMA descriptor
> creation or silent data corruption if lower unaligned bits are
> truncated.
>
> In addition, a non-page-aligned sgl length will trigger an edge case
> in `ib_umem_find_best_pgsz()`. In case of a discontinuity in later
> buffers, we will have a `va` with lowest bit set to 1. That will lead
> to `ib_umem_find_best_pgsz()` always return 0, and break the promise
> to find best page size for the mapping on the NIC side.
>
> Fix this by splitting the scatterlist by the largest possible page
> aligned chunk within `UINT_MAX` (`ALIGN_DOWN(UINT_MAX, PAGE_SIZE)`).
> This ensures all scatterlist DMA addresses and lengths remain page
> aligned, while minimizing the total number of sgl entries.
>
> Page-aligned entries allow the system to cleanly chunk payloads into
> PCIe MaxPayloadSize (MPS) (e.g., 128 bytes, 256 bytes, 512 bytes).
> As a result, this may help reduce TLP fragmentation in P2P transfers
> and alleviate potential congestion within a logical PCIe switch
> partition, especially when Relaxed Ordering is not possible due to
> hardware constraints.
>
> Reported-by: sashiko-bot <sashiko-bot(a)kernel.org>
> Closes: https://lore.kernel.org/all/20260609165431.778061F00893@smtp.kernel.org/
> Fixes: 3aa31a8bb11e ("dma-buf: provide phys_vec to scatter-gather mapping routine")
> Cc: stable(a)vger.kernel.org
> Signed-off-by: David Hu <xuehaohu(a)google.com>
> ---
> Changes in v3:
> - Removed the type cast for `min` (David Laight)
> - Reverted max ent size to be `ALIGN_DOWN(UINT_MAX, PAGE_SIZE)` and
> updated commit message to reflect that (Jason Gunthorpe)
> - Updated commit message to reflect that this also fixes an edge case
> in `ib_umem_find_best_pgsz()`
>
> Changes in v2:
> - Updated commit title and message to reflect the switch to 2G chunks
> - Switch to using 2G as the max sg entry size as it naturally aligns
> with most hardware boundaries, while allowing compiler optimizations
> with bit shifts (David Laight)
> - Optimized away division calculation for `nent`, and multiplication
> calculation for sgl address, by dropping the `for` loop in favor of a
> `while (length)` loop (David Laight)
> - Dropped `min_t` in favor of `min()` to maintain a strict type
> checking safety net (David Laight)
>
> drivers/dma-buf/dma-buf-mapping.c | 19 +++++++++++--------
> 1 file changed, 11 insertions(+), 8 deletions(-)
Could you please avoid sending patches as replies? It severely disrupts
the reading flow when using mutt's threaded view.
Regarding the patch,
Reviewed-by: Leon Romanovsky <leonro(a)nvidia.com>
Thanks
Hi,
On Mon, Oct 23, 2023 at 10:25:50AM -0700, Doug Anderson wrote:
> On Mon, Oct 23, 2023 at 9:31 AM Yuran Pereira <yuran.pereira(a)hotmail.com> wrote:
> >
> > Since "Clean up checks for already prepared/enabled in panels" has
> > already been done and merged [1], I think there is no longer a need
> > for this item to be in the gpu TODO.
> >
> > [1] https://patchwork.freedesktop.org/patch/551421/
> >
> > Signed-off-by: Yuran Pereira <yuran.pereira(a)hotmail.com>
> > ---
> > Documentation/gpu/todo.rst | 25 -------------------------
> > 1 file changed, 25 deletions(-)
>
> It's not actually all done. It's in a bit of a limbo state right now,
> unfortunately. I landed all of the "simple" cases where panels were
> needlessly tracking prepare/enable, but the less simple cases are
> still outstanding.
>
> Specifically the issue is that many panels have code to properly power
> cycle themselves off at shutdown time and in order to do that they
> need to keep track of the prepare/enable state. After a big, long
> discussion [1] it was decided that we could get rid of all the panel
> code handling shutdown if only all relevant DRM KMS drivers would
> properly call drm_atomic_helper_shutdown().
>
> I made an attempt to get DRM KMS drivers to call
> drm_atomic_helper_shutdown() [2] [3] [4]. I was able to land the
> patches that went through drm-misc, but currently many of the
> non-drm-misc ones are blocked waiting for attention.
>
> ...so things that could be done to help out:
>
> a) Could review patches that haven't landed in [4]. Maybe adding a
> Reviewed-by tag would help wake up maintainers?
>
> b) Could see if you can identify panels that are exclusively used w/
> DRM drivers that have already been converted and then we could post
> patches for just those panels. I have no idea how easy this task would
> be. Is it enough to look at upstream dts files by "compatible" string?
I think it is, yes.
Maxime
https://monkeymartfree.com
If you are looking for a lighthearted way to unwind after a long day, management simulators are often the perfect prescription. Among the sea of complex strategy games, one title stands out for its charming simplicity and addictive loop: Monkey Mart. This vibrant, browser-based game puts you in the paws of an ambitious primate entrepreneur looking to build the most successful grocery empire in the jungle.
Here is a guide on how to experience this delightful game and make your supermarket the talk of the animal kingdom.
What is Monkey Mart?
Monkey Mart is a "casual idle" management game where you control a hard-working monkey who has just opened a fresh produce market. The game combines the satisfaction of a business sim with the smooth movement of an arcade game. Unlike heavy-duty simulators that require tracking complex spreadsheets, this game focuses on the physical flow of goods—planting, harvesting, stocking, and cashing out happy customers.
How to Play: The Daily Grind
The gameplay loop is intuitive and satisfying. You start with a single plot of land where you grow bananas. As the player, you move your monkey around to harvest the fruit and carry it to the display stands. Once the shelves are stocked, fellow animals—from chickens to cows—will wander in to fill their baskets.
As you collect money from the cash register, you can unlock new features:
1. Expansion: Use your profits to open new stalls for corn, eggs, milk, and even baked goods.
2. Hiring Staff: Eventually, the store gets too big for one monkey. You can hire assistants to restock shelves or cashiers to handle the long lines.
3. Processing: Later in the game, you aren't just selling raw fruit. You’ll invest in machines to turn flour and chocolate into delicious cookies or milk into cheese.
Tips for Success
To turn your small stand into a bustling mega-mart, keep these strategies in mind:
Prioritize the Register: Customers will wait for items to be stocked, but they get impatient at the checkout. Always make sure the register is clear so the cash keeps flowing.
Invest in Speed: In the early game, use your coins to upgrade your monkey’s movement speed and carrying capacity. The more you can carry at once, the less time you spend backtracking.
Balance Your Staff: Don’t just hire everyone at once. Observe where the bottleneck is. If the shelves are empty, hire a restocker. If the line is out the door, upgrade your cashier.
Keep Your Staff Awake: Your AI helpers occasionally take naps! Make sure to walk over to them to wake them up and keep the productivity high.
Why It’s Worth Your Time
The beauty of playing Monkey Mart lies in its visual feedback. Watching the shelves fill up and seeing the "money pop" when you finish a transaction provides a steady stream of "mini-wins" that make the experience incredibly relaxing. The art style is colorful and cute, making it a great choice for players of all ages.
Conclusion
Monkey Mart proves that a game doesn’t need a dark storyline or high-end graphics to be deeply engaging. It is a game about growth, efficiency, and the simple joy of building something from the ground up. Whether you have five minutes between tasks or an hour to kill on a weekend, stepping into the role of a jungle manager is a fantastic way to spend your time. Give it a try—your customers are waiting!
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 `check_add_overflow()` for `nents` 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>
Reviewed-by: Kevin Tian <kevin.tian(a)intel.com>
Reviewed-by: Leon Romanovsky <leon(a)kernel.org>
Signed-off-by: David Hu <xuehaohu(a)google.com>
---
Changes in v7:
- Added a missing blank line after local variable declaration in
`calc_sg_nents()` (Leon).
- Collected Reviewed-by from Leon Romanovsky.
Changes in v6:
- Used `check_add_overflow()` in `calc_sg_nents()` for safer
accumulation (Leon).
- Dropped explicit `!nents` check and added a comment noting that
`sg_alloc_table` handles `nents == 0` (Leon).
- Collected Reviewed-by from Kevin Tian.
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).
- Collected Reviewed-by from Pranjal Shrivastava.
drivers/dma-buf/dma-buf-mapping.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/dma-buf/dma-buf-mapping.c b/drivers/dma-buf/dma-buf-mapping.c
index 794acff2546a..80f6ab2f4809 100644
--- a/drivers/dma-buf/dma-buf-mapping.c
+++ b/drivers/dma-buf/dma-buf-mapping.c
@@ -5,12 +5,13 @@
*/
#include <linux/dma-buf-mapping.h>
#include <linux/dma-resv.h>
+#include <linux/overflow.h>
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++) {
@@ -40,8 +41,12 @@ static unsigned int calc_sg_nents(struct dma_iova_state *state,
size_t i;
if (!state || !dma_use_iova(state)) {
- for (i = 0; i < nr_ranges; i++)
- nents += DIV_ROUND_UP(phys_vec[i].len, UINT_MAX);
+ for (i = 0; i < nr_ranges; i++) {
+ unsigned int added = DIV_ROUND_UP(phys_vec[i].len, UINT_MAX);
+
+ if (check_add_overflow(nents, added, &nents))
+ return 0;
+ }
} else {
/*
* In IOVA case, there is only one SG entry which spans
@@ -95,9 +100,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 +139,8 @@ 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);
+
+ /* sg_alloc_table will cleanly fail and return -EINVAL if nents == 0 */
ret = sg_alloc_table(&dma->sgt, nents, GFP_KERNEL | __GFP_ZERO);
if (ret)
goto err_free_state;
--
2.54.0.1064.gd145956f57-goog
Hi Robert,
> Subject: [PATCH v1] dma-buf/udmabuf: Disable the size limit by default
>
> As udmabuf increasingly enjoys popularity - being used in projects like
> libcamera, Gstreamer, Mesa, KWin and Weston - users more frequently
> encounter cases where the current default size limit of 64MB is too low.
> Examples include allocating video buffers at a 8K resolution - and even 4K
> is affected when using non-subsampled video formats and high bit depths.
>
> In its current form the size limit for individual buffers does not seem to
> provide any additional level of protection - such as limiting the amount of
> memory a process can pin - as the later can just allocate multiple buffers.
> If additional guardrails are desired, they would likely require some kind
> accounting not limited to individual buffers.
>
> Therefor let's disable the size limit by default. Use the special value
> of zero to do so, which prevously could be used to effectively disable the
> interface. Using other means, such as file permissions, appears to be a
> much better fit for that purpose.
>
> Signed-off-by: Robert Mader <robert.mader(a)collabora.com>
>
> ---
>
> Please let me know if changing the meaning of the parameter value of zero
> is considered a breaking change / not acceptable. In that case INT_MAX
> might be a better option.
Yeah, I think using INT_MAX might be better.
Thanks,
Vivek
>
> See
> https://lore.kernel.org/dri-devel/20260711144814.8205-1-
> robert.mader(a)collabora.com/
> for a previous attempt to make the value configurable via kconfig - and
> in particular
> https://lore.kernel.org/dri-devel/6764ca6f-b4d8-4baa-9d27-
> 2ca867ac2d41(a)amd.com/
> for the suggestion and discussion to remove the default limit.
> ---
> drivers/dma-buf/udmabuf.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
> index bced421c0d65..3509b690d8e2 100644
> --- a/drivers/dma-buf/udmabuf.c
> +++ b/drivers/dma-buf/udmabuf.c
> @@ -20,9 +20,9 @@ static int list_limit = 1024;
> module_param(list_limit, int, 0644);
> MODULE_PARM_DESC(list_limit, "udmabuf_create_list->count limit.
> Default is 1024.");
>
> -static int size_limit_mb = 64;
> +static int size_limit_mb = 0;
> module_param(size_limit_mb, int, 0644);
> -MODULE_PARM_DESC(size_limit_mb, "Max size of a dmabuf, in
> megabytes. Default is 64.");
> +MODULE_PARM_DESC(size_limit_mb, "Max size of a dmabuf, in
> megabytes. Setting 0 disables the limit. Default is 0.");
>
> struct udmabuf {
> pgoff_t pagecount;
> @@ -373,7 +373,7 @@ static long udmabuf_create(struct miscdevice
> *device,
>
> subpgcnt = list[i].size >> PAGE_SHIFT;
> pgcnt += subpgcnt;
> - if (pgcnt > pglimit)
> + if (pglimit && pglimit < pgcnt)
> goto err_noinit;
>
> max_nr_folios = max_t(unsigned long, subpgcnt,
> max_nr_folios);
> --
> 2.55.0
I've been looking into Japanese estate cars recently, and it seems that a few excellent models never get the recognition they deserve. Everyone talks about the usual choices, but there are several practical, reliable wagons that offer great value without attracting much attention.
One thing I appreciate about Japanese estate cars is their balance of comfort, fuel efficiency, and long-term dependability. Whether you're carrying family, luggage, or work equipment, they often provide more space than many people expect.
Some underrated options that deserve a closer look include:
* Toyota Caldina for its reliability and versatile design.
* Nissan Stagea, especially for drivers who enjoy a more performance-oriented estate.
* Subaru Legacy Touring Wagon with its excellent all-wheel-drive capability.
* Honda Accord Wagon, which combines comfort with dependable engineering.
While researching different models, I also noticed that experienced **Japanese used car dealers** often recommend checking the vehicle's maintenance history, auction grade, and export documentation before making a purchase. Those factors usually matter more than simply choosing the most popular model.
I came across some useful information about Japanese vehicle sourcing while browsing https://nobukojapan.com, particularly regarding the import process and how vehicles are selected before export. It helped me better understand what to look for when comparing different estate cars.
I'm curious to hear from people who have actually owned one of these wagons. Which Japanese estate car do you think is the most underrated, and why? Are there any hidden gems that deserve more attention but rarely get mentioned?