Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

18 participants
3341 discussions

Re: [PATCH 1/2] dma-buf: Add __dma_fence_is_signaled()

by kernel test robot

Hello, kernel test robot noticed "Oops:general_protection_fault,probably_for_non-canonical_address#:#[##]SMP_KASAN_PTI" on: commit: 142f20971642be40507d3a0bc94e905e251db81a ("[PATCH 1/2] dma-buf: Add __dma_fence_is_signaled()") url: https://github.com/intel-lab-lkp/linux/commits/Philipp-Stanner/dma-buf-dma-… base: git://linuxtv.org/sailus/media_tree.git master patch link: https://lore.kernel.org/all/20251125104443.82974-2-phasta@kernel.org/ patch subject: [PATCH 1/2] dma-buf: Add __dma_fence_is_signaled() in testcase: lkvs version: lkvs-x86_64-6505b18-1_20251124 with following parameters: test: rapl-client config: x86_64-rhel-9.4-func compiler: gcc-14 test machine: 4 threads Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz (Skylake) with 32G memory (please refer to attached dmesg/kmsg for entire log/backtrace) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <oliver.sang(a)intel.com> | Closes: https://lore.kernel.org/oe-lkp/202512092317.8cf778a-lkp@intel.com [ 46.662293][ T179] i915 0000:00:02.0: vgaarb: VGA decodes changed: olddecodes=io+mem,decodes=io+mem:owns=io+mem [ 46.680656][ T40] sd 1:0:0:0: [sda] Preferred minimum I/O size 4096 bytes [ 46.682302][ T59] i915 0000:00:02.0: Direct firmware load for i915/skl_dmc_ver1_27.bin failed with error -2 [ 46.698362][ T59] i915 0000:00:02.0: [drm] Failed to load DMC firmware i915/skl_dmc_ver1_27.bin (-ENOENT). Disabling runtime power management. [ 46.711256][ T59] i915 0000:00:02.0: [drm] DMC firmware homepage: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git [ 46.725941][ T12] Oops: general protection fault, probably for non-canonical address 0xdffffc01544551ba: 0000 [#1] SMP KASAN PTI [ 46.725953][ T179] ------------[ cut here ]------------ [ 46.737600][ T12] KASAN: probably user-memory-access in range [0x0000000aa22a8dd0-0x0000000aa22a8dd7] [ 46.737612][ T12] CPU: 3 UID: 0 PID: 12 Comm: kworker/u16:0 Tainted: G S I 6.18.0-rc5-00236-g142f20971642 #1 PREEMPT(voluntary) [ 46.742889][ T179] Fence 0000:00:02.0:[i915]:9:2 released with pending signals! [ 46.752212][ T12] Tainted: [S]=CPU_OUT_OF_SPEC, [I]=FIRMWARE_WORKAROUND [ 46.752217][ T12] Hardware name: Dell Inc. OptiPlex 7040/0Y7WYT, BIOS 1.1.1 10/07/2015 [ 46.752220][ T12] Workqueue: i915 __i915_gem_free_work [i915] [ 46.765216][ T179] WARNING: CPU: 0 PID: 179 at drivers/dma-buf/dma-fence.c:555 dma_fence_release (kbuild/src/consumer/drivers/dma-buf/dma-fence.c:555 (discriminator 1)) [ 46.772517][ T12] [ 46.772521][ T12] RIP: 0010:__list_add_valid_or_report (kbuild/src/consumer/lib/list_debug.c:29) [ 46.772528][ T12] Code: 8b 98 fe 48 89 d3 48 85 d2 0f 84 af 8b 98 fe 4c 8d 62 08 48 89 fd 49 89 f5 48 b8 00 00 00 00 00 fc ff df 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 0f 85 b7 00 00 00 4c 39 6b 08 75 43 48 b8 00 00 00 00 All code ======== 0: 8b 98 fe 48 89 d3 mov -0x2c76b702(%rax),%ebx 6: 48 85 d2 test %rdx,%rdx 9: 0f 84 af 8b 98 fe je 0xfffffffffe988bbe f: 4c 8d 62 08 lea 0x8(%rdx),%r12 13: 48 89 fd mov %rdi,%rbp 16: 49 89 f5 mov %rsi,%r13 19: 48 b8 00 00 00 00 00 movabs $0xdffffc0000000000,%rax 20: fc ff df 23: 4c 89 e2 mov %r12,%rdx 26: 48 c1 ea 03 shr $0x3,%rdx 2a:* 80 3c 02 00 cmpb $0x0,(%rdx,%rax,1) <-- trapping instruction 2e: 0f 85 b7 00 00 00 jne 0xeb 34: 4c 39 6b 08 cmp %r13,0x8(%rbx) 38: 75 43 jne 0x7d 3a: 48 rex.W 3b: b8 00 00 00 00 mov $0x0,%eax Code starting with the faulting instruction =========================================== 0: 80 3c 02 00 cmpb $0x0,(%rdx,%rax,1) 4: 0f 85 b7 00 00 00 jne 0xc1 a: 4c 39 6b 08 cmp %r13,0x8(%rbx) e: 75 43 jne 0x53 10: 48 rex.W 11: b8 00 00 00 00 mov $0x0,%eax [ 46.779267][ T179] Modules linked in: [ 46.787293][ T12] RSP: 0018:ffffc9000010fac8 EFLAGS: 00010003 [ 46.787300][ T12] RAX: dffffc0000000000 RBX: 0000000aa22a8dcf RCX: ffffffff82f5859d [ 46.793179][ T179] platform_profile [ 46.803018][ T12] RDX: 00000001544551ba RSI: ffff88884fde5c90 RDI: ffffc9000010fb50 [ 46.803023][ T12] RBP: ffffc9000010fb50 R08: 0000000000000000 R09: ffffed1109fbcb96 [ 46.803025][ T12] R10: ffff88884fde5cb7 R11: fefefefefefefeff R12: 0000000aa22a8dd7 [ 46.805219][ T179] sd_mod [ 46.811413][ T12] R13: ffff88884fde5c90 R14: ffff88884fde5c90 R15: 0000000aa22a8dcf [ 46.811417][ T12] FS: 0000000000000000(0000) GS:ffff888848e3e000(0000) knlGS:0000000000000000 [ 46.811419][ T12] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 46.830755][ T179] intel_rapl_common [ 46.834463][ T12] CR2: 00007f3bc83ae000 CR3: 0000000868388002 CR4: 00000000003726f0 [ 46.834467][ T12] Call Trace: [ 46.834469][ T12] <TASK> [ 46.840348][ T179] snd_hda_core [ 46.848115][ T12] dma_fence_default_wait (kbuild/src/consumer/include/linux/list.h:158 (discriminator 1) kbuild/src/consumer/include/linux/list.h:177 (discriminator 1) kbuild/src/consumer/drivers/dma-buf/dma-fence.c:800 (discriminator 1)) [ 46.851758][ T179] x86_pkg_temp_thermal [ 46.859527][ T12] ? __pfx_dma_fence_default_wait (kbuild/src/consumer/drivers/dma-buf/dma-fence.c:778) The kernel config and materials to reproduce are available at: https://download.01.org/0day-ci/archive/20251209/202512092317.8cf778a-lkp@i… -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

2 months

Re: [PATCH v18 25/42] dept: add documents for dept

by Bagas Sanjaya

On Fri, Dec 05, 2025 at 04:18:38PM +0900, Byungchul Park wrote: > Add documents describing the concept and APIs of dept. > > Signed-off-by: Byungchul Park <byungchul(a)sk.com> > --- > Documentation/dev-tools/dept.rst | 778 +++++++++++++++++++++++++++ > Documentation/dev-tools/dept_api.rst | 125 +++++ You forget to add toctree entries: ---- >8 ---- diff --git a/Documentation/dev-tools/index.rst b/Documentation/dev-tools/index.rst index 4b8425e348abd1..02c858f5ed1fa2 100644 --- a/Documentation/dev-tools/index.rst +++ b/Documentation/dev-tools/index.rst @@ -22,6 +22,8 @@ Documentation/process/debugging/index.rst clang-format coccinelle sparse + dept + dept_api kcov gcov kasan > +Lockdep detects a deadlock by checking lock acquisition order. For > +example, a graph to track acquisition order built by lockdep might look > +like: > + > +.. literal:: > + > + A -> B - > + \ > + -> E > + / > + C -> D - > + > + where 'A -> B' means that acquisition A is prior to acquisition B > + with A still held. Use code-block directive for literal code blocks: ---- >8 ---- diff --git a/Documentation/dev-tools/dept.rst b/Documentation/dev-tools/dept.rst index 333166464543d7..8394c4ea81bc2a 100644 --- a/Documentation/dev-tools/dept.rst +++ b/Documentation/dev-tools/dept.rst @@ -10,7 +10,7 @@ Lockdep detects a deadlock by checking lock acquisition order. For example, a graph to track acquisition order built by lockdep might look like: -.. literal:: +.. code-block:: A -> B - \ @@ -25,7 +25,7 @@ Lockdep keeps adding each new acquisition order into the graph at runtime. For example, 'E -> C' will be added when the two locks have been acquired in the order, E and then C. The graph will look like: -.. literal:: +.. code-block:: A -> B - \ @@ -41,7 +41,7 @@ been acquired in the order, E and then C. The graph will look like: This graph contains a subgraph that demonstrates a loop like: -.. literal:: +.. code-block:: -> E - / \ @@ -76,7 +76,7 @@ e.g. irq context, normal process context, wq worker context, or so on. Can lockdep detect the following deadlock? -.. literal:: +.. code-block:: context X context Y context Z @@ -91,7 +91,7 @@ Can lockdep detect the following deadlock? No. What about the following? -.. literal:: +.. code-block:: context X context Y @@ -116,7 +116,7 @@ What leads a deadlock A deadlock occurs when one or multi contexts are waiting for events that will never happen. For example: -.. literal:: +.. code-block:: context X context Y context Z @@ -148,7 +148,7 @@ In terms of dependency: Dependency graph reflecting this example will look like: -.. literal:: +.. code-block:: -> C -> A -> B - / \ @@ -171,7 +171,7 @@ Introduce DEPT DEPT(DEPendency Tracker) tracks wait and event instead of lock acquisition order so as to recognize the following situation: -.. literal:: +.. code-block:: context X context Y context Z @@ -186,7 +186,7 @@ acquisition order so as to recognize the following situation: and builds up a dependency graph at runtime that is similar to lockdep. The graph might look like: -.. literal:: +.. code-block:: -> C -> A -> B - / \ @@ -199,7 +199,7 @@ DEPT keeps adding each new dependency into the graph at runtime. For example, 'B -> D' will be added when event D occurrence is a prerequisite to reaching event B like: -.. literal:: +.. code-block:: context W @@ -211,7 +211,7 @@ prerequisite to reaching event B like: After the addition, the graph will look like: -.. literal:: +.. code-block:: -> D / @@ -236,7 +236,7 @@ How DEPT works Let's take a look how DEPT works with the 1st example in the section 'Limitation of lockdep'. -.. literal:: +.. code-block:: context X context Y context Z @@ -256,7 +256,7 @@ event. Adding comments to describe DEPT's view in detail: -.. literal:: +.. code-block:: context X context Y context Z @@ -293,7 +293,7 @@ Adding comments to describe DEPT's view in detail: Let's build up dependency graph with this example. Firstly, context X: -.. literal:: +.. code-block:: context X @@ -304,7 +304,7 @@ Let's build up dependency graph with this example. Firstly, context X: There are no events to create dependency. Next, context Y: -.. literal:: +.. code-block:: context Y @@ -332,7 +332,7 @@ event A cannot be triggered if wait B cannot be awakened by event B. Therefore, we can say event A depends on event B, say, 'A -> B'. The graph will look like after adding the dependency: -.. literal:: +.. code-block:: A -> B @@ -340,7 +340,7 @@ graph will look like after adding the dependency: Lastly, context Z: -.. literal:: +.. code-block:: context Z @@ -362,7 +362,7 @@ triggered if wait A cannot be awakened by event A. Therefore, we can say event B depends on event A, say, 'B -> A'. The graph will look like after adding the dependency: -.. literal:: +.. code-block:: -> A -> B - / \ @@ -386,7 +386,7 @@ Interpret DEPT report The following is the same example in the section 'How DEPT works'. -.. literal:: +.. code-block:: context X context Y context Z @@ -425,7 +425,7 @@ We can simplify this by labeling each waiting point with [W], each point where its event's context starts with [S] and each event with [E]. This example will look like after the labeling: -.. literal:: +.. code-block:: context X context Y context Z @@ -443,7 +443,7 @@ DEPT uses the symbols [W], [S] and [E] in its report as described above. The following is an example reported by DEPT for a real problem in practice. -.. literal:: +.. code-block:: Link: https://lore.kernel.org/lkml/6383cde5-cf4b-facf-6e07-1378a485657d@I-love.SA… Link: https://lore.kernel.org/lkml/1674268856-31807-1-git-send-email-byungchul.pa… @@ -646,7 +646,7 @@ practice. Let's take a look at the summary that is the most important part. -.. literal:: +.. code-block:: --------------------------------------------------- summary @@ -669,7 +669,7 @@ Let's take a look at the summary that is the most important part. The summary shows the following scenario: -.. literal:: +.. code-block:: context A context B context ?(unknown) @@ -684,7 +684,7 @@ The summary shows the following scenario: Adding comments to describe DEPT's view in detail: -.. literal:: +.. code-block:: context A context B context ?(unknown) @@ -711,7 +711,7 @@ Adding comments to describe DEPT's view in detail: Let's build up dependency graph with this report. Firstly, context A: -.. literal:: +.. code-block:: context A @@ -735,7 +735,7 @@ unlock(&ni->ni_lock:0) depends on folio_unlock(&f1), say, The graph will look like after adding the dependency: -.. literal:: +.. code-block:: unlock(&ni->ni_lock:0) -> folio_unlock(&f1) @@ -743,7 +743,7 @@ The graph will look like after adding the dependency: Secondly, context B: -.. literal:: +.. code-block:: context B @@ -762,7 +762,7 @@ folio_unlock(&f1) depends on unlock(&ni->ni_lock:0), say, The graph will look like after adding the dependency: -.. literal:: +.. code-block:: -> unlock(&ni->ni_lock:0) -> folio_unlock(&f1) - / \ > +Limitation of lockdep > +--------------------- > + > +Lockdep deals with a deadlock by typical lock e.g. spinlock and mutex, > +that are supposed to be released within the acquisition context. > +However, when it comes to a deadlock by folio lock that is not supposed > +to be released within the acquisition context or other general > +synchronization mechanisms, lockdep doesn't work. > + > +NOTE: In this document, 'context' refers to any type of unique context > +e.g. irq context, normal process context, wq worker context, or so on. > + > +Can lockdep detect the following deadlock? > + > +.. literal:: > + > + context X context Y context Z > + > + mutex_lock A > + folio_lock B > + folio_lock B <- DEADLOCK > + mutex_lock A <- DEADLOCK > + folio_unlock B > + folio_unlock B > + mutex_unlock A > + mutex_unlock A > + > +No. What about the following? > + > +.. literal:: > + > + context X context Y > + > + mutex_lock A > + mutex_lock A <- DEADLOCK > + wait_for_complete B <- DEADLOCK > + complete B > + mutex_unlock A > + mutex_unlock A > + > +No. One unanswered question from my v17 review [1]: You explain in "How DEPT works" section how DEPT detects deadlock in the first example (the former with three contexts). Can you do the same on the second example (the latter with two contexts)? Thanks. [1]: https://lore.kernel.org/linux-doc/aN84jKyrE1BumpLj@archie.me/ -- An old man doll... just what I always wanted! - Clara

2 months, 1 week

[PATCH 1/2] dma-buf: improve sg_table debugging hack v3

by Christian König

This debugging hack is important to enforce the rule that importers should *never* touch the underlying struct page of the exporter. Instead of just mangling the page link create a copy of the sg_table but only copy over the DMA addresses and not the pages. This will cause a NULL pointer de-reference if the importer tries to touch the struct page. Still quite a hack but this at least allows the exporter to properly keeps it's sg_table intact while allowing the DMA-buf maintainer to find and fix misbehaving importers and finally switch over to using a different data structure in the future. v2: improve the hack further by using a wrapper structure and explaining the background a bit more in the commit message. v3: fix some whitespace issues, use sg_assign_page(). Signed-off-by: Christian König <christian.koenig(a)amd.com> Reviewed-by: Michael J. Ruhl <michael.j.ruhl(a)intel.com> (v1) --- drivers/dma-buf/dma-buf.c | 74 +++++++++++++++++++++++++++++++-------- 1 file changed, 60 insertions(+), 14 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 2305bb2cc1f1..944f4103b5cc 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -35,6 +35,12 @@ #include "dma-buf-sysfs-stats.h" +/* Wrapper to hide the sg_table page link from the importer */ +struct dma_buf_sg_table_wrapper { + struct sg_table *original; + struct sg_table wrapper; +}; + static inline int is_dma_buf_file(struct file *); static DEFINE_MUTEX(dmabuf_list_mutex); @@ -828,21 +834,59 @@ void dma_buf_put(struct dma_buf *dmabuf) } EXPORT_SYMBOL_NS_GPL(dma_buf_put, "DMA_BUF"); -static void mangle_sg_table(struct sg_table *sg_table) +static int dma_buf_mangle_sg_table(struct sg_table **sg_table) { -#ifdef CONFIG_DMABUF_DEBUG - int i; - struct scatterlist *sg; - - /* To catch abuse of the underlying struct page by importers mix - * up the bits, but take care to preserve the low SG_ bits to - * not corrupt the sgt. The mixing is undone on unmap - * before passing the sgt back to the exporter. + struct scatterlist *to_sg, *from_sg; + struct sg_table *from = *sg_table; + struct dma_buf_sg_table_wrapper *to; + int i, ret; + + if (!IS_ENABLED(CONFIG_DMABUF_DEBUG)) + return 0; + + /* + * To catch abuse of the underlying struct page by importers copy the + * sg_table without copying the page_link and give only the copy back to + * the importer. */ - for_each_sgtable_sg(sg_table, sg, i) - sg->page_link ^= ~0xffUL; -#endif + to = kzalloc(sizeof(*to), GFP_KERNEL); + if (!to) + return -ENOMEM; + + ret = sg_alloc_table(&to->wrapper, from->nents, GFP_KERNEL); + if (ret) + goto free_to; + + to_sg = to->wrapper.sgl; + for_each_sgtable_dma_sg(from, from_sg, i) { + to_sg->offset = 0; + to_sg->length = 0; + sg_assign_page(to_sg, NULL); + sg_dma_address(to_sg) = sg_dma_address(from_sg); + sg_dma_len(to_sg) = sg_dma_len(from_sg); + to_sg = sg_next(to_sg); + } + to->original = from; + *sg_table = &to->wrapper; + return 0; + +free_to: + kfree(to); + return ret; +} + +static void dma_buf_demangle_sg_table(struct sg_table **sg_table) +{ + struct dma_buf_sg_table_wrapper *copy; + + if (!IS_ENABLED(CONFIG_DMABUF_DEBUG)) + return; + + copy = container_of(*sg_table, typeof(*copy), wrapper); + *sg_table = copy->original; + sg_free_table(&copy->wrapper); + kfree(copy); } static inline bool @@ -1139,7 +1183,9 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach, if (ret < 0) goto error_unmap; } - mangle_sg_table(sg_table); + ret = dma_buf_mangle_sg_table(&sg_table); + if (ret) + goto error_unmap; if (IS_ENABLED(CONFIG_DMA_API_DEBUG)) { struct scatterlist *sg; @@ -1220,7 +1266,7 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment *attach, dma_resv_assert_held(attach->dmabuf->resv); - mangle_sg_table(sg_table); + dma_buf_demangle_sg_table(&sg_table); attach->dmabuf->ops->unmap_dma_buf(attach, sg_table, direction); if (dma_buf_pin_on_map(attach)) -- 2.43.0

2 months, 1 week

Re: [PATCH 1/4] dma-buf/fence: give some reasonable maximum signaling timeout

by Lucas Stach

Am Mittwoch, dem 26.11.2025 um 16:44 +0100 schrieb Philipp Stanner: > On Wed, 2025-11-26 at 16:03 +0100, Christian König wrote: > > > > [...] > > > My hope would be that in the mid-term future we'd get firmware > > > rings > > > that can be preempted through a firmware call for all major > > > hardware. > > > Then a huge share of our problems would disappear. > > > > At least on AMD HW pre-emption is actually horrible unreliable as > > well. > > Do you mean new GPUs with firmware scheduling, or what is "HW pre- > emption"? > > With firmware interfaces, my hope would be that you could simply tell > > stop_running_ring(nr_of_ring) > // time slice for someone else > start_running_ring(nr_of_ring) > > Thereby getting real scheduling and all that. And eliminating many > other problems we know well from drm/sched. It doesn't really matter if you have firmware scheduling or not for preemption to be a hard problem on GPUs. CPUs have limited software visible state that needs to be saved/restored on a context switch and even there people start complaining now that they need to context switch the AVX512 register set. GPUs have megabytes of software visible state. Which needs to be saved/restored on the context switch if you want fine grained preemption with low preemption latency. There might be points in the command execution where you can ignore most of that state, but reaching those points can have basically unbounded latency. So either you can reliably save/restore lots of state or you are limited to very coarse grained preemption with all the usual issues of timeouts and DoS vectors. I'm not totally up to speed with the current state across all relevant GPUs, but until recently NVidia was the only vendor to have real reliable fine-grained preemption. Regards, Lucas

2 months, 1 week

Re: [PATCH 1/2] dma-buf: improve sg_table debugging hack v2

by Christian König

On 12/4/25 16:51, Matthew Auld wrote: > On 04/12/2025 14:59, Christian König wrote: >> This debugging hack is important to enforce the rule that importers >> should *never* touch the underlying struct page of the exporter. >> >> Instead of just mangling the page link create a copy of the sg_table >> but only copy over the DMA addresses and not the pages. >> >> This will cause a NULL pointer de-reference if the importer tries to >> touch the struct page. Still quite a hack but this at least allows the >> exporter to properly keeps it's sg_table intact while allowing the >> DMA-buf maintainer to find and fix misbehaving importers and finally >> switch over to using a different data structure in the future. >> >> v2: improve the hack further by using a wrapper structure and explaining >> the background a bit more in the commit message. >> >> Signed-off-by: Christian König <christian.koenig(a)amd.com> >> Reviewed-by: Michael J. Ruhl <michael.j.ruhl(a)intel.com> (v1) >> --- >> drivers/dma-buf/dma-buf.c | 72 +++++++++++++++++++++++++++++++-------- >> 1 file changed, 58 insertions(+), 14 deletions(-) >> >> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c >> index 2305bb2cc1f1..8c4afd360b72 100644 >> --- a/drivers/dma-buf/dma-buf.c >> +++ b/drivers/dma-buf/dma-buf.c >> @@ -35,6 +35,12 @@ >> #include "dma-buf-sysfs-stats.h" >> +/* Wrapper to hide the sg_table page link from the importer */ >> +struct dma_buf_sg_table_wrapper { >> + struct sg_table *original; >> + struct sg_table wrapper; >> +}; >> + >> static inline int is_dma_buf_file(struct file *); >> static DEFINE_MUTEX(dmabuf_list_mutex); >> @@ -828,21 +834,57 @@ void dma_buf_put(struct dma_buf *dmabuf) >> } >> EXPORT_SYMBOL_NS_GPL(dma_buf_put, "DMA_BUF"); >> -static void mangle_sg_table(struct sg_table *sg_table) >> +static int dma_buf_mangle_sg_table(struct sg_table **sg_table) >> { >> -#ifdef CONFIG_DMABUF_DEBUG >> - int i; >> - struct scatterlist *sg; >> - >> - /* To catch abuse of the underlying struct page by importers mix >> - * up the bits, but take care to preserve the low SG_ bits to >> - * not corrupt the sgt. The mixing is undone on unmap >> - * before passing the sgt back to the exporter. >> + struct scatterlist *to_sg, *from_sg; >> + struct sg_table *from = *sg_table; >> + struct dma_buf_sg_table_wrapper *to; >> + int i, ret; >> + >> + if (!IS_ENABLED(CONFIG_DMABUF_DEBUG)) >> + return 0; >> + >> + /* >> + * To catch abuse of the underlying struct page by importers copy the >> + * sg_table without copying the page_link and give only the copy back to >> + * the importer. >> */ >> - for_each_sgtable_sg(sg_table, sg, i) >> - sg->page_link ^= ~0xffUL; >> -#endif >> + to = kzalloc(sizeof(*to), GFP_KERNEL); >> + if (!to) >> + return -ENOMEM; >> + >> + ret = sg_alloc_table(&to->wrapper, from->nents, GFP_KERNEL); >> + if (ret) >> + goto free_to; >> + >> + to_sg = to->wrapper.sgl; >> + for_each_sgtable_dma_sg(from, from_sg, i) { >> + sg_set_page(to_sg, NULL, 0, 0); > > Are we still allowed to pass NULL page here? There looks to be the recently added: > > VM_WARN_ON_ONCE(!page_range_contiguous(page, ALIGN(len + offset, PAGE_SIZE) / PAGE_SIZE)); > > And if page_range_contiguous() does not just return true, it potentially wants to dereference the page, like with page_to_pfn()? Good point. It doesn't crash at the moment because page_to_pfn() also works with NULL as page, but it is clearly not the nicest thing to do. I will switch over to using sg_assign_page() instead. > > >> + sg_dma_address(to_sg) = sg_dma_address(from_sg); >> + sg_dma_len(to_sg) = sg_dma_len(from_sg); > > Nit: formatting looks off here. Oh, indeed. Thanks, Christian. > >> + to_sg = sg_next(to_sg); >> + } >> + to->original = from; >> + *sg_table = &to->wrapper; >> + return 0; >> + >> +free_to: >> + kfree(to); >> + return ret; >> +} >> + >> +static void dma_buf_demangle_sg_table(struct sg_table **sg_table) >> +{ >> + struct dma_buf_sg_table_wrapper *copy; >> + >> + if (!IS_ENABLED(CONFIG_DMABUF_DEBUG)) >> + return; >> + >> + copy = container_of(*sg_table, typeof(*copy), wrapper); >> + *sg_table = copy->original; >> + sg_free_table(&copy->wrapper); >> + kfree(copy); >> } >> static inline bool >> @@ -1139,7 +1181,9 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach, >> if (ret < 0) >> goto error_unmap; >> } >> - mangle_sg_table(sg_table); >> + ret = dma_buf_mangle_sg_table(&sg_table); >> + if (ret) >> + goto error_unmap; >> if (IS_ENABLED(CONFIG_DMA_API_DEBUG)) { >> struct scatterlist *sg; >> @@ -1220,7 +1264,7 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment *attach, >> dma_resv_assert_held(attach->dmabuf->resv); >> - mangle_sg_table(sg_table); >> + dma_buf_demangle_sg_table(&sg_table); >> attach->dmabuf->ops->unmap_dma_buf(attach, sg_table, direction); >> if (dma_buf_pin_on_map(attach)) >

2 months, 1 week

[PATCH 1/2] dma-buf: improve sg_table debugging hack v2

by Christian König

This debugging hack is important to enforce the rule that importers should *never* touch the underlying struct page of the exporter. Instead of just mangling the page link create a copy of the sg_table but only copy over the DMA addresses and not the pages. This will cause a NULL pointer de-reference if the importer tries to touch the struct page. Still quite a hack but this at least allows the exporter to properly keeps it's sg_table intact while allowing the DMA-buf maintainer to find and fix misbehaving importers and finally switch over to using a different data structure in the future. v2: improve the hack further by using a wrapper structure and explaining the background a bit more in the commit message. Signed-off-by: Christian König <christian.koenig(a)amd.com> Reviewed-by: Michael J. Ruhl <michael.j.ruhl(a)intel.com> (v1) --- drivers/dma-buf/dma-buf.c | 72 +++++++++++++++++++++++++++++++-------- 1 file changed, 58 insertions(+), 14 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 2305bb2cc1f1..8c4afd360b72 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -35,6 +35,12 @@ #include "dma-buf-sysfs-stats.h" +/* Wrapper to hide the sg_table page link from the importer */ +struct dma_buf_sg_table_wrapper { + struct sg_table *original; + struct sg_table wrapper; +}; + static inline int is_dma_buf_file(struct file *); static DEFINE_MUTEX(dmabuf_list_mutex); @@ -828,21 +834,57 @@ void dma_buf_put(struct dma_buf *dmabuf) } EXPORT_SYMBOL_NS_GPL(dma_buf_put, "DMA_BUF"); -static void mangle_sg_table(struct sg_table *sg_table) +static int dma_buf_mangle_sg_table(struct sg_table **sg_table) { -#ifdef CONFIG_DMABUF_DEBUG - int i; - struct scatterlist *sg; - - /* To catch abuse of the underlying struct page by importers mix - * up the bits, but take care to preserve the low SG_ bits to - * not corrupt the sgt. The mixing is undone on unmap - * before passing the sgt back to the exporter. + struct scatterlist *to_sg, *from_sg; + struct sg_table *from = *sg_table; + struct dma_buf_sg_table_wrapper *to; + int i, ret; + + if (!IS_ENABLED(CONFIG_DMABUF_DEBUG)) + return 0; + + /* + * To catch abuse of the underlying struct page by importers copy the + * sg_table without copying the page_link and give only the copy back to + * the importer. */ - for_each_sgtable_sg(sg_table, sg, i) - sg->page_link ^= ~0xffUL; -#endif + to = kzalloc(sizeof(*to), GFP_KERNEL); + if (!to) + return -ENOMEM; + + ret = sg_alloc_table(&to->wrapper, from->nents, GFP_KERNEL); + if (ret) + goto free_to; + + to_sg = to->wrapper.sgl; + for_each_sgtable_dma_sg(from, from_sg, i) { + sg_set_page(to_sg, NULL, 0, 0); + sg_dma_address(to_sg) = sg_dma_address(from_sg); + sg_dma_len(to_sg) = sg_dma_len(from_sg); + to_sg = sg_next(to_sg); + } + to->original = from; + *sg_table = &to->wrapper; + return 0; + +free_to: + kfree(to); + return ret; +} + +static void dma_buf_demangle_sg_table(struct sg_table **sg_table) +{ + struct dma_buf_sg_table_wrapper *copy; + + if (!IS_ENABLED(CONFIG_DMABUF_DEBUG)) + return; + + copy = container_of(*sg_table, typeof(*copy), wrapper); + *sg_table = copy->original; + sg_free_table(&copy->wrapper); + kfree(copy); } static inline bool @@ -1139,7 +1181,9 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach, if (ret < 0) goto error_unmap; } - mangle_sg_table(sg_table); + ret = dma_buf_mangle_sg_table(&sg_table); + if (ret) + goto error_unmap; if (IS_ENABLED(CONFIG_DMA_API_DEBUG)) { struct scatterlist *sg; @@ -1220,7 +1264,7 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment *attach, dma_resv_assert_held(attach->dmabuf->resv); - mangle_sg_table(sg_table); + dma_buf_demangle_sg_table(&sg_table); attach->dmabuf->ops->unmap_dma_buf(attach, sg_table, direction); if (dma_buf_pin_on_map(attach)) -- 2.43.0

2 months, 1 week

Re: [RFC v2 01/11] file: add callback for pre-mapping dmabuf

by Christian König

On 11/23/25 23:51, Pavel Begunkov wrote: > Add a file callback that maps a dmabuf for the given file and returns > an opaque token of type struct dma_token representing the mapping. I'm really scratching my head what you mean with that? And why the heck would we need to pass a DMA-buf to a struct file? Regards, Christian. > The > implementation details are hidden from the caller, and the implementors > are normally expected to extend the structure. > > The callback callers will be able to pass the token with an IO request, > which implemented in following patches as a new iterator type. The user > should release the token once it's not needed by calling the provided > release callback via appropriate helpers. > > Signed-off-by: Pavel Begunkov <asml.silence(a)gmail.com> > --- > include/linux/dma_token.h | 35 +++++++++++++++++++++++++++++++++++ > include/linux/fs.h | 4 ++++ > 2 files changed, 39 insertions(+) > create mode 100644 include/linux/dma_token.h > > diff --git a/include/linux/dma_token.h b/include/linux/dma_token.h > new file mode 100644 > index 000000000000..9194b34282c2 > --- /dev/null > +++ b/include/linux/dma_token.h > @@ -0,0 +1,35 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +#ifndef _LINUX_DMA_TOKEN_H > +#define _LINUX_DMA_TOKEN_H > + > +#include <linux/dma-buf.h> > + > +struct dma_token_params { > + struct dma_buf *dmabuf; > + enum dma_data_direction dir; > +}; > + > +struct dma_token { > + void (*release)(struct dma_token *); > +}; > + > +static inline void dma_token_release(struct dma_token *token) > +{ > + token->release(token); > +} > + > +static inline struct dma_token * > +dma_token_create(struct file *file, struct dma_token_params *params) > +{ > + struct dma_token *res; > + > + if (!file->f_op->dma_map) > + return ERR_PTR(-EOPNOTSUPP); > + res = file->f_op->dma_map(file, params); > + > + WARN_ON_ONCE(!IS_ERR(res) && !res->release); > + > + return res; > +} > + > +#endif > diff --git a/include/linux/fs.h b/include/linux/fs.h > index c895146c1444..0ce9a53fabec 100644 > --- a/include/linux/fs.h > +++ b/include/linux/fs.h > @@ -2262,6 +2262,8 @@ struct dir_context { > struct iov_iter; > struct io_uring_cmd; > struct offset_ctx; > +struct dma_token; > +struct dma_token_params; > > typedef unsigned int __bitwise fop_flags_t; > > @@ -2309,6 +2311,8 @@ struct file_operations { > int (*uring_cmd_iopoll)(struct io_uring_cmd *, struct io_comp_batch *, > unsigned int poll_flags); > int (*mmap_prepare)(struct vm_area_desc *); > + struct dma_token *(*dma_map)(struct file *, > + struct dma_token_params *); > } __randomize_layout; > > /* Supports async buffered reads */

2 months, 1 week

Re: [RFC v2 05/11] block: add infra to handle dmabuf tokens

by Christoph Hellwig

On Sun, Nov 23, 2025 at 10:51:25PM +0000, Pavel Begunkov wrote: > +struct dma_token *blkdev_dma_map(struct file *file, > + struct dma_token_params *params) Given that this is a direct file operation instance it should be in block/fops.c. If we do want a generic helper below it, it should take a struct block_device instead. But we can probably defer that until a user for that shows up.

2 months, 1 week

Re: [RFC v2 07/11] nvme-pci: implement dma_token backed requests

by Christoph Hellwig

> +static void nvme_sync_dma(struct nvme_dev *nvme_dev, struct request *req, > + enum dma_data_direction dir) > +{ > + struct blk_mq_dma_map *map = req->dma_map; > + int length = blk_rq_payload_bytes(req); > + bool for_cpu = dir == DMA_FROM_DEVICE; > + struct device *dev = nvme_dev->dev; > + dma_addr_t *dma_list = map->private; > + struct bio *bio = req->bio; > + int offset, map_idx; > + > + offset = bio->bi_iter.bi_bvec_done; > + map_idx = offset / NVME_CTRL_PAGE_SIZE; > + length += offset & (NVME_CTRL_PAGE_SIZE - 1); > + > + while (length > 0) { > + u64 dma_addr = dma_list[map_idx++]; > + > + if (for_cpu) > + __dma_sync_single_for_cpu(dev, dma_addr, > + NVME_CTRL_PAGE_SIZE, dir); > + else > + __dma_sync_single_for_device(dev, dma_addr, > + NVME_CTRL_PAGE_SIZE, dir); > + length -= NVME_CTRL_PAGE_SIZE; > + } This looks really inefficient. Usually the ranges in the dmabuf should be much larger than a controller page. > +static void nvme_unmap_premapped_data(struct nvme_dev *dev, > + struct request *req) > +{ > + struct nvme_iod *iod = blk_mq_rq_to_pdu(req); > + > + if (rq_data_dir(req) == READ) > + nvme_sync_dma(dev, req, DMA_FROM_DEVICE); > + if (!(iod->flags & IOD_SINGLE_SEGMENT)) > + nvme_free_descriptors(req); > +} This doesn't really unmap anything :) Also the dma ownership rules say that you always need to call the sync_to_device helpers before I/O and the sync_to_cpu helpers after I/O, no matters if it is a read or write. The implementations then makes them a no-op where possible. > + > + offset = bio->bi_iter.bi_bvec_done; > + map_idx = offset / NVME_CTRL_PAGE_SIZE; > + offset &= (NVME_CTRL_PAGE_SIZE - 1); > + > + prp1_dma = dma_list[map_idx++] + offset; > + > + length -= (NVME_CTRL_PAGE_SIZE - offset); > + if (length <= 0) { > + prp2_dma = 0; Urgg, why is this building PRPs instead of SGLs? Yes, SGLs are an optional feature, but for devices where you want to micro-optimize like this I think we should simply require them. This should cut down on both the memory use and the amount of special mapping code.

2 months, 1 week

Re: [RFC v2 06/11] nvme-pci: add support for dmabuf reggistration

by Christoph Hellwig

Splitting this trivial stub from the substantial parts in the next patch feels odd. Please merge them. (and better commit logs and comments really would be useful for others to understand what you've done). > +const struct dma_buf_attach_ops nvme_dmabuf_importer_ops = { > + .move_notify = nvme_dmabuf_move_notify, > + .allow_peer2peer = true, > +}; Tab-align the =, please. > +static int nvme_init_dma_token(struct request_queue *q, > + struct blk_mq_dma_token *token) > +{ > + struct dma_buf_attachment *attach; > + struct nvme_ns *ns = q->queuedata; > + struct nvme_dev *dev = to_nvme_dev(ns->ctrl); > + struct dma_buf *dmabuf = token->dmabuf; > + > + if (dmabuf->size % NVME_CTRL_PAGE_SIZE) > + return -EINVAL; Why do you care about alignment to the controller page size? > + for_each_sgtable_dma_sg(sgt, sg, tmp) { > + dma_addr_t dma = sg_dma_address(sg); > + unsigned long sg_len = sg_dma_len(sg); > + > + while (sg_len) { > + dma_list[i++] = dma; > + dma += NVME_CTRL_PAGE_SIZE; > + sg_len -= NVME_CTRL_PAGE_SIZE; > + } > + } Why does this build controller pages sized chunks?

2 months, 1 week

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig