On Tue, Sep 08, 2026 at 09:15:45PM +0800, Li Wang wrote:
> From: Mengmeng Zhao <zhaomengmeng(a)kylinos.cn>
>
> Inspired by the paper published in SC'25 [1], we implemented a character
> device named fgds that provides two ioctl interfaces:
> `REG_BUFFER/UNREG_BUFFER`. It enables applications to perform direct I/O
> between GPU memory and NVMe via POSIX and io_uring APIs. This is
> particularly useful for LLM workloads, such as model loading, KV cache
> offloading, and checkpointing. The fgds device corresponds one-to-one with
> the PCIe GPU on the machine. The usage is straightforward: an application
> simply opens the corresponding fgds device, calls ioctl on the returned fd
> with REG_BUFFER, taking the target GPU memory buffer address (represented
> as a dma-buf fd), and the buffer length as inputs, and then invokes mmap on
> the fgds device fd, using the return value of ioctl as the input. The mmap
> call returns a CPU virtual address (call it cpu_vaddr). Afterward,
> cpu_vaddr can be passed directly to pread/pwrite, or
> io_uring_prep_read/io_uring_prep_write to perform direct I/O between files
> on NVMe and GPU memory. A minimal working example can be found in [2].
> The underlying mechanism is that, with the support of fgds device,
> cpu_vaddr is made to point directly to the GPU memory buffer corresponding
> to the dma-buf fd. This solution is loosely coupled with the GPU vendor's
> driver; the GPU vendor only needs to support exporting the allocated GPU
> memory buffer through the standard Linux kernel dma-buf framework, which
> the vast majority of mainstream GPUs already support. This allows both
> applications and the fgds device to work seamlessly with GPUs from
> different vendors without any modifications. Furthermore, applications no
> longer need to call vendor-specific proprietary APIs (such as NVIDIA's
> cuFile API) or install vendor-specific kernel modules (such as NVIDIA's
> nvidia-fs.ko) for different GPU vendors. We have tested fgds on GPU cards
> from NVIDIA, AMD, and several other vendors, and it works well.
>
> Besides the benefits in ease of use and compatibility, another key
> advantage of this solution is higher performance. [2] presents the
> performance comparison results between fgds and NVIDIA GDS. Because fgds
> eliminates the overhead of phony buffers incurred by NVIDIA GDS, it
> achieves significantly higher performance. For example, for reads, fgds
> outperforms GDS by 11% to 109%; for writes, fgds outperforms GDS by 10%
> to 71%.
>
> To further accelerate the read and write operations of large files or
> massive data volumes—which are very common in LLM scenarios—we have
> implemented library functions `fgds_read` and `fgds_write`. Under the hood,
> these interfaces split large data into chunks and submit them
> asynchronously and in parallel via io_uring, thereby further boosting I/O
> performance, with read performance improved by up to 115% and write
> performance by up to 40%. In addition, we also provide the `fgds_register`
> library interface to encapsulate the `open`, `ioctl' and `mmap` operations.
> Readers who are interested can refer to [2].
>
> In addition, we have added the LMCache backend, enabling vLLM to offload KV
> cache via LMCache using fgds, which accelerates inference performance. We
> also added PyTorch APIs, compatible with the PyTorch GDS API, to improve
> the performance of reading and writing checkpoints during LLM training.
>
> We look forward to community feedback and are fully committed to iterating
> on this series to work towards upstreaming.
That's not really needed in a changelog text, it could be in the 0/X
patch :)
Anyway, you didn't cc: the io_uring list, why?
Also, as a first cut, please see the sashiko comments on this patch:
https://sashiko.dev/#/patchset/20260908131545.105987-1-liwang@kylinos.cn
>
> [1] https://dl.acm.org/doi/10.1145/3712285.3759862
> [2] https://github.com/Storage-and-OS-for-AI/fgds
>
> Signed-off-by: Mengmeng Zhao <zhaomengmeng(a)kylinos.cn>
> Signed-off-by: Li Wang <liwang(a)kylinos.cn>
> ---
> drivers/misc/Kconfig | 9 +
> drivers/misc/Makefile | 1 +
> drivers/misc/fgds.c | 989 ++++++++++++++++++++++++++++++++++++++
> include/uapi/linux/fgds.h | 54 +++
> 4 files changed, 1053 insertions(+)
> create mode 100644 drivers/misc/fgds.c
> create mode 100644 include/uapi/linux/fgds.h
>
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index 7364931dad3a..2f3a5a5fd0bf 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -568,6 +568,15 @@ config MCHP_LAN966X_PCI
> - lan966x-miim (MDIO_MSCC_MIIM)
> - lan966x-switch (LAN966X_SWITCH)
>
> +config FGDS
> + tristate "GPU-NVMe direct I/O control driver"
> + depends on PCI && DMA_SHARED_BUFFER && ZONE_DEVICE
> + help
> + Say Y here if you want to support GPU-NVME direct I/O
> + via POSIX/io_uring interfaces.
> +
> + If unsure, say N.
Module name is not listed here.
Nor why "fgds" is the name, that's going to be hard to remember, does it
stand for something?
> +
> source "drivers/misc/c2port/Kconfig"
> source "drivers/misc/eeprom/Kconfig"
> source "drivers/misc/cb710/Kconfig"
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index e8d8d5d88c0d..04985abe1678 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -71,3 +71,4 @@ obj-y += keba/
> obj-y += amd-sbi/
> obj-$(CONFIG_MISC_RP1) += rp1/
> obj-$(CONFIG_INTEL_SSEI) += issei/
> +obj-$(CONFIG_FGDS) += fgds.o
> diff --git a/drivers/misc/fgds.c b/drivers/misc/fgds.c
> new file mode 100644
> index 000000000000..3aa4945f701b
> --- /dev/null
> +++ b/drivers/misc/fgds.c
> @@ -0,0 +1,989 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Fast GPU Direct Storage via dma-buf.
> + *
> + * Copyright (C) 2026 KylinSoft. Co., Ltd. All rights reserved.
> + *
> + * Maps GPU memory into user space to enable direct NVME-to-GPU DMA
> + * pread/pwrite syscalls. BAR pages are remapped into ZONE_DEVICE via
> + * devm_memremap_pages() and populated using dma-buf backing pages.
> + */
> +#define pr_fmt(fmt) "fgds: " fmt
You are a driver, always use dev_*() print functions, not pr_()
functions, as you will loose the device information. For example:
> +/*
> + * BAR-based mapping requires device physical addresses. When using
> + * IOMMU, DMA addresses are IOVAs, which cannot be mapped directly.
> + */
> +static int fgds_check_gpu_iommu(struct pci_dev *pdev)
> +{
> + struct iommu_domain *domain;
> +
> + domain = iommu_get_domain_for_dev(&pdev->dev);
> + if (domain && domain->type != IOMMU_DOMAIN_IDENTITY) {
> + pr_warn("%s: reject attaching a translating IOMMU domain (requires iommu=pt or off\n",
> + dev_name(&pdev->dev));
Should be dev_warn(), right?
But what can userspace do with that warning, did something just break?
> + pr_info("loaded successfully: %u GPU(s) active\n", fgds_dev_count);
When drivers work, they are quiet, please remove this, and the other
pr_info() lines, as they seem to be left over from your debugging.
thanks,
greg k-h
On Wed, Aug 26, 2026 at 06:37:00PM +0530, Ekansh Gupta wrote:
> On 20-08-2026 20:17, Rob Clark wrote:
> > On Wed, Aug 19, 2026 at 11:15 PM Krzysztof Kozlowski <krzk(a)kernel.org> wrote:
> >>
> >> On 19/08/2026 17:48, Rob Clark wrote:
> >>> On Wed, Aug 19, 2026 at 8:27 AM Krzysztof Kozlowski <krzk(a)kernel.org> wrote:
> >>>> The rule of usptream development is that we do not accept duplicated
> >>>> code, just because a vendor wants to write something new. This is
> >>>> basically the concept applied all over the drivers tree, where we pushed
> >>>> back against all sorts of duplications all over the vendors.
> >>>>
> >>>> What I miss in this thread is why would there be any exception here. We
> >>>> do not grant exceptions from standard practices on "I want" reasons.
> >>>
> >>> I agree that we should not have duplicated drivers just for vendor
> >>> lolz. But when it comes to adopting common frameworks and integrating
> >>> better into the ecosystem, this doesn't seem like something we should
> >>> actively discourage. I don't think this is a case of vendor lolz, but
> >>
> >> No one discourages it. Following standard Linux kernel practices and
> >> requirements is not discouraging, do not twist the narrative here.
> >> Again, it is standard upstream review telling that we do not duplicate
> >> drivers. Ever, unless there is serious exception needed.
> >
> > I wasn't trying to twist the narrative, just trying to come up with a
> > path forward that isn't "no" or "improve existing driver", since
> > neither of those gets us towards a future using common frameworks.
> >
> >> I asked why there should be an exception granted? Is the reason for
> >> exception following:
> >> "We want to adopt common framework"
> >> ?
> >
> > Possibly? But I don't think we want two drivers to be any sort of
> > long term solution. (Ie. as long as venus/iris have co-exist.)
> >
> >>
> >>> rather reacting to drm/accel emerging as the standard framework for
> >>> this sort of driver.
> >>>
> >>> So how do we get from here to there?
> >>
> >> What is wrong with my proposal?
> >
> > Maybe I missed something, my understanding was your proposal was
> > "Grow/replace/improve existing driver instead of coming with a
> > duplicate".. grow or improve doesn't move us toward common
> > frameworks. Maybe "replace" is a valid option. If there is something
> > I missed, then I apologize.
> >
> > Options I can think of are:
> >
> > 1. Hardware cutoff.. new hw gets new driver, existing hw gets existing
> > driver
> > 2. Backwards compat chardev registered by new driver, providing existing
> > UABI. I'm not 100% sure about the feasibility/drawbacks of this..
> > AFAIU the fastrpc folks where planning a backwards compat layer in
> > userspace, so maybe it is possible.
> > 3. exception?
> >
> > I'd like to know what the feasibility of #2 is, since at a high level
> > that sounds like the best option. Possibly limit exposure of legacy
> > UABI to existing hw so we don't get into a place of needing to extend
> > the legacy UABI for new hw?
> >
> > But #1 sounds like a non-controversial place to start regardless.
> > Possibly with #2 coming as followup and necessary step before eventual
> > migration to new driver for existing hw?
> >
> > Even if we start with #2, how do we handle first-merge-window
> > bugs/regressions without reverting addition of new driver and removal
> > of old? It seems like we'd need a window of a couple release cycles
> > where both drivers exist?
> >
> > Maybe others have other/better options in mind?
> To all, I'm seeking on the approach I should follow to go ahead here. I
> can work on implementing #1(as per Rob's list) with hw specific
> compatible for v4 if it's acceptable.
>
I don't see any reason for you to define a "hw specific compatible",
because as you have shown in this series (and as Rob point out), there's
no difference in the "hardware".
The only reason for your "hw specific compatible" is to make a software
selection in Linux - and that's not what DeviceTree is for.
As such, I don't see that you have a DeviceTree problem at all, because
this is a Linux-internal problem.
> #2(compat driver) is something that we are still exploring as we
> couldn't find any standard way to achieve it. We might start a separate
> discussion for that once we have few possible designs with us.
>
This is the actual problem!
We have existing user space that depends on the ioctl interface exposed
by the current misc driver. You must not break these.
Hardware cutoff is not a viable solution, because that's just a
declaration that we'll let the old platforms rotten - or alternatively
you commit to maintain two drivers to the very same feature and quality
level.
So the only reasonable solution is #2; from there it's a valid question
if you reach that point my stepwise migrating the current misc driver
that solution, or if you present a new driver with the fully backwards
compatible interface, alongside the new ABI.
But this does bring to a question which the cover letter should explain
- but doesn't: what problem does this patch series actually solve?
Regards,
Bjorn
> Happy to take any other suggestion also.>
> > BR,
> > -R
>
>
On Fri, Sep 04, 2026 at 12:44:57PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding(a)nvidia.com>
>
> Drivers buildable as a module may want to use this, so export it.
We need a specific reason/driver. Otherwise, that's every API function.
It doesn't look to me like the VPR driver ever actually uses the NID.
>
> Signed-off-by: Thierry Reding <treding(a)nvidia.com>
> ---
> drivers/of/of_numa.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/of/of_numa.c b/drivers/of/of_numa.c
> index 230d5f628c1b..da2e9bd1717c 100644
> --- a/drivers/of/of_numa.c
> +++ b/drivers/of/of_numa.c
> @@ -171,6 +171,7 @@ int of_node_to_nid(struct device_node *device)
>
> return NUMA_NO_NODE;
> }
> +EXPORT_SYMBOL(of_node_to_nid);
Assuming this is still needed, EXPORT_SYMBOL_GPL.
Rob
From: Leon Romanovsky <leonro(a)nvidia.com>
Nothing in DMA-buf declares whether a mapping may be moved or taken away.
Nearly every callback on both sides is optional, so the answer follows
from which ones are implemented and from whether dma_buf_pin() succeeds.
Documentation/ says none of this, and the rules sit in the kdoc of
dma_buf_ops.pin, dma_buf_attach_ops.invalidate_mappings and
dma_buf_invalidate_mappings(), which a driver author has to know by name
before finding them.
Describe the three flows an importer has to handle, the callbacks each
one asks of both sides, and dma_buf_pin() as the runtime negotiation.
Signed-off-by: Leon Romanovsky <leonro(a)nvidia.com>
---
Let's try this variant from importer POV.
Thanks
Changes in v2:
- Split pci p2p documentation patch to separate series
- Improved dma-buf documentation patch.
- Link to v1: https://patch.msgid.link/20260825-document-dma-buf-v1-0-5ecfb3e1371c@nvidia…
---
Documentation/driver-api/dma-buf.rst | 6 ++++
drivers/dma-buf/dma-buf.c | 69 +++++++++++++++++++++++++++++++++++-
2 files changed, 74 insertions(+), 1 deletion(-)
diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst
index 2f36c21d9948..39c201f38aa6 100644
--- a/Documentation/driver-api/dma-buf.rst
+++ b/Documentation/driver-api/dma-buf.rst
@@ -113,6 +113,12 @@ Basic Operation and Device DMA Access
.. kernel-doc:: drivers/dma-buf/dma-buf.c
:doc: dma buf device access
+Mapping Lifetime Negotiation
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/dma-buf/dma-buf.c
+ :doc: mapping lifetime negotiation
+
CPU Access to DMA Buffer Objects
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index d504c636dc29..aa47142cd9ed 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -684,7 +684,74 @@ static struct file *dma_buf_getfile(size_t size, int flags)
* reference acquired with dma_buf_get() by calling dma_buf_put().
*
* For the detailed semantics exporters are expected to implement see
- * &dma_buf_ops.
+ * &dma_buf_ops. Whether the exporter may still move or take away the backing
+ * storage after step 3 depends on what both sides implement. See the mapping
+ * lifetime negotiation section below.
+ */
+
+/**
+ * DOC: mapping lifetime negotiation
+ *
+ * Nearly everything in DMA-buf is optional. No flag or enum says whether the
+ * exporter may move or take away the backing storage while an importer holds
+ * a mapping. Each side simply implements the callbacks it can offer, and
+ * dma_buf_pin() settles the result at runtime.
+ *
+ * Out of that optionality the importer sees three main flows. They are named
+ * from the importer's point of view, because each one demands a different
+ * capability of its hardware:
+ *
+ * - Pinned: the memory is never taken away. The importer offers no way
+ * to stop DMA.
+ * - Revoked: the storage never moves, but the exporter may take it away. The
+ * importer must be able to stop DMA, and may hit user visible errors while
+ * doing so.
+ * - Movable: the exporter may relocate the storage at any time. The importer
+ * must be able to pause DMA, and must raise no error while the storage is
+ * moving.
+ *
+ * An importer reaches its flow like this:
+ *
+ * 1. Attach with dma_buf_dynamic_attach(). Leaving out the optional
+ * &dma_buf_attach_ops.invalidate_mappings callback pins the buffer for as
+ * long as the attachment exists.
+ * 2. Call dma_buf_pin() under the reservation lock.
+ * 3. On failure, run the movable flow or give up.
+ * 4. On success, the flow is the revoked one if the optional
+ * &dma_buf_attach_ops.invalidate_mappings is implemented, and the pinned
+ * one if it is not.
+ *
+ * Pinned flow:
+ *
+ * - Exporter: implement &dma_buf_ops.pin and &dma_buf_ops.unpin to hold the
+ * storage still on request. An exporter whose storage never moves implements
+ * neither, and dma_buf_pin() then succeeds on its own. An exporter which
+ * refuses to be pinned implements &dma_buf_ops.pin and fails it.
+ * - Importer: nothing more. The mapping stays valid until the importer unmaps.
+ *
+ * Revoked flow:
+ *
+ * - Exporter: answer dma_buf_pin() as above. Call
+ * dma_buf_invalidate_mappings() when the storage goes away and fail
+ * &dma_buf_ops.map_dma_buf while it is gone. The two waits which complete a
+ * revocation are described in dma_buf_invalidate_mappings().
+ * - Importer: &dma_buf_attach_ops.invalidate_mappings has to unmap within
+ * bounded time and drop the pin.
+ *
+ * Movable flow:
+ *
+ * - Exporter: call dma_buf_invalidate_mappings() before each move, then wait
+ * for the &dma_buf.resv fences. &dma_buf_ops.pin and &dma_buf_ops.unpin play
+ * no part here.
+ * - Importer: hold no pin. &dma_buf_attach_ops.invalidate_mappings drops the
+ * cached mapping and has to lead to dma_buf_unmap_attachment() within
+ * bounded time. It need not stop the hardware, because access runs until the
+ * importer's &dma_buf.resv fences retire. The importer maps again before the
+ * next DMA.
+ *
+ * &dma_buf_ops.attach is the best place for an exporter to turn an importer
+ * away, because the importer can still fall back to another flow and attach
+ * again.
*/
/**
---
base-commit: 63367df6e7255067ad6a83abe0d2799dfa491876
change-id: 20260820-document-dma-buf-3f8b41e32f57
Best regards,
--
Leon Romanovsky <leonro(a)nvidia.com>
DMA-buf lets an exporter pin, move or revoke the backing storage under
an importer, and which of the three applies is decided by the optional
callbacks each side implements and by whether dma_buf_pin() succeeds.
Nothing in Documentation/ describes that, and the single reference to
the mechanism still names move_notify(), removed in v7.1.
Thanks
Signed-off-by: Leon Romanovsky <leonro(a)nvidia.com>
---
Leon Romanovsky (2):
PCI/P2PDMA: Update DMABUF lifecycle docs after move_notify() rename
dma-buf: Document how exporters and importers agree on mapping lifetime
Documentation/driver-api/dma-buf.rst | 6 +++
Documentation/driver-api/pci/p2pdma.rst | 6 ++-
drivers/dma-buf/dma-buf.c | 85 ++++++++++++++++++++++++++++++++-
3 files changed, 94 insertions(+), 3 deletions(-)
---
base-commit: 8049741ac93acd3a590dac070e12571fddf0e294
change-id: 20260820-document-dma-buf-3f8b41e32f57
Best regards,
--
Leon Romanovsky <leonro(a)nvidia.com>
Hi,
On 9/3/26 9:10 AM, Manuel Ebner wrote:
> Remove needless '(' and add missing ')'.
>
> Signed-off-by: Manuel Ebner <manuelebnerli(a)mailbox.org>
> ---
> Documentation/gpu/drm-vm-bind-locking.rst | 2 +-
> Documentation/gpu/nova/core/todo.rst | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
This patch probably should be 2 patches since these files have
different maintainers.
> diff --git a/Documentation/gpu/drm-vm-bind-locking.rst b/Documentation/gpu/drm-vm-bind-locking.rst
> index a345aa513..df6cf0132 100644
> --- a/Documentation/gpu/drm-vm-bind-locking.rst
> +++ b/Documentation/gpu/drm-vm-bind-locking.rst
> @@ -170,7 +170,7 @@ submission is therefore preceded with a re-validation section:
> validate_gem_bo(&gpu_vm_bo->gem_bo);
>
> // The following list iteration needs the Gem object's
> - // dma_resv to be held (it protects the gpu_vm_bo's list of
> + // dma_resv to be held. It protects the gpu_vm_bo's list of
> // gpu_vmas, but since local gem objects share the gpu_vm's
> // dma_resv, it is already held at this point.
I think that I must like parenthetical phrases more than you do. ;)
Acked-by: Randy Dunlap <rdunlap(a)infradead.org>
Thanks.
> for_each_gpu_vma_of_gpu_vm_bo(&gpu_vm_bo, &gpu_vma)
> diff --git a/Documentation/gpu/nova/core/todo.rst b/Documentation/gpu/nova/core/todo.rst
> index d5130b2b0..a01c362b1 100644
> --- a/Documentation/gpu/nova/core/todo.rst
> +++ b/Documentation/gpu/nova/core/todo.rst
> @@ -33,7 +33,7 @@ A good example from nova-core would be the ``Chipset`` enum type, which defines
> the value ``AD102``. When probing the GPU the value ``0x192`` can be read from a
> certain register indication the chipset AD102. Hence, the enum value ``AD102``
> should be derived from the number ``0x192``. Currently, nova-core uses a custom
> -implementation (``Chipset::from_u32`` for this.
> +implementation (``Chipset::from_u32``) for this.
>
> Instead, it would be desirable to have something like the ``FromPrimitive``
> trait [1] from the num crate.
--
~Randy
On Wed, Sep 02, 2026 at 07:07:50PM -0400, David Hu wrote:
> On Wed, Sep 2, 2026 at 8:08 AM Jason Gunthorpe <jgg(a)ziepe.ca> wrote:
> >
> > On Tue, Sep 01, 2026 at 05:08:49PM +0000, David Hu 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.
> >
> > This patch is fine, but pedenatically a scatterlist's entry limit
> > should be bounded to dma_get_max_seg_size(), though I don't think it
> > helps this. Operating scatterlists at the size limits has proven
> > problematic in a number of places already...
> >
> > > 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.
> >
> > That's an IB side bug, the newer logic that joins adjacent SGLs should
> > have avoided it?
>
> Hi Jason,
>
> Thank you for the review. I think you are right on both counts.
> Regarding the IB side, the new SGL joining logic in
> `ib_umem_find_best_pgsz()` indeed avoids the issue. `mask |= va` is
> skipped for artifically split, contiguous SGLs. Since Christian has
> already pulled v8 into drm-misc-next, I won't spin a v9 to avoid
> creating unnecessary noise on the list. If you prefer a followup,
> please let me know.
Nope, I'm fine, it just explains why it wasn't seen in other
tested. You were backporting and mix&matched things. It confirms the
upstream kernel was fine from the start.
There are other importers besides RDMA, so I still think that this is
a good change regardless. Having each segment remain page aligned, and
staying away from ULONG_MAX that might trigger overflows is a friendly
and robust thing to do for less sophisticated importers.
Jason
On 9/1/26 19:08, David Hu wrote:
> From: David Hu <xuehaohu(a)google.com>
>
> This series address two related issues in scatter-gather mapping,
> specifically for the MMIO based dma-buf mapping. The fixes ensure
> sgt mapping is correct, and proper for large MMIO regions.
>
> Patch 1 fixes a silent integer overflow for mapping length exceeding 4G
> (Previously submitted as [PATCH v7] dma-buf: Fix silent overflow for
> phys vec to sgt)
> https://lore.kernel.org/all/20260609164047.486227-1-xuehaohu@google.com/
>
> Patch 2 Splits sgl by largest page aligned chunk
> (Previously submitted as [PATCH v3] dma-buf: Split sgl by largest page-aligned chunk)
> https://lore.kernel.org/all/20260722233806.3922093-1-dhu@x6u.co/
*sigh* such issues are exactly the reason why I didn't wanted the dma-mapping stuff inside DMA-buf. That clearly doesn't belong here.
I'm going to push those fixes to drm-misc-next now, but when there are more issues like that will mark the code as abandoned and not maintained.
Regards,
Christian.
>
> Changes in v8:
> - Combined the two patches into one unified series to avoid merge
> conflicts.
> - Collected Reviewed-by tag from Leon Romanovsky for Patch 2.
>
> David Hu (2):
> dma-buf: Fix silent overflow for phys vec to sgt
> dma-buf: Split sgl by largest page-aligned chunk
>
> drivers/dma-buf/dma-buf-mapping.c | 31 +++++++++++++++++++++----------
> 1 file changed, 21 insertions(+), 10 deletions(-)
>
> --
> 2.55.0.897.gb25b4bd76c-goog
>