Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

74 participants
6258 discussions

Re: [PATCH V13 2/7] dma-resv: Fix undefined symbol when CONFIG_DMA_SHARED_BUFFER is disabled

by Christian König

On 4/24/26 10:34, Mukesh Kumar Chaurasiya wrote: > On Fri, Apr 24, 2026 at 10:25:25AM +0200, Christian König wrote: >> On 4/24/26 10:06, Mukesh Kumar Chaurasiya wrote: >>> [Sie erhalten nicht häufig E-Mails von mkchauras(a)gmail.com. Weitere Informationen, warum dies wichtig ist, finden Sie unter https://aka.ms/LearnAboutSenderIdentification ] >>> >>> On Fri, Apr 24, 2026 at 09:56:16AM +0200, Christian König wrote: >>>> On 4/24/26 07:47, Mukesh Kumar Chaurasiya (IBM) wrote: >>>>> When building with LLVM=1 for architectures like powerpc where >>>>> CONFIG_DMA_SHARED_BUFFER is not enabled, the build fails with: >>>>> >>>>> ld.lld: error: undefined symbol: dma_resv_reset_max_fences >>>>> >>> referenced by helpers.c >>>>> >>> rust/helpers/helpers.o:(rust_helper_dma_resv_unlock) >>>>> >>>>> The issue occurs because: >>>>> 1. CONFIG_DEBUG_MUTEXES=y is enabled >>>>> 2. CONFIG_DMA_SHARED_BUFFER is not enabled >>>>> 3. dma_resv_reset_max_fences() is declared in the header when >>>>> CONFIG_DEBUG_MUTEXES is set >>>>> 4. But the function is only compiled in drivers/dma-buf/dma-resv.c, >>>>> which is only built when CONFIG_DMA_SHARED_BUFFER is enabled >>>>> 5. Rust helpers call dma_resv_unlock() which calls >>>>> dma_resv_reset_max_fences(), causing an undefined symbol >>>>> >>>>> Fix this by making the function declaration conditional on both >>>>> CONFIG_DEBUG_MUTEXES and CONFIG_DMA_SHARED_BUFFER. When either is >>>>> disabled, use a static inline stub instead. >>>> >>>> Well we are clearly missing something here, but of hand that doesn't looks like the right fix. >>>> >>>> When CONFIG_DMA_SHARED_BUFFER isn't enabled then the whole dma-resv.h header can't be used at all. >>>> >>>> So you also can't call dma_resv_unlock() from the Rust helpers. Which means that we need to make the Rust helpers somehow depend on CONFIG_DMA_SHARED_BUFFER. >>>> >>>> Alternative would be to provide dummies for the functions in dma-resv.h when CONFIG_DMA_SHARED_BUFFER isn't set, but that looks a bit like it just hides the issue. >>>> >>>> Regards, >>>> Christian. >>>> >>> What about something like this: >>> >>> diff --git a/rust/helpers/dma-resv.c b/rust/helpers/dma-resv.c >>> index 71914d8241e2..53c119f1b144 100644 >>> --- a/rust/helpers/dma-resv.c >>> +++ b/rust/helpers/dma-resv.c >>> @@ -2,6 +2,7 @@ >>> >>> #include <linux/dma-resv.h> >>> >>> +#ifdef CONFIG_DMA_SHARED_BUFFER >>> __rust_helper >>> int rust_helper_dma_resv_lock(struct dma_resv *obj, struct ww_acquire_ctx *ctx) >>> { >>> @@ -12,3 +13,4 @@ __rust_helper void rust_helper_dma_resv_unlock(struct dma_resv *obj) >>> { >>> dma_resv_unlock(obj); >>> } >>> +#endif >>> >>> This seems to fix the issue and makes sense, whoever wants to use the >>> dma shared buffer will anyway enable the config >> >> Yeah that directions makes sense. >> >> I would maybe go a step further and don't even compile rust/helpers/dma-resv.c when CONFIG_DMA_SHARED_BUFFER isn't set. >> > This makes sense. >> But if that is not possible for some reason then this solution is perfectly fine with me as well. >> >> The general goal is to make the error messages when you haven't set CONFIG_DMA_SHARED_BUFFER and still try to use the DMA-buf functions easy to understand and not something cryptic. >> >> Thanks, >> Christian. >> > > What about this one? > > diff --git a/rust/helpers/helpers.c b/rust/helpers/helpers.c > index 625921e27dfb..09ee5cac600d 100644 > --- a/rust/helpers/helpers.c > +++ b/rust/helpers/helpers.c > @@ -57,7 +57,9 @@ > #include "cred.c" > #include "device.c" > #include "dma.c" > +#ifdef CONFIG_DMA_SHARED_BUFFER > #include "dma-resv.c" > +#endif > #include "drm.c" > #include "err.c" > #include "irq.c" Looks good, feel free to add Reviewed-by: Christian König <christian.koenig(a)amd.com> But somebody more familiar with the Rust helpers should take another look on it. Regards, Christian. > > Regards, > Mukesh > >>> >>> Regards, >>> Mukesh >>>>> >>>>> Fixes: 0c6b522abc2a ("dma-buf: cleanup dma-resv shared fence debugging a bit v2") >>>>> Signed-off-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras(a)gmail.com> >>>>> --- >>>>> include/linux/dma-resv.h | 2 +- >>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>> >>>>> diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h >>>>> index c5ab6fd9ebe8..23c8db0b5214 100644 >>>>> --- a/include/linux/dma-resv.h >>>>> +++ b/include/linux/dma-resv.h >>>>> @@ -311,7 +311,7 @@ static inline bool dma_resv_iter_is_restarted(struct dma_resv_iter *cursor) >>>>> #define dma_resv_held(obj) lockdep_is_held(&(obj)->lock.base) >>>>> #define dma_resv_assert_held(obj) lockdep_assert_held(&(obj)->lock.base) >>>>> >>>>> -#ifdef CONFIG_DEBUG_MUTEXES >>>>> +#if IS_ENABLED(CONFIG_DEBUG_MUTEXES) && IS_ENABLED(CONFIG_DMA_SHARED_BUFFER) >>>>> void dma_resv_reset_max_fences(struct dma_resv *obj); >>>>> #else >>>>> static inline void dma_resv_reset_max_fences(struct dma_resv *obj) {} >>>>> -- >>>>> 2.53.0 >>>>> >>>> >>

2 days, 21 hours

Re: [PATCH V13 2/7] dma-resv: Fix undefined symbol when CONFIG_DMA_SHARED_BUFFER is disabled

by Christian König

On 4/24/26 10:06, Mukesh Kumar Chaurasiya wrote: > [Sie erhalten nicht häufig E-Mails von mkchauras(a)gmail.com. Weitere Informationen, warum dies wichtig ist, finden Sie unter https://aka.ms/LearnAboutSenderIdentification ] > > On Fri, Apr 24, 2026 at 09:56:16AM +0200, Christian König wrote: >> On 4/24/26 07:47, Mukesh Kumar Chaurasiya (IBM) wrote: >>> When building with LLVM=1 for architectures like powerpc where >>> CONFIG_DMA_SHARED_BUFFER is not enabled, the build fails with: >>> >>> ld.lld: error: undefined symbol: dma_resv_reset_max_fences >>> >>> referenced by helpers.c >>> >>> rust/helpers/helpers.o:(rust_helper_dma_resv_unlock) >>> >>> The issue occurs because: >>> 1. CONFIG_DEBUG_MUTEXES=y is enabled >>> 2. CONFIG_DMA_SHARED_BUFFER is not enabled >>> 3. dma_resv_reset_max_fences() is declared in the header when >>> CONFIG_DEBUG_MUTEXES is set >>> 4. But the function is only compiled in drivers/dma-buf/dma-resv.c, >>> which is only built when CONFIG_DMA_SHARED_BUFFER is enabled >>> 5. Rust helpers call dma_resv_unlock() which calls >>> dma_resv_reset_max_fences(), causing an undefined symbol >>> >>> Fix this by making the function declaration conditional on both >>> CONFIG_DEBUG_MUTEXES and CONFIG_DMA_SHARED_BUFFER. When either is >>> disabled, use a static inline stub instead. >> >> Well we are clearly missing something here, but of hand that doesn't looks like the right fix. >> >> When CONFIG_DMA_SHARED_BUFFER isn't enabled then the whole dma-resv.h header can't be used at all. >> >> So you also can't call dma_resv_unlock() from the Rust helpers. Which means that we need to make the Rust helpers somehow depend on CONFIG_DMA_SHARED_BUFFER. >> >> Alternative would be to provide dummies for the functions in dma-resv.h when CONFIG_DMA_SHARED_BUFFER isn't set, but that looks a bit like it just hides the issue. >> >> Regards, >> Christian. >> > What about something like this: > > diff --git a/rust/helpers/dma-resv.c b/rust/helpers/dma-resv.c > index 71914d8241e2..53c119f1b144 100644 > --- a/rust/helpers/dma-resv.c > +++ b/rust/helpers/dma-resv.c > @@ -2,6 +2,7 @@ > > #include <linux/dma-resv.h> > > +#ifdef CONFIG_DMA_SHARED_BUFFER > __rust_helper > int rust_helper_dma_resv_lock(struct dma_resv *obj, struct ww_acquire_ctx *ctx) > { > @@ -12,3 +13,4 @@ __rust_helper void rust_helper_dma_resv_unlock(struct dma_resv *obj) > { > dma_resv_unlock(obj); > } > +#endif > > This seems to fix the issue and makes sense, whoever wants to use the > dma shared buffer will anyway enable the config Yeah that directions makes sense. I would maybe go a step further and don't even compile rust/helpers/dma-resv.c when CONFIG_DMA_SHARED_BUFFER isn't set. But if that is not possible for some reason then this solution is perfectly fine with me as well. The general goal is to make the error messages when you haven't set CONFIG_DMA_SHARED_BUFFER and still try to use the DMA-buf functions easy to understand and not something cryptic. Thanks, Christian. > > Regards, > Mukesh >>> >>> Fixes: 0c6b522abc2a ("dma-buf: cleanup dma-resv shared fence debugging a bit v2") >>> Signed-off-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras(a)gmail.com> >>> --- >>> include/linux/dma-resv.h | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h >>> index c5ab6fd9ebe8..23c8db0b5214 100644 >>> --- a/include/linux/dma-resv.h >>> +++ b/include/linux/dma-resv.h >>> @@ -311,7 +311,7 @@ static inline bool dma_resv_iter_is_restarted(struct dma_resv_iter *cursor) >>> #define dma_resv_held(obj) lockdep_is_held(&(obj)->lock.base) >>> #define dma_resv_assert_held(obj) lockdep_assert_held(&(obj)->lock.base) >>> >>> -#ifdef CONFIG_DEBUG_MUTEXES >>> +#if IS_ENABLED(CONFIG_DEBUG_MUTEXES) && IS_ENABLED(CONFIG_DMA_SHARED_BUFFER) >>> void dma_resv_reset_max_fences(struct dma_resv *obj); >>> #else >>> static inline void dma_resv_reset_max_fences(struct dma_resv *obj) {} >>> -- >>> 2.53.0 >>> >>

2 days, 21 hours

Re: [PATCH V13 2/7] dma-resv: Fix undefined symbol when CONFIG_DMA_SHARED_BUFFER is disabled

by Christian König

On 4/24/26 07:47, Mukesh Kumar Chaurasiya (IBM) wrote: > When building with LLVM=1 for architectures like powerpc where > CONFIG_DMA_SHARED_BUFFER is not enabled, the build fails with: > > ld.lld: error: undefined symbol: dma_resv_reset_max_fences > >>> referenced by helpers.c > >>> rust/helpers/helpers.o:(rust_helper_dma_resv_unlock) > > The issue occurs because: > 1. CONFIG_DEBUG_MUTEXES=y is enabled > 2. CONFIG_DMA_SHARED_BUFFER is not enabled > 3. dma_resv_reset_max_fences() is declared in the header when > CONFIG_DEBUG_MUTEXES is set > 4. But the function is only compiled in drivers/dma-buf/dma-resv.c, > which is only built when CONFIG_DMA_SHARED_BUFFER is enabled > 5. Rust helpers call dma_resv_unlock() which calls > dma_resv_reset_max_fences(), causing an undefined symbol > > Fix this by making the function declaration conditional on both > CONFIG_DEBUG_MUTEXES and CONFIG_DMA_SHARED_BUFFER. When either is > disabled, use a static inline stub instead. Well we are clearly missing something here, but of hand that doesn't looks like the right fix. When CONFIG_DMA_SHARED_BUFFER isn't enabled then the whole dma-resv.h header can't be used at all. So you also can't call dma_resv_unlock() from the Rust helpers. Which means that we need to make the Rust helpers somehow depend on CONFIG_DMA_SHARED_BUFFER. Alternative would be to provide dummies for the functions in dma-resv.h when CONFIG_DMA_SHARED_BUFFER isn't set, but that looks a bit like it just hides the issue. Regards, Christian. > > Fixes: 0c6b522abc2a ("dma-buf: cleanup dma-resv shared fence debugging a bit v2") > Signed-off-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras(a)gmail.com> > --- > include/linux/dma-resv.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h > index c5ab6fd9ebe8..23c8db0b5214 100644 > --- a/include/linux/dma-resv.h > +++ b/include/linux/dma-resv.h > @@ -311,7 +311,7 @@ static inline bool dma_resv_iter_is_restarted(struct dma_resv_iter *cursor) > #define dma_resv_held(obj) lockdep_is_held(&(obj)->lock.base) > #define dma_resv_assert_held(obj) lockdep_assert_held(&(obj)->lock.base) > > -#ifdef CONFIG_DEBUG_MUTEXES > +#if IS_ENABLED(CONFIG_DEBUG_MUTEXES) && IS_ENABLED(CONFIG_DMA_SHARED_BUFFER) > void dma_resv_reset_max_fences(struct dma_resv *obj); > #else > static inline void dma_resv_reset_max_fences(struct dma_resv *obj) {} > -- > 2.53.0 >

2 days, 22 hours

[PATCH v2] dma-buf/udmabuf: skip redundant cpu sync to fix cacheline EEXIST warning

by Mikhail Gavrilov

When CONFIG_DMA_API_DEBUG_SG is enabled, importing a udmabuf into a DRM driver (e.g. amdgpu for video playback in GNOME Videos / Showtime) triggers a spurious warning: DMA-API: amdgpu 0000:03:00.0: cacheline tracking EEXIST, \ overlapping mappings aren't supported WARNING: kernel/dma/debug.c:619 at add_dma_entry+0x473/0x5f0 The call chain is: amdgpu_cs_ioctl -> amdgpu_ttm_backend_bind -> dma_buf_map_attachment -> [udmabuf] map_udmabuf -> get_sg_table -> dma_map_sgtable(dev, sg, direction, 0) // attrs=0 -> debug_dma_map_sg -> add_dma_entry -> EEXIST This happens because udmabuf builds a per-page scatter-gather list via sg_set_folio(). When begin_cpu_udmabuf() has already created an sg table mapped for the misc device, and an importer such as amdgpu maps the same pages for its own device via map_udmabuf(), the DMA debug infrastructure sees two active mappings whose physical addresses share cacheline boundaries and warns about the overlap. The DMA_ATTR_SKIP_CPU_SYNC flag suppresses this check in add_dma_entry() because it signals that no CPU cache maintenance is performed at map/unmap time, making the cacheline overlap harmless. All other major dma-buf exporters already pass this flag: - drm_gem_map_dma_buf() passes DMA_ATTR_SKIP_CPU_SYNC - amdgpu_dma_buf_map() passes DMA_ATTR_SKIP_CPU_SYNC The CPU sync at map/unmap time is also redundant for udmabuf: begin_cpu_udmabuf() and end_cpu_udmabuf() already perform explicit cache synchronization via dma_sync_sgtable_for_cpu/device() when CPU access is requested through the dma-buf interface. Pass DMA_ATTR_SKIP_CPU_SYNC to dma_map_sgtable() and dma_unmap_sgtable() in udmabuf to suppress the spurious warning and skip the redundant sync. Fixes: 284562e1f348 ("udmabuf: implement begin_cpu_access/end_cpu_access hooks") Cc: stable(a)vger.kernel.org Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov(a)gmail.com> --- v1 -> v2: - Rebased on drm-tip to resolve conflict with folio conversion patches. No code change, same two-line fix. v1: https://lore.kernel.org/all/20260317053653.28888-1-mikhail.v.gavrilov@gmail… drivers/dma-buf/udmabuf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c index 94b26ea706a3..bced421c0d65 100644 --- a/drivers/dma-buf/udmabuf.c +++ b/drivers/dma-buf/udmabuf.c @@ -145,7 +145,7 @@ static struct sg_table *get_sg_table(struct device *dev, struct dma_buf *buf, if (ret < 0) goto err_alloc; - ret = dma_map_sgtable(dev, sg, direction, 0); + ret = dma_map_sgtable(dev, sg, direction, DMA_ATTR_SKIP_CPU_SYNC); if (ret < 0) goto err_map; return sg; @@ -160,7 +160,7 @@ static struct sg_table *get_sg_table(struct device *dev, struct dma_buf *buf, static void put_sg_table(struct device *dev, struct sg_table *sg, enum dma_data_direction direction) { - dma_unmap_sgtable(dev, sg, direction, 0); + dma_unmap_sgtable(dev, sg, direction, DMA_ATTR_SKIP_CPU_SYNC); sg_free_table(sg); kfree(sg); } -- 2.53.0

3 days, 16 hours

(no subject)

by leoevelyn768＠gmail.com

Recovering Your Lost Bitcoin: Trust Almighty Recovery Hacker In the ever-evolving world of cryptocurrency, the allure of investment opportunities has attracted many, but unfortunately, it has also led to a rise in fraudulent schemes. If you've fallen victim to a deceptive investment firm and lost your hard-earned Bitcoin, you're not alone. Fortunately, there is help available. Almighty Recovery Hacker is a specialized recovery firm dedicated to helping individuals like you trace and recover lost or stolen Bitcoin. Email... almightyrecoverycoin{(a)}mail.com Whatsapp... {+53 5 1 556969}

3 days, 18 hours

Dub Hub: Steve Kerr thinks

by MurasakiDeiivi＠gmail.com

Brandin Podziemski is trying in direction of do much too much , making it possible for an uncontested physical appearance in direction of Utah's secondleading , who completed with 6 details within just a seasonlow 18 minutes, didn't perform the minute quarter as the Warriors blew the recreation open up with a 4120 toward reporters the moment Tuesday's train, Kerr claimed the thirdyear secure's present struggles stem towards trying toward do much too a lot.Through 18 video games, Podziemski is averaging 12.4 information upon 43.8% capturing, such as 37.9% against 3 and 77.8% at the freethrow consists of been powerful as the staff's secondary ballhandler powering Stephen Curry, still as Kerr notes, the Warriors wear't want even more towards Podziemski upon utmost ambition is there, still he's at his most straightforward Even though he leans into the job that enhances the veteran far more upon this and other information in the vicinity of the NBA, in this article is our newest information roundup for Wednesday, November 26th:Warriors Information:Warriors employ train toward lean into gameplan self-control right before Rockets showdown NBC Sporting activities Bay AreaSo, the Warriors, upon Tuesday, viewed movie of their 1347 victory that was manufactured upon the corrective motion taken around the supreme a few muted the Jazz within just the moment quarter, with a 4120 comfort, and rode the momentum toward a rout.What I observed as that very first quarter went upon was a absence of notice defensively, within just words and phrases of being familiar with the sport application, making an attempt in the direction of acquire out George and Markkanen and extremely be targeted upon them, ?Kerr mentioned soon after video clip evaluation and prepare at Chase Centre.And we make it possible for George attain 4 open up 3s in just the initial quarter.Warriors' Jonathan Kuminga toward be part of 5upon5 scrimmage, return even now unclear The AthleticKerr, who is made up of sounded annoyed within existing times When speaking about the deficiency of clarity close to Kuminga's reputation, supplied a sure enhance regarding the 23yearold just after Tuesday's train.He did threeonthree right before train, ?Kerr reported.And that went very then he took portion inside of all of he will gained't enjoy within just the video game Wednesday, nonetheless he will choose element within a fiveonfive scrimmage Wednesday night time just before our sport, and that will Deliver us a optimistic gauge for where by he is.Steph Curry discusses the thing to consider course of action guiding his shoe alternative as a refreshing sneaker no cost agentNBA Information:Where by just about every personnel stands throughout best 7 days of Community Engage in NBAThe Emirates NBA Cup includes accomplished the best 7 days of Local community Perform with 20 video games still left in the direction of Compute the 8 groups that will progress in the direction of the Knockout organized for the motion Wednesday upon ESPN, and a greatest video game Friday upon Best Video clip and League will progress in the direction of the Knockout Rounds? 8 areas are accessible.6 will transfer towards the winners of each individual supreme 2 wild card?areas will be the groups in opposition to every single convention with the ideal data within just Neighborhood Enjoy game titles who carried out moment inside their Suggs ejected just after scuffle through Magic76ers gameIn scenario yourself forgotten it at Golden Nation of Thoughts:How Jimmy Butler's manufacturer of isolation basketball fosters collectivismWhile simply just 5.6% of the Warriors' offensive belongings contain an isolation series 18th within the league it's a obvious uptick versus a time back, inside which 5% of their belongings had been isolations, 26th in just the the meantime, postup belongings on top of that professional a minimal uptick: against 2.3% very last time 22nd in direction of 3% this period Butler and his manufacturer of offense is made up of definitely performed a section guiding all those quantities https://www.goldenstatefanstore.com/collections/seth-curry-jersey, a option that is made up of tested in direction of be an thriving a person primarily based upon performance just 128 merged isolation and postup belongings amongst Butler which includes all those that conclusion within just a teammate getting a shot generate or neglected, freethrows, or turning the ball above the Warriors are scoring 1.047 information for every ownership, for each Synergy by unstoppablebaby upon X for all the hottest information upon the Golden Place Warriors. https://www.goldenstatefanstore.com Sitemap

4 days, 3 hours

Eingles

by jamesjohnson987547＠gmail.com

How Can I Recover My Lost Cryptocurrency, Top Hire Ghost Mystery Recovery Hacker It sounds like Ghost Mystery Recovery Hacker made a real impact with their professionalism and communication. Recovering something that seems lost for good can be a huge relief! Did they use any particular methods or tools that impressed Or was it their customer service that made the process smooth and reassuring. seems like you're referring to an experience with a service called Ghost Mystery Recovery Hacker. From what you're saying, it sounds like they provided excellent assistance in helping you recover something important. Could you share a bit more about what they helped you recover and what stood out most about the experience. Was it their approach, tools, or something else, They took the time to understand my situation and explained each step in a way that was honest and easy to follow. They took the time to understand my situation and explained each step in a way that was honest and easy to follow. What stood out most was their consistency and dedication. I was kept informed throughout, and they remained patient and responsive whenever I had questions. Their expertise was evident in the way they handled everything carefully and efficiently, without creating false expectations.The outcome exceeded what I had hoped for. They were able to successfully resolve my issue, which brought me a great sense of relief. It’s not often you come across a service that combines professionalism, transparency, and results so well. Email address: support@ ghostmysteryrecovery. c om WhatsApp on (+44) 7480 061765 Website; ghostmysteryrecovery. c om

4 days, 14 hours

Eingles

by jamesjohnson987547＠gmail.com

4 days, 14 hours

Eingles

by jamesjohnson987547＠gmail.com

4 days, 14 hours

[PATCH RFC 00/26] Add DMA-buf mapping types and convert vfio/iommufd to use them

by Jason Gunthorpe

Since its introduction, DMA-buf has only supported using scatterlist for the exporter and importer to exchange address information. This is not sufficient for all use cases as dma_addr_t is a very specific and limited type that should not be abused for things unrelated to the DMA API. There are several motivations for addressing this now: 1) VFIO to IOMMUFD and KVM requires a physical address, not a dma_addr_t scatterlist, it cannot be represented in the scatterlist structure 2) xe vGPU requires the host driver to accept a DMABUF from VFIO of its own VF and convert it into an internal VRAM address on the PF 3) We are starting to look at replacement datastructures for scatterlist 4) Ideas around UALink/etc are suggesting not using the DMA API None of these can sanely be achieved using scatterlist. Introduce a new mechanism called "mapping types" which allows DMA-buf to work with more map/unmap options than scatterlist. Each mapping type encompasses a full set of functions and data unique to itself. The core code provides a match-making system to select the best type offered by the exporter and importer to be the active mapping type for the attachment. Everything related to scatterlist is moved into a DMA-buf SGT mapping type, and into the "dma_buf_sgt_*" namespace for clarity. Existing exporters are moved over to explicitly declare SGT mapping types and importers are adjusted to use the dma_buf_sgt_* named importer helpers. Mapping types are designed to be extendable, a driver can declare its own mapping type for its internal private interconnect and use that without having to adjust the core code. The new attachment sequence starts with the importing driver declaring what mapping types it can accept: struct dma_buf_mapping_match imp_match[] = { DMA_BUF_IMAPPING_MY_DRIVER(dev, ...), DMA_BUF_IMAPPING_SGT(dev, false), }; attach = dma_buf_mapping_attach(dmabuf, imp_match, ...) Most drivers will do this via a dma_buf_sgt_*attach() helper. The exporting driver can then declare what mapping types it can supply: int exporter_match_mapping(struct dma_buf_match_args *args) { struct dma_buf_mapping_match exp_match[] = { DMA_BUF_EMAPPING_MY_DRIVER(my_ops, dev, ...), DMA_BUF_EMAPPING_SGT(sgt_ops, dev, false), DMA_BUF_EMAPPING_PAL(PAL_ops), }; return dma_buf_match_mapping(args, exp_match, ...); } Most drivers will do this via a helper: static const struct dma_buf_ops ops = { DMA_BUF_SIMPLE_SGT_EXP_MATCH(map_func, unmap_func) }; During dma_buf_mapping_attach() the core code will select a mutual match between the importer and exporter and record it as the active match in the attach->map_type. Each mapping type has its own types/function calls for mapping/unmapping, and storage in the attach->map_type for its information. As such each mapping type can offer function signatures and data that exactly matches its needs. This series goes through a sequence of: 1) Introduce the basic mapping type framework and the main components of the SGT mapping type 2) Automatically make all existing exporters and importers use core generated SGT mapping types so every attachment has a SGT mapping type 3) Convert all exporter drivers to natively create a SGT mapping type 4) Move all dma_buf_* functions and types that are related to SGT into dma_buf_sgt_* 5) Remove all the now-unused items that have been moved into SGT specific structures. 6) Demonstrate adding a new Physical Address List alongside SGT. Due to the high number of files touched I would expect this to be broken into phases, but this shows the entire picture. This is on github: https://github.com/jgunthorpe/linux/commits/dmabuf_map_type It is a followup to the discussion here: https://lore.kernel.org/dri-devel/20251027044712.1676175-1-vivek.kasireddy@… Jason Gunthorpe (26): dma-buf: Introduce DMA-buf mapping types dma-buf: Add the SGT DMA mapping type dma-buf: Add dma_buf_mapping_attach() dma-buf: Route SGT related actions through attach->map_type dma-buf: Allow single exporter drivers to avoid the match_mapping function drm: Check the SGT ops for drm_gem_map_dma_buf() dma-buf: Convert all the simple exporters to use SGT mapping type drm/vmwgfx: Use match_mapping instead of dummy calls accel/habanalabs: Use the SGT mapping type drm/xe/dma-buf: Use the SGT mapping type drm/amdgpu: Use the SGT mapping type vfio/pci: Change the DMA-buf exporter to use mapping_type dma-buf: Update dma_buf_phys_vec_to_sgt() to use the SGT mapping type iio: buffer: convert to use the SGT mapping type functionfs: convert to use the SGT mapping type dma-buf: Remove unused SGT stuff from the common structures treewide: Rename dma_buf_map_attachment(_unlocked) to dma_buf_sgt_ treewide: Rename dma_buf_unmap_attachment(_unlocked) to dma_buf_sgt_* treewide: Rename dma_buf_attach() to dma_buf_sgt_attach() treewide: Rename dma_buf_dynamic_attach() to dma_buf_sgt_dynamic_attach() dma-buf: Add the Physical Address List DMA mapping type vfio/pci: Add physical address list support to DMABUF iommufd: Use the PAL mapping type instead of a vfio function iommufd: Support DMA-bufs with multiple physical ranges iommufd/selftest: Check multi-phys DMA-buf scenarios dma-buf: Add kunit tests for mapping type Documentation/gpu/todo.rst | 2 +- drivers/accel/amdxdna/amdxdna_gem.c | 14 +- drivers/accel/amdxdna/amdxdna_ubuf.c | 10 +- drivers/accel/habanalabs/common/memory.c | 54 ++- drivers/accel/ivpu/ivpu_gem.c | 10 +- drivers/accel/ivpu/ivpu_gem_userptr.c | 11 +- drivers/accel/qaic/qaic_data.c | 8 +- drivers/dma-buf/Makefile | 1 + drivers/dma-buf/dma-buf-mapping.c | 186 ++++++++- drivers/dma-buf/dma-buf.c | 180 ++++++--- drivers/dma-buf/heaps/cma_heap.c | 12 +- drivers/dma-buf/heaps/system_heap.c | 13 +- drivers/dma-buf/st-dma-mapping.c | 373 ++++++++++++++++++ drivers/dma-buf/udmabuf.c | 8 +- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 98 +++-- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 +- drivers/gpu/drm/armada/armada_gem.c | 33 +- drivers/gpu/drm/drm_gem_shmem_helper.c | 2 +- drivers/gpu/drm/drm_prime.c | 31 +- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 18 +- drivers/gpu/drm/i915/gem/i915_gem_object.c | 2 +- .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 8 +- .../gpu/drm/i915/gem/selftests/mock_dmabuf.c | 8 +- drivers/gpu/drm/msm/msm_gem_prime.c | 7 +- drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 11 +- drivers/gpu/drm/tegra/gem.c | 33 +- drivers/gpu/drm/virtio/virtgpu_prime.c | 23 +- drivers/gpu/drm/vmwgfx/vmwgfx_prime.c | 32 +- drivers/gpu/drm/xe/xe_bo.c | 18 +- drivers/gpu/drm/xe/xe_dma_buf.c | 61 +-- drivers/iio/industrialio-buffer.c | 15 +- drivers/infiniband/core/umem_dmabuf.c | 15 +- drivers/iommu/iommufd/io_pagetable.h | 4 +- drivers/iommu/iommufd/iommufd_private.h | 8 - drivers/iommu/iommufd/iommufd_test.h | 7 + drivers/iommu/iommufd/pages.c | 85 ++-- drivers/iommu/iommufd/selftest.c | 177 ++++++--- .../media/common/videobuf2/videobuf2-core.c | 2 +- .../common/videobuf2/videobuf2-dma-contig.c | 26 +- .../media/common/videobuf2/videobuf2-dma-sg.c | 21 +- .../common/videobuf2/videobuf2-vmalloc.c | 13 +- .../platform/nvidia/tegra-vde/dmabuf-cache.c | 9 +- drivers/misc/fastrpc.c | 21 +- drivers/tee/tee_heap.c | 13 +- drivers/usb/gadget/function/f_fs.c | 11 +- drivers/vfio/pci/vfio_pci_dmabuf.c | 79 ++-- drivers/xen/gntdev-dmabuf.c | 29 +- include/linux/dma-buf-mapping.h | 297 ++++++++++++++ include/linux/dma-buf.h | 168 ++++---- io_uring/zcrx.c | 9 +- net/core/devmem.c | 14 +- samples/vfio-mdev/mbochs.c | 10 +- sound/soc/fsl/fsl_asrc_m2m.c | 12 +- tools/testing/selftests/iommu/iommufd.c | 43 ++ tools/testing/selftests/iommu/iommufd_utils.h | 17 + 55 files changed, 1764 insertions(+), 614 deletions(-) create mode 100644 drivers/dma-buf/st-dma-mapping.c base-commit: c63e5a50e1dd291cd95b04291b028fdcaba4c534 -- 2.43.0

4 days, 15 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig