- Linaro-mm-sig - lists.linaro.org

Re: [PATCH v2 06/10] dma-buf: heaps: Add support for Tegra VPR

by kernel test robot

Hi Thierry, kernel test robot noticed the following build warnings: [auto build test WARNING on akpm-mm/mm-everything] [also build test WARNING on next-20260122] [cannot apply to drm-misc/drm-misc-next robh/for-next linus/master v6.19-rc6] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Thierry-Reding/dt-bindings-r… base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything patch link: https://lore.kernel.org/r/20260122161009.3865888-7-thierry.reding%40kernel.… patch subject: [PATCH v2 06/10] dma-buf: heaps: Add support for Tegra VPR config: i386-allmodconfig (https://download.01.org/0day-ci/archive/20260123/202601231123.4V5wVUur-lkp@…) compiler: gcc-14 (Debian 14.2.0-19) 14.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260123/202601231123.4V5wVUur-lkp@…) 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 <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202601231123.4V5wVUur-lkp@intel.com/ All warnings (new ones prefixed by >>): drivers/dma-buf/heaps/tegra-vpr.c: In function 'tegra_vpr_protect_pages': drivers/dma-buf/heaps/tegra-vpr.c:205:21: error: implicit declaration of function '__ptep_get'; did you mean 'ptep_get'? [-Wimplicit-function-declaration] 205 | pte_t pte = __ptep_get(ptep); | ^~~~~~~~~~ | ptep_get drivers/dma-buf/heaps/tegra-vpr.c:205:21: error: invalid initializer drivers/dma-buf/heaps/tegra-vpr.c:207:15: error: implicit declaration of function 'clear_pte_bit'; did you mean 'clear_ptes'? [-Wimplicit-function-declaration] 207 | pte = clear_pte_bit(pte, __pgprot(PROT_NORMAL)); | ^~~~~~~~~~~~~ | clear_ptes In file included from arch/x86/include/asm/paravirt_types.h:11, from arch/x86/include/asm/ptrace.h:175, from arch/x86/include/asm/math_emu.h:5, from arch/x86/include/asm/processor.h:13, from arch/x86/include/asm/timex.h:5, from include/linux/timex.h:67, from include/linux/time32.h:13, from include/linux/time.h:60, from include/linux/stat.h:19, from include/linux/fs_dirent.h:5, from include/linux/fs/super_types.h:5, from include/linux/fs/super.h:5, from include/linux/fs.h:5, from include/linux/debugfs.h:15, from drivers/dma-buf/heaps/tegra-vpr.c:12: drivers/dma-buf/heaps/tegra-vpr.c:207:43: error: 'PROT_NORMAL' undeclared (first use in this function) 207 | pte = clear_pte_bit(pte, __pgprot(PROT_NORMAL)); | ^~~~~~~~~~~ arch/x86/include/asm/pgtable_types.h:202:48: note: in definition of macro '__pgprot' 202 | #define __pgprot(x) ((pgprot_t) { (x) } ) | ^ drivers/dma-buf/heaps/tegra-vpr.c:207:43: note: each undeclared identifier is reported only once for each function it appears in 207 | pte = clear_pte_bit(pte, __pgprot(PROT_NORMAL)); | ^~~~~~~~~~~ arch/x86/include/asm/pgtable_types.h:202:48: note: in definition of macro '__pgprot' 202 | #define __pgprot(x) ((pgprot_t) { (x) } ) | ^ drivers/dma-buf/heaps/tegra-vpr.c:208:15: error: implicit declaration of function 'set_pte_bit'; did you mean 'set_pte_at'? [-Wimplicit-function-declaration] 208 | pte = set_pte_bit(pte, __pgprot(PROT_DEVICE_nGnRnE)); | ^~~~~~~~~~~ | set_pte_at drivers/dma-buf/heaps/tegra-vpr.c:208:41: error: 'PROT_DEVICE_nGnRnE' undeclared (first use in this function) 208 | pte = set_pte_bit(pte, __pgprot(PROT_DEVICE_nGnRnE)); | ^~~~~~~~~~~~~~~~~~ arch/x86/include/asm/pgtable_types.h:202:48: note: in definition of macro '__pgprot' 202 | #define __pgprot(x) ((pgprot_t) { (x) } ) | ^ drivers/dma-buf/heaps/tegra-vpr.c:210:9: error: implicit declaration of function '__set_pte'; did you mean 'set_pte'? [-Wimplicit-function-declaration] 210 | __set_pte(ptep, pte); | ^~~~~~~~~ | set_pte drivers/dma-buf/heaps/tegra-vpr.c: In function 'tegra_vpr_unprotect_pages': drivers/dma-buf/heaps/tegra-vpr.c:218:21: error: invalid initializer 218 | pte_t pte = __ptep_get(ptep); | ^~~~~~~~~~ drivers/dma-buf/heaps/tegra-vpr.c:220:43: error: 'PROT_DEVICE_nGnRnE' undeclared (first use in this function) 220 | pte = clear_pte_bit(pte, __pgprot(PROT_DEVICE_nGnRnE)); | ^~~~~~~~~~~~~~~~~~ arch/x86/include/asm/pgtable_types.h:202:48: note: in definition of macro '__pgprot' 202 | #define __pgprot(x) ((pgprot_t) { (x) } ) | ^ drivers/dma-buf/heaps/tegra-vpr.c:221:41: error: 'PROT_NORMAL' undeclared (first use in this function) 221 | pte = set_pte_bit(pte, __pgprot(PROT_NORMAL)); | ^~~~~~~~~~~ arch/x86/include/asm/pgtable_types.h:202:48: note: in definition of macro '__pgprot' 202 | #define __pgprot(x) ((pgprot_t) { (x) } ) | ^ drivers/dma-buf/heaps/tegra-vpr.c: In function 'tegra_vpr_buffer_allocate': >> drivers/dma-buf/heaps/tegra-vpr.c:612:30: warning: variable 'last' set but not used [-Wunused-but-set-variable] 612 | unsigned long first, last; | ^~~~ >> drivers/dma-buf/heaps/tegra-vpr.c:612:23: warning: variable 'first' set but not used [-Wunused-but-set-variable] 612 | unsigned long first, last; | ^~~~~ drivers/dma-buf/heaps/tegra-vpr.c: In function 'tegra_vpr_buffer_release': drivers/dma-buf/heaps/tegra-vpr.c:695:30: warning: variable 'last' set but not used [-Wunused-but-set-variable] 695 | unsigned long first, last; | ^~~~ drivers/dma-buf/heaps/tegra-vpr.c:695:23: warning: variable 'first' set but not used [-Wunused-but-set-variable] 695 | unsigned long first, last; | ^~~~~ drivers/dma-buf/heaps/tegra-vpr.c: In function 'tegra_vpr_setup_chunks': >> drivers/dma-buf/heaps/tegra-vpr.c:8:21: warning: format '%lu' expects argument of type 'long unsigned int', but argument 6 has type 'size_t' {aka 'unsigned int'} [-Wformat=] 8 | #define pr_fmt(fmt) "tegra-vpr: " fmt | ^~~~~~~~~~~~~ include/linux/dynamic_debug.h:231:29: note: in expansion of macro 'pr_fmt' 231 | func(&id, ##__VA_ARGS__); \ | ^~~~~~~~~~~ include/linux/dynamic_debug.h:259:9: note: in expansion of macro '__dynamic_func_call_cls' 259 | __dynamic_func_call_cls(__UNIQUE_ID(ddebug), cls, fmt, func, ##__VA_ARGS__) | ^~~~~~~~~~~~~~~~~~~~~~~ include/linux/dynamic_debug.h:261:9: note: in expansion of macro '_dynamic_func_call_cls' 261 | _dynamic_func_call_cls(_DPRINTK_CLASS_DFLT, fmt, func, ##__VA_ARGS__) | ^~~~~~~~~~~~~~~~~~~~~~ include/linux/dynamic_debug.h:280:9: note: in expansion of macro '_dynamic_func_call' 280 | _dynamic_func_call(fmt, __dynamic_pr_debug, \ | ^~~~~~~~~~~~~~~~~~ include/linux/printk.h:636:9: note: in expansion of macro 'dynamic_pr_debug' 636 | dynamic_pr_debug(fmt, ##__VA_ARGS__) | ^~~~~~~~~~~~~~~~ drivers/dma-buf/heaps/tegra-vpr.c:1075:17: note: in expansion of macro 'pr_debug' 1075 | pr_debug(" %2u: %pap-%pap (%lu MiB)\n", i, &start, &end, | ^~~~~~~~ drivers/dma-buf/heaps/tegra-vpr.c: In function 'tegra_vpr_add_heap': drivers/dma-buf/heaps/tegra-vpr.c:1120:30: warning: variable 'last' set but not used [-Wunused-but-set-variable] 1120 | unsigned long first, last; | ^~~~ drivers/dma-buf/heaps/tegra-vpr.c:1120:23: warning: variable 'first' set but not used [-Wunused-but-set-variable] 1120 | unsigned long first, last; | ^~~~~ vim +/last +612 drivers/dma-buf/heaps/tegra-vpr.c 605 606 static struct tegra_vpr_buffer * 607 tegra_vpr_buffer_allocate(struct tegra_vpr *vpr, size_t size) 608 { 609 unsigned int num_pages = size >> PAGE_SHIFT; 610 unsigned int order = get_order(size); 611 struct tegra_vpr_buffer *buffer; > 612 unsigned long first, last; 613 int pageno, err; 614 pgoff_t i; 615 616 /* 617 * "order" defines the alignment and size, so this may result in 618 * fragmented memory depending on the allocation patterns. However, 619 * since this is used primarily for video frames, it is expected that 620 * a number of buffers of the same size will be allocated, so 621 * fragmentation should be negligible. 622 */ 623 pageno = tegra_vpr_allocate_region(vpr, num_pages, 1); 624 if (pageno < 0) 625 return ERR_PTR(pageno); 626 627 first = find_first_bit(vpr->bitmap, vpr->num_pages); 628 last = find_last_bit(vpr->bitmap, vpr->num_pages); 629 630 buffer = kzalloc(sizeof(*buffer), GFP_KERNEL); 631 if (!buffer) { 632 err = -ENOMEM; 633 goto release; 634 } 635 636 INIT_LIST_HEAD(&buffer->attachments); 637 INIT_LIST_HEAD(&buffer->list); 638 mutex_init(&buffer->lock); 639 buffer->start = vpr->base + (pageno << PAGE_SHIFT); 640 buffer->limit = buffer->start + size; 641 buffer->size = size; 642 buffer->num_pages = num_pages; 643 buffer->pageno = pageno; 644 buffer->order = order; 645 646 buffer->pages = kmalloc_array(buffer->num_pages, 647 sizeof(*buffer->pages), 648 GFP_KERNEL); 649 if (!buffer->pages) { 650 err = -ENOMEM; 651 goto free; 652 } 653 654 /* track which chunks this buffer overlaps */ 655 if (vpr->num_chunks > 0) { 656 unsigned int limit = buffer->pageno + buffer->num_pages, i; 657 658 for (i = 0; i < vpr->num_chunks; i++) { 659 struct tegra_vpr_chunk *chunk = &vpr->chunks[i]; 660 661 if (tegra_vpr_chunk_overlaps(chunk, pageno, limit)) 662 set_bit(i, buffer->chunks); 663 } 664 665 /* activate chunks if necessary */ 666 err = tegra_vpr_activate_chunks(vpr, buffer); 667 if (err < 0) 668 goto free; 669 670 /* track first and last allocated pages */ 671 if (buffer->pageno < vpr->first) 672 vpr->first = buffer->pageno; 673 674 if (limit - 1 > vpr->last) 675 vpr->last = limit - 1; 676 } 677 678 for (i = 0; i < buffer->num_pages; i++) 679 buffer->pages[i] = &vpr->start_page[pageno + i]; 680 681 return buffer; 682 683 free: 684 kfree(buffer->pages); 685 kfree(buffer); 686 release: 687 bitmap_release_region(vpr->bitmap, pageno, order); 688 return ERR_PTR(err); 689 } 690 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

3 weeks, 1 day

1
0
0 0

Re: [PATCH v2 04/10] mm/cma: Allow dynamically creating CMA areas

by kernel test robot

Hi Thierry, kernel test robot noticed the following build errors: [auto build test ERROR on akpm-mm/mm-everything] [also build test ERROR on next-20260122] [cannot apply to drm-misc/drm-misc-next robh/for-next linus/master v6.19-rc6] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Thierry-Reding/dt-bindings-r… base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything patch link: https://lore.kernel.org/r/20260122161009.3865888-5-thierry.reding%40kernel.… patch subject: [PATCH v2 04/10] mm/cma: Allow dynamically creating CMA areas config: i386-buildonly-randconfig-003-20260123 (https://download.01.org/0day-ci/archive/20260123/202601231051.5GWCp3mt-lkp@…) compiler: gcc-14 (Debian 14.2.0-19) 14.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260123/202601231051.5GWCp3mt-lkp@…) 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 <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202601231051.5GWCp3mt-lkp@intel.com/ All errors (new ones prefixed by >>): mm/cma_debug.c: In function 'cma_debugfs_init': >> mm/cma_debug.c:207:25: error: 'cma_area_count' undeclared (first use in this function) 207 | for (i = 0; i < cma_area_count; i++) | ^~~~~~~~~~~~~~ mm/cma_debug.c:207:25: note: each undeclared identifier is reported only once for each function it appears in >> mm/cma_debug.c:208:38: error: 'cma_areas' undeclared (first use in this function); did you mean 'cma_free'? 208 | cma_debugfs_add_one(&cma_areas[i], cma_debugfs_root); | ^~~~~~~~~ | cma_free vim +/cma_area_count +207 mm/cma_debug.c 28b24c1fc8c22c Sasha Levin 2015-04-14 199 28b24c1fc8c22c Sasha Levin 2015-04-14 200 static int __init cma_debugfs_init(void) 28b24c1fc8c22c Sasha Levin 2015-04-14 201 { 5a7f1b2f2fbeb4 Yue Hu 2019-03-05 202 struct dentry *cma_debugfs_root; 28b24c1fc8c22c Sasha Levin 2015-04-14 203 int i; 28b24c1fc8c22c Sasha Levin 2015-04-14 204 28b24c1fc8c22c Sasha Levin 2015-04-14 205 cma_debugfs_root = debugfs_create_dir("cma", NULL); 28b24c1fc8c22c Sasha Levin 2015-04-14 206 28b24c1fc8c22c Sasha Levin 2015-04-14 @207 for (i = 0; i < cma_area_count; i++) 5a7f1b2f2fbeb4 Yue Hu 2019-03-05 @208 cma_debugfs_add_one(&cma_areas[i], cma_debugfs_root); -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

3 weeks, 1 day

1
0
0 0

Re: [PATCH v2 04/10] mm/cma: Allow dynamically creating CMA areas

by kernel test robot

Hi Thierry, kernel test robot noticed the following build errors: [auto build test ERROR on akpm-mm/mm-everything] [also build test ERROR on next-20260122] [cannot apply to drm-misc/drm-misc-next robh/for-next linus/master v6.19-rc6] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Thierry-Reding/dt-bindings-r… base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything patch link: https://lore.kernel.org/r/20260122161009.3865888-5-thierry.reding%40kernel.… patch subject: [PATCH v2 04/10] mm/cma: Allow dynamically creating CMA areas config: openrisc-randconfig-r072-20260123 (https://download.01.org/0day-ci/archive/20260123/202601231052.RfGOFd3g-lkp@…) compiler: or1k-linux-gcc (GCC) 15.2.0 smatch version: v0.5.0-8994-gd50c5a4c reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260123/202601231052.RfGOFd3g-lkp@…) 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 <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202601231052.RfGOFd3g-lkp@intel.com/ All errors (new ones prefixed by >>): mm/cma_sysfs.c: In function 'cma_sysfs_init': >> mm/cma_sysfs.c:119:25: error: 'cma_area_count' undeclared (first use in this function); did you mean 'cma_early_area_count'? 119 | for (i = 0; i < cma_area_count; i++) { | ^~~~~~~~~~~~~~ | cma_early_area_count mm/cma_sysfs.c:119:25: note: each undeclared identifier is reported only once for each function it appears in >> mm/cma_sysfs.c:126:24: error: 'cma_areas' undeclared (first use in this function); did you mean 'cma_attrs'? 126 | cma = &cma_areas[i]; | ^~~~~~~~~ | cma_attrs vim +119 mm/cma_sysfs.c 43ca106fa8ec7d Minchan Kim 2021-05-04 107 43ca106fa8ec7d Minchan Kim 2021-05-04 108 static int __init cma_sysfs_init(void) 43ca106fa8ec7d Minchan Kim 2021-05-04 109 { 43ca106fa8ec7d Minchan Kim 2021-05-04 110 struct kobject *cma_kobj_root; 43ca106fa8ec7d Minchan Kim 2021-05-04 111 struct cma_kobject *cma_kobj; 43ca106fa8ec7d Minchan Kim 2021-05-04 112 struct cma *cma; 43ca106fa8ec7d Minchan Kim 2021-05-04 113 int i, err; 43ca106fa8ec7d Minchan Kim 2021-05-04 114 43ca106fa8ec7d Minchan Kim 2021-05-04 115 cma_kobj_root = kobject_create_and_add("cma", mm_kobj); 43ca106fa8ec7d Minchan Kim 2021-05-04 116 if (!cma_kobj_root) 43ca106fa8ec7d Minchan Kim 2021-05-04 117 return -ENOMEM; 43ca106fa8ec7d Minchan Kim 2021-05-04 118 43ca106fa8ec7d Minchan Kim 2021-05-04 @119 for (i = 0; i < cma_area_count; i++) { 43ca106fa8ec7d Minchan Kim 2021-05-04 120 cma_kobj = kzalloc(sizeof(*cma_kobj), GFP_KERNEL); 43ca106fa8ec7d Minchan Kim 2021-05-04 121 if (!cma_kobj) { 43ca106fa8ec7d Minchan Kim 2021-05-04 122 err = -ENOMEM; 43ca106fa8ec7d Minchan Kim 2021-05-04 123 goto out; 43ca106fa8ec7d Minchan Kim 2021-05-04 124 } 43ca106fa8ec7d Minchan Kim 2021-05-04 125 43ca106fa8ec7d Minchan Kim 2021-05-04 @126 cma = &cma_areas[i]; -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

3 weeks, 1 day

1
0
0 0

Re: [PATCH v2 00/10] dma-bug: heaps: Add Tegra VPR support

by Rob Herring

On Thu, 22 Jan 2026 17:09:59 +0100, Thierry Reding wrote: > From: Thierry Reding <treding(a)nvidia.com> > > Hi, > > This series adds support for the video protection region (VPR) used on > Tegra SoC devices. It's a special region of memory that is protected > from accesses by the CPU and used to store DRM protected content (both > decrypted stream data as well as decoded video frames). > > Patches 1 and 2 add DT binding documentation for the VPR and add the VPR > to the list of memory-region items for display and host1x. > > Patch 3 adds bitmap_allocate(), which is like bitmap_allocate_region() > but works on sizes that are not a power of two. > > Patch 4 introduces new APIs needed by the Tegra VPR implementation that > allow CMA areas to be dynamically created at runtime rather than using > the fixed, system-wide list. This is used in this driver specifically > because it can use an arbitrary number of these areas (though they are > currently limited to 4). > > Patch 5 adds some infrastructure for DMA heap implementations to provide > information through debugfs. > > The Tegra VPR implementation is added in patch 6. See its commit message > for more details about the specifics of this implementation. > > Finally, patches 7-10 add the VPR placeholder node on Tegra234 and hook > it up to the host1x and GPU nodes so that they can make use of this > region. > > Changes in v2: > - Tegra VPR implementation is now more optimized to reduce the number of > (very slow) resize operations, and allows cross-chunk allocations > - dynamic CMA areas are now trackd separately from static ones, but the > global number of CMA pages accounts for all areas > > Thierry > > Thierry Reding (10): > dt-bindings: reserved-memory: Document Tegra VPR > dt-bindings: display: tegra: Document memory regions > bitmap: Add bitmap_allocate() function > mm/cma: Allow dynamically creating CMA areas > dma-buf: heaps: Add debugfs support > dma-buf: heaps: Add support for Tegra VPR > arm64: tegra: Add VPR placeholder node on Tegra234 > arm64: tegra: Add GPU node on Tegra234 > arm64: tegra: Hook up VPR to host1x > arm64: tegra: Hook up VPR to the GPU > > .../display/tegra/nvidia,tegra186-dc.yaml | 10 + > .../display/tegra/nvidia,tegra20-dc.yaml | 10 +- > .../display/tegra/nvidia,tegra20-host1x.yaml | 7 + > .../nvidia,tegra-video-protection-region.yaml | 55 + > arch/arm/mm/dma-mapping.c | 2 +- > arch/arm64/boot/dts/nvidia/tegra234.dtsi | 60 + > arch/s390/mm/init.c | 2 +- > drivers/dma-buf/dma-heap.c | 56 + > drivers/dma-buf/heaps/Kconfig | 7 + > drivers/dma-buf/heaps/Makefile | 1 + > drivers/dma-buf/heaps/cma_heap.c | 2 +- > drivers/dma-buf/heaps/tegra-vpr.c | 1265 +++++++++++++++++ > include/linux/bitmap.h | 25 +- > include/linux/cma.h | 7 +- > include/linux/dma-heap.h | 2 + > include/trace/events/tegra_vpr.h | 57 + > mm/cma.c | 187 ++- > mm/cma.h | 5 +- > 18 files changed, 1713 insertions(+), 47 deletions(-) > create mode 100644 Documentation/devicetree/bindings/reserved-memory/nvidia,tegra-video-protection-region.yaml > create mode 100644 drivers/dma-buf/heaps/tegra-vpr.c > create mode 100644 include/trace/events/tegra_vpr.h > > -- > 2.52.0 > > > My bot found new DTB warnings on the .dts files added or changed in this series. Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings are fixed by another series. Ultimately, it is up to the platform maintainer whether these warnings are acceptable or not. No need to reply unless the platform maintainer has comments. If you already ran DT checks and didn't see these error(s), then make sure dt-schema is up to date: pip3 install dtschema --upgrade This patch series was applied (using b4) to base: Base: attempting to guess base-commit... Base: tags/next-20260121 (exact match) Base: tags/next-20260121 (use --merge-base to override) If this is not the correct base, please add 'base-commit' tag (or use b4 which does this automatically) New warnings running 'make CHECK_DTBS=y for arch/arm64/boot/dts/nvidia/' for 20260122161009.3865888-1-thierry.reding(a)kernel.org: arch/arm64/boot/dts/nvidia/tegra234-p3740-0002+p3701-0008.dtb: video-protection-region@0 (nvidia,tegra-video-protection-region): {'compatible': ['nvidia,tegra-video-protection-region'], 'status': ['disabled'], 'no-map': True, 'reg': [[0, 0, 0, 0]], 'size': 1879048192, 'alignment': 1048576, 'reusable': True, 'phandle': 263, '$nodename': ['video-protection-region@0']} should not be valid under {'required': ['reusable']} from schema $id: http://devicetree.org/schemas/reserved-memory/nvidia,tegra-video-protection… arch/arm64/boot/dts/nvidia/tegra234-p3740-0002+p3701-0008.dtb: video-protection-region@0 (nvidia,tegra-video-protection-region): {'compatible': ['nvidia,tegra-video-protection-region'], 'status': ['disabled'], 'no-map': True, 'reg': [[0, 0, 0, 0]], 'size': 1879048192, 'alignment': 1048576, 'reusable': True, 'phandle': 263, '$nodename': ['video-protection-region@0']} should not be valid under {'required': ['no-map']} from schema $id: http://devicetree.org/schemas/reserved-memory/nvidia,tegra-video-protection… arch/arm64/boot/dts/nvidia/tegra234-p3740-0002+p3701-0008.dtb: video-protection-region@0 (nvidia,tegra-video-protection-region): 'oneOf' conditional failed, one must be fixed: {'compatible': ['nvidia,tegra-video-protection-region'], 'status': ['disabled'], 'no-map': True, 'reg': [[0, 0, 0, 0]], 'size': 1879048192, 'alignment': 1048576, 'reusable': True, 'phandle': 263, '$nodename': ['video-protection-region@0']} is valid under each of {'required': ['size']}, {'required': ['reg']} arch/arm64/boot/dts/nvidia/tegra234-p3740-0002+p3701-0008.dtb: video-protection-region@0 (nvidia,tegra-video-protection-region): 'oneOf' conditional failed, one must be fixed: 'iommu-addresses' is a required property from schema $id: http://devicetree.org/schemas/reserved-memory/nvidia,tegra-video-protection… arch/arm64/boot/dts/nvidia/tegra234-p3740-0002+p3701-0008.dtb: video-protection-region@0 (nvidia,tegra-video-protection-region): {'compatible': ['nvidia,tegra-video-protection-region'], 'status': ['disabled'], 'no-map': True, 'reg': [[0, 0, 0, 0]], 'size': 1879048192, 'alignment': 1048576, 'reusable': True, 'phandle': 263, '$nodename': ['video-protection-region@0']} is valid under each of {'required': ['compatible', 'size']}, {'required': ['compatible', 'reg']} from schema $id: http://devicetree.org/schemas/reserved-memory/nvidia,tegra-video-protection… arch/arm64/boot/dts/nvidia/tegra234-sim-vdk.dtb: video-protection-region@0 (nvidia,tegra-video-protection-region): {'compatible': ['nvidia,tegra-video-protection-region'], 'status': ['disabled'], 'no-map': True, 'reg': [[0, 0, 0, 0]], 'size': 1879048192, 'alignment': 1048576, 'reusable': True, 'phandle': 248, '$nodename': ['video-protection-region@0']} should not be valid under {'required': ['reusable']} from schema $id: http://devicetree.org/schemas/reserved-memory/nvidia,tegra-video-protection… arch/arm64/boot/dts/nvidia/tegra234-sim-vdk.dtb: video-protection-region@0 (nvidia,tegra-video-protection-region): {'compatible': ['nvidia,tegra-video-protection-region'], 'status': ['disabled'], 'no-map': True, 'reg': [[0, 0, 0, 0]], 'size': 1879048192, 'alignment': 1048576, 'reusable': True, 'phandle': 248, '$nodename': ['video-protection-region@0']} should not be valid under {'required': ['no-map']} from schema $id: http://devicetree.org/schemas/reserved-memory/nvidia,tegra-video-protection… arch/arm64/boot/dts/nvidia/tegra234-sim-vdk.dtb: video-protection-region@0 (nvidia,tegra-video-protection-region): 'oneOf' conditional failed, one must be fixed: {'compatible': ['nvidia,tegra-video-protection-region'], 'status': ['disabled'], 'no-map': True, 'reg': [[0, 0, 0, 0]], 'size': 1879048192, 'alignment': 1048576, 'reusable': True, 'phandle': 248, '$nodename': ['video-protection-region@0']} is valid under each of {'required': ['size']}, {'required': ['reg']} arch/arm64/boot/dts/nvidia/tegra234-sim-vdk.dtb: video-protection-region@0 (nvidia,tegra-video-protection-region): 'oneOf' conditional failed, one must be fixed: 'iommu-addresses' is a required property from schema $id: http://devicetree.org/schemas/reserved-memory/nvidia,tegra-video-protection… arch/arm64/boot/dts/nvidia/tegra234-sim-vdk.dtb: video-protection-region@0 (nvidia,tegra-video-protection-region): {'compatible': ['nvidia,tegra-video-protection-region'], 'status': ['disabled'], 'no-map': True, 'reg': [[0, 0, 0, 0]], 'size': 1879048192, 'alignment': 1048576, 'reusable': True, 'phandle': 248, '$nodename': ['video-protection-region@0']} is valid under each of {'required': ['compatible', 'size']}, {'required': ['compatible', 'reg']} from schema $id: http://devicetree.org/schemas/reserved-memory/nvidia,tegra-video-protection… arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767-0000.dtb: video-protection-region@0 (nvidia,tegra-video-protection-region): {'compatible': ['nvidia,tegra-video-protection-region'], 'status': ['disabled'], 'no-map': True, 'reg': [[0, 0, 0, 0]], 'size': 1879048192, 'alignment': 1048576, 'reusable': True, 'phandle': 260, '$nodename': ['video-protection-region@0']} should not be valid under {'required': ['reusable']} from schema $id: http://devicetree.org/schemas/reserved-memory/nvidia,tegra-video-protection… arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767-0000.dtb: video-protection-region@0 (nvidia,tegra-video-protection-region): {'compatible': ['nvidia,tegra-video-protection-region'], 'status': ['disabled'], 'no-map': True, 'reg': [[0, 0, 0, 0]], 'size': 1879048192, 'alignment': 1048576, 'reusable': True, 'phandle': 260, '$nodename': ['video-protection-region@0']} should not be valid under {'required': ['no-map']} from schema $id: http://devicetree.org/schemas/reserved-memory/nvidia,tegra-video-protection… arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767-0000.dtb: video-protection-region@0 (nvidia,tegra-video-protection-region): 'oneOf' conditional failed, one must be fixed: {'compatible': ['nvidia,tegra-video-protection-region'], 'status': ['disabled'], 'no-map': True, 'reg': [[0, 0, 0, 0]], 'size': 1879048192, 'alignment': 1048576, 'reusable': True, 'phandle': 260, '$nodename': ['video-protection-region@0']} is valid under each of {'required': ['size']}, {'required': ['reg']} arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767-0000.dtb: video-protection-region@0 (nvidia,tegra-video-protection-region): 'oneOf' conditional failed, one must be fixed: 'iommu-addresses' is a required property from schema $id: http://devicetree.org/schemas/reserved-memory/nvidia,tegra-video-protection… arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767-0000.dtb: video-protection-region@0 (nvidia,tegra-video-protection-region): {'compatible': ['nvidia,tegra-video-protection-region'], 'status': ['disabled'], 'no-map': True, 'reg': [[0, 0, 0, 0]], 'size': 1879048192, 'alignment': 1048576, 'reusable': True, 'phandle': 260, '$nodename': ['video-protection-region@0']} is valid under each of {'required': ['compatible', 'size']}, {'required': ['compatible', 'reg']} from schema $id: http://devicetree.org/schemas/reserved-memory/nvidia,tegra-video-protection… arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767-0005.dtb: video-protection-region@0 (nvidia,tegra-video-protection-region): {'compatible': ['nvidia,tegra-video-protection-region'], 'status': ['disabled'], 'no-map': True, 'reg': [[0, 0, 0, 0]], 'size': 1879048192, 'alignment': 1048576, 'reusable': True, 'phandle': 260, '$nodename': ['video-protection-region@0']} should not be valid under {'required': ['reusable']} from schema $id: http://devicetree.org/schemas/reserved-memory/nvidia,tegra-video-protection… arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767-0005.dtb: video-protection-region@0 (nvidia,tegra-video-protection-region): {'compatible': ['nvidia,tegra-video-protection-region'], 'status': ['disabled'], 'no-map': True, 'reg': [[0, 0, 0, 0]], 'size': 1879048192, 'alignment': 1048576, 'reusable': True, 'phandle': 260, '$nodename': ['video-protection-region@0']} should not be valid under {'required': ['no-map']} from schema $id: http://devicetree.org/schemas/reserved-memory/nvidia,tegra-video-protection… arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767-0005.dtb: video-protection-region@0 (nvidia,tegra-video-protection-region): 'oneOf' conditional failed, one must be fixed: {'compatible': ['nvidia,tegra-video-protection-region'], 'status': ['disabled'], 'no-map': True, 'reg': [[0, 0, 0, 0]], 'size': 1879048192, 'alignment': 1048576, 'reusable': True, 'phandle': 260, '$nodename': ['video-protection-region@0']} is valid under each of {'required': ['size']}, {'required': ['reg']} arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767-0005.dtb: video-protection-region@0 (nvidia,tegra-video-protection-region): 'oneOf' conditional failed, one must be fixed: 'iommu-addresses' is a required property from schema $id: http://devicetree.org/schemas/reserved-memory/nvidia,tegra-video-protection… arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767-0005.dtb: video-protection-region@0 (nvidia,tegra-video-protection-region): {'compatible': ['nvidia,tegra-video-protection-region'], 'status': ['disabled'], 'no-map': True, 'reg': [[0, 0, 0, 0]], 'size': 1879048192, 'alignment': 1048576, 'reusable': True, 'phandle': 260, '$nodename': ['video-protection-region@0']} is valid under each of {'required': ['compatible', 'size']}, {'required': ['compatible', 'reg']} from schema $id: http://devicetree.org/schemas/reserved-memory/nvidia,tegra-video-protection… arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701-0000.dtb: video-protection-region@0 (nvidia,tegra-video-protection-region): {'compatible': ['nvidia,tegra-video-protection-region'], 'status': ['disabled'], 'no-map': True, 'reg': [[0, 0, 0, 0]], 'size': 1879048192, 'alignment': 1048576, 'reusable': True, 'phandle': 272, '$nodename': ['video-protection-region@0']} should not be valid under {'required': ['reusable']} from schema $id: http://devicetree.org/schemas/reserved-memory/nvidia,tegra-video-protection… arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701-0000.dtb: video-protection-region@0 (nvidia,tegra-video-protection-region): {'compatible': ['nvidia,tegra-video-protection-region'], 'status': ['disabled'], 'no-map': True, 'reg': [[0, 0, 0, 0]], 'size': 1879048192, 'alignment': 1048576, 'reusable': True, 'phandle': 272, '$nodename': ['video-protection-region@0']} should not be valid under {'required': ['no-map']} from schema $id: http://devicetree.org/schemas/reserved-memory/nvidia,tegra-video-protection… arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701-0000.dtb: video-protection-region@0 (nvidia,tegra-video-protection-region): 'oneOf' conditional failed, one must be fixed: {'compatible': ['nvidia,tegra-video-protection-region'], 'status': ['disabled'], 'no-map': True, 'reg': [[0, 0, 0, 0]], 'size': 1879048192, 'alignment': 1048576, 'reusable': True, 'phandle': 272, '$nodename': ['video-protection-region@0']} is valid under each of {'required': ['size']}, {'required': ['reg']} arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701-0000.dtb: video-protection-region@0 (nvidia,tegra-video-protection-region): 'oneOf' conditional failed, one must be fixed: 'iommu-addresses' is a required property from schema $id: http://devicetree.org/schemas/reserved-memory/nvidia,tegra-video-protection… arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701-0000.dtb: video-protection-region@0 (nvidia,tegra-video-protection-region): {'compatible': ['nvidia,tegra-video-protection-region'], 'status': ['disabled'], 'no-map': True, 'reg': [[0, 0, 0, 0]], 'size': 1879048192, 'alignment': 1048576, 'reusable': True, 'phandle': 272, '$nodename': ['video-protection-region@0']} is valid under each of {'required': ['compatible', 'size']}, {'required': ['compatible', 'reg']} from schema $id: http://devicetree.org/schemas/reserved-memory/nvidia,tegra-video-protection… arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701-0008.dtb: video-protection-region@0 (nvidia,tegra-video-protection-region): {'compatible': ['nvidia,tegra-video-protection-region'], 'status': ['disabled'], 'no-map': True, 'reg': [[0, 0, 0, 0]], 'size': 1879048192, 'alignment': 1048576, 'reusable': True, 'phandle': 272, '$nodename': ['video-protection-region@0']} should not be valid under {'required': ['reusable']} from schema $id: http://devicetree.org/schemas/reserved-memory/nvidia,tegra-video-protection… arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701-0008.dtb: video-protection-region@0 (nvidia,tegra-video-protection-region): {'compatible': ['nvidia,tegra-video-protection-region'], 'status': ['disabled'], 'no-map': True, 'reg': [[0, 0, 0, 0]], 'size': 1879048192, 'alignment': 1048576, 'reusable': True, 'phandle': 272, '$nodename': ['video-protection-region@0']} should not be valid under {'required': ['no-map']} from schema $id: http://devicetree.org/schemas/reserved-memory/nvidia,tegra-video-protection… arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701-0008.dtb: video-protection-region@0 (nvidia,tegra-video-protection-region): 'oneOf' conditional failed, one must be fixed: {'compatible': ['nvidia,tegra-video-protection-region'], 'status': ['disabled'], 'no-map': True, 'reg': [[0, 0, 0, 0]], 'size': 1879048192, 'alignment': 1048576, 'reusable': True, 'phandle': 272, '$nodename': ['video-protection-region@0']} is valid under each of {'required': ['size']}, {'required': ['reg']} arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701-0008.dtb: video-protection-region@0 (nvidia,tegra-video-protection-region): 'oneOf' conditional failed, one must be fixed: 'iommu-addresses' is a required property from schema $id: http://devicetree.org/schemas/reserved-memory/nvidia,tegra-video-protection… arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701-0008.dtb: video-protection-region@0 (nvidia,tegra-video-protection-region): {'compatible': ['nvidia,tegra-video-protection-region'], 'status': ['disabled'], 'no-map': True, 'reg': [[0, 0, 0, 0]], 'size': 1879048192, 'alignment': 1048576, 'reusable': True, 'phandle': 272, '$nodename': ['video-protection-region@0']} is valid under each of {'required': ['compatible', 'size']}, {'required': ['compatible', 'reg']} from schema $id: http://devicetree.org/schemas/reserved-memory/nvidia,tegra-video-protection… arch/arm64/boot/dts/nvidia/tegra234-sim-vdk.dtb: ethernet@6800000 (nvidia,tegra234-mgbe): 'snps,axi-config', 'stmmac-axi-config' do not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/net/nvidia,tegra234-mgbe.yaml arch/arm64/boot/dts/nvidia/tegra234-sim-vdk.dtb: ethernet@6900000 (nvidia,tegra234-mgbe): 'snps,axi-config', 'stmmac-axi-config' do not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/net/nvidia,tegra234-mgbe.yaml arch/arm64/boot/dts/nvidia/tegra234-sim-vdk.dtb: ethernet@6a00000 (nvidia,tegra234-mgbe): 'snps,axi-config', 'stmmac-axi-config' do not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/net/nvidia,tegra234-mgbe.yaml arch/arm64/boot/dts/nvidia/tegra234-sim-vdk.dtb: vic@15340000 (nvidia,tegra234-vic): 'memory-region', 'memory-region-names' do not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/display/tegra/nvidia,tegra124-vic.yaml arch/arm64/boot/dts/nvidia/tegra234-sim-vdk.dtb: nvdec@15480000 (nvidia,tegra234-nvdec): 'memory-region', 'memory-region-names' do not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/gpu/host1x/nvidia,tegra234-nvdec.yaml arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701-0000.dtb: /bus@0/i2c@31e0000/audio-codec@1c: failed to match any schema with compatible: ['realtek,rt5640'] arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767-0000.dtb: padctl@3520000 (nvidia,tegra234-xusb-padctl): ports:usb2-0: 'connector' is a dependency of 'usb-role-switch' from schema $id: http://devicetree.org/schemas/phy/nvidia,tegra194-xusb-padctl.yaml arch/arm64/boot/dts/nvidia/tegra234-sim-vdk.dtb: /gpu@17000000: failed to match any schema with compatible: ['nvidia,ga10b'] arch/arm64/boot/dts/nvidia/tegra234-p3740-0002+p3701-0008.dtb: /bus@0/i2c@31c0000/audio-codec@1c: failed to match any schema with compatible: ['realtek,rt5640'] arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701-0000.dtb: padctl@3520000 (nvidia,tegra234-xusb-padctl): ports:usb2-0: 'port' does not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/phy/nvidia,tegra194-xusb-padctl.yaml arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701-0000.dtb: padctl@3520000 (nvidia,tegra234-xusb-padctl): ports:usb2-0: 'connector' is a dependency of 'usb-role-switch' from schema $id: http://devicetree.org/schemas/phy/nvidia,tegra194-xusb-padctl.yaml arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701-0000.dtb: padctl@3520000 (nvidia,tegra234-xusb-padctl): ports:usb2-1: 'port' does not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/phy/nvidia,tegra194-xusb-padctl.yaml arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701-0000.dtb: padctl@3520000 (nvidia,tegra234-xusb-padctl): ports:usb3-0: 'port' does not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/phy/nvidia,tegra194-xusb-padctl.yaml arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701-0000.dtb: padctl@3520000 (nvidia,tegra234-xusb-padctl): ports:usb3-1: 'port' does not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/phy/nvidia,tegra194-xusb-padctl.yaml arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767-0000.dtb: ethernet@6800000 (nvidia,tegra234-mgbe): 'snps,axi-config', 'stmmac-axi-config' do not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/net/nvidia,tegra234-mgbe.yaml arch/arm64/boot/dts/nvidia/tegra234-p3740-0002+p3701-0008.dtb: padctl@3520000 (nvidia,tegra234-xusb-padctl): ports:usb2-0: 'connector' is a dependency of 'usb-role-switch' from schema $id: http://devicetree.org/schemas/phy/nvidia,tegra194-xusb-padctl.yaml arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767-0000.dtb: ethernet@6900000 (nvidia,tegra234-mgbe): 'snps,axi-config', 'stmmac-axi-config' do not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/net/nvidia,tegra234-mgbe.yaml arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767-0000.dtb: ethernet@6a00000 (nvidia,tegra234-mgbe): 'snps,axi-config', 'stmmac-axi-config' do not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/net/nvidia,tegra234-mgbe.yaml arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701-0000.dtb: ethernet@6800000 (nvidia,tegra234-mgbe): 'snps,axi-config', 'stmmac-axi-config' do not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/net/nvidia,tegra234-mgbe.yaml arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701-0000.dtb: ethernet@6800000 (nvidia,tegra234-mgbe): phy-mode: ['10gbase-r'] does not contain items matching the given schema from schema $id: http://devicetree.org/schemas/net/nvidia,tegra234-mgbe.yaml arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701-0000.dtb: ethernet@6900000 (nvidia,tegra234-mgbe): 'snps,axi-config', 'stmmac-axi-config' do not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/net/nvidia,tegra234-mgbe.yaml arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701-0000.dtb: ethernet@6a00000 (nvidia,tegra234-mgbe): 'snps,axi-config', 'stmmac-axi-config' do not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/net/nvidia,tegra234-mgbe.yaml arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767-0000.dtb: vic@15340000 (nvidia,tegra234-vic): 'memory-region', 'memory-region-names' do not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/display/tegra/nvidia,tegra124-vic.yaml arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767-0000.dtb: nvdec@15480000 (nvidia,tegra234-nvdec): 'memory-region', 'memory-region-names' do not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/gpu/host1x/nvidia,tegra234-nvdec.yaml arch/arm64/boot/dts/nvidia/tegra234-p3740-0002+p3701-0008.dtb: ethernet@6800000 (nvidia,tegra234-mgbe): 'snps,axi-config', 'stmmac-axi-config' do not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/net/nvidia,tegra234-mgbe.yaml arch/arm64/boot/dts/nvidia/tegra234-p3740-0002+p3701-0008.dtb: ethernet@6900000 (nvidia,tegra234-mgbe): 'snps,axi-config', 'stmmac-axi-config' do not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/net/nvidia,tegra234-mgbe.yaml arch/arm64/boot/dts/nvidia/tegra234-p3740-0002+p3701-0008.dtb: ethernet@6a00000 (nvidia,tegra234-mgbe): 'snps,axi-config', 'stmmac-axi-config' do not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/net/nvidia,tegra234-mgbe.yaml arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701-0000.dtb: vic@15340000 (nvidia,tegra234-vic): 'memory-region', 'memory-region-names' do not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/display/tegra/nvidia,tegra124-vic.yaml arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701-0000.dtb: nvdec@15480000 (nvidia,tegra234-nvdec): 'memory-region', 'memory-region-names' do not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/gpu/host1x/nvidia,tegra234-nvdec.yaml arch/arm64/boot/dts/nvidia/tegra234-p3740-0002+p3701-0008.dtb: vic@15340000 (nvidia,tegra234-vic): 'memory-region', 'memory-region-names' do not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/display/tegra/nvidia,tegra124-vic.yaml arch/arm64/boot/dts/nvidia/tegra234-p3740-0002+p3701-0008.dtb: nvdec@15480000 (nvidia,tegra234-nvdec): 'memory-region', 'memory-region-names' do not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/gpu/host1x/nvidia,tegra234-nvdec.yaml arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767-0000.dtb: /gpu@17000000: failed to match any schema with compatible: ['nvidia,ga10b'] arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701-0000.dtb: /gpu@17000000: failed to match any schema with compatible: ['nvidia,ga10b'] arch/arm64/boot/dts/nvidia/tegra234-p3740-0002+p3701-0008.dtb: /gpu@17000000: failed to match any schema with compatible: ['nvidia,ga10b'] arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767-0005.dtb: padctl@3520000 (nvidia,tegra234-xusb-padctl): ports:usb2-0: 'connector' is a dependency of 'usb-role-switch' from schema $id: http://devicetree.org/schemas/phy/nvidia,tegra194-xusb-padctl.yaml arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767-0005.dtb: ethernet@6800000 (nvidia,tegra234-mgbe): 'snps,axi-config', 'stmmac-axi-config' do not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/net/nvidia,tegra234-mgbe.yaml arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767-0005.dtb: ethernet@6900000 (nvidia,tegra234-mgbe): 'snps,axi-config', 'stmmac-axi-config' do not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/net/nvidia,tegra234-mgbe.yaml arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767-0005.dtb: ethernet@6a00000 (nvidia,tegra234-mgbe): 'snps,axi-config', 'stmmac-axi-config' do not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/net/nvidia,tegra234-mgbe.yaml arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767-0005.dtb: vic@15340000 (nvidia,tegra234-vic): 'memory-region', 'memory-region-names' do not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/display/tegra/nvidia,tegra124-vic.yaml arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767-0005.dtb: nvdec@15480000 (nvidia,tegra234-nvdec): 'memory-region', 'memory-region-names' do not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/gpu/host1x/nvidia,tegra234-nvdec.yaml arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767-0005.dtb: /gpu@17000000: failed to match any schema with compatible: ['nvidia,ga10b'] arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701-0008.dtb: /bus@0/i2c@31e0000/audio-codec@1c: failed to match any schema with compatible: ['realtek,rt5640'] arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701-0008.dtb: padctl@3520000 (nvidia,tegra234-xusb-padctl): ports:usb2-0: 'port' does not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/phy/nvidia,tegra194-xusb-padctl.yaml arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701-0008.dtb: padctl@3520000 (nvidia,tegra234-xusb-padctl): ports:usb2-0: 'connector' is a dependency of 'usb-role-switch' from schema $id: http://devicetree.org/schemas/phy/nvidia,tegra194-xusb-padctl.yaml arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701-0008.dtb: padctl@3520000 (nvidia,tegra234-xusb-padctl): ports:usb2-1: 'port' does not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/phy/nvidia,tegra194-xusb-padctl.yaml arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701-0008.dtb: padctl@3520000 (nvidia,tegra234-xusb-padctl): ports:usb3-0: 'port' does not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/phy/nvidia,tegra194-xusb-padctl.yaml arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701-0008.dtb: padctl@3520000 (nvidia,tegra234-xusb-padctl): ports:usb3-1: 'port' does not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/phy/nvidia,tegra194-xusb-padctl.yaml arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701-0008.dtb: ethernet@6800000 (nvidia,tegra234-mgbe): 'snps,axi-config', 'stmmac-axi-config' do not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/net/nvidia,tegra234-mgbe.yaml arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701-0008.dtb: ethernet@6800000 (nvidia,tegra234-mgbe): phy-mode: ['10gbase-r'] does not contain items matching the given schema from schema $id: http://devicetree.org/schemas/net/nvidia,tegra234-mgbe.yaml arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701-0008.dtb: ethernet@6900000 (nvidia,tegra234-mgbe): 'snps,axi-config', 'stmmac-axi-config' do not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/net/nvidia,tegra234-mgbe.yaml arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701-0008.dtb: ethernet@6a00000 (nvidia,tegra234-mgbe): 'snps,axi-config', 'stmmac-axi-config' do not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/net/nvidia,tegra234-mgbe.yaml arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701-0008.dtb: vic@15340000 (nvidia,tegra234-vic): 'memory-region', 'memory-region-names' do not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/display/tegra/nvidia,tegra124-vic.yaml arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701-0008.dtb: nvdec@15480000 (nvidia,tegra234-nvdec): 'memory-region', 'memory-region-names' do not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/gpu/host1x/nvidia,tegra234-nvdec.yaml arch/arm64/boot/dts/nvidia/tegra234-p3737-0000+p3701-0008.dtb: /gpu@17000000: failed to match any schema with compatible: ['nvidia,ga10b']

3 weeks, 1 day

1
0
0 0

Re: [PATCH v2 02/10] dt-bindings: display: tegra: Document memory regions

by Rob Herring (Arm)

On Thu, 22 Jan 2026 17:10:01 +0100, Thierry Reding wrote: > From: Thierry Reding <treding(a)nvidia.com> > > Add the memory-region and memory-region-names properties to the bindings > for the display controllers and the host1x engine found on various Tegra > generations. These memory regions are used to access firmware-provided > framebuffer memory as well as the video protection region. > > Signed-off-by: Thierry Reding <treding(a)nvidia.com> > --- > .../bindings/display/tegra/nvidia,tegra186-dc.yaml | 10 ++++++++++ > .../bindings/display/tegra/nvidia,tegra20-dc.yaml | 10 +++++++++- > .../bindings/display/tegra/nvidia,tegra20-host1x.yaml | 7 +++++++ > 3 files changed, 26 insertions(+), 1 deletion(-) > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dc.yaml: properties:memory-region-names: 'anyOf' conditional failed, one must be fixed: 'maxitems' is not one of ['$ref', 'additionalItems', 'additionalProperties', 'allOf', 'anyOf', 'const', 'contains', 'default', 'dependencies', 'dependentRequired', 'dependentSchemas', 'deprecated', 'description', 'else', 'enum', 'exclusiveMaximum', 'exclusiveMinimum', 'items', 'if', 'minItems', 'minimum', 'maxItems', 'maximum', 'multipleOf', 'not', 'oneOf', 'pattern', 'patternProperties', 'properties', 'required', 'then', 'typeSize', 'unevaluatedProperties', 'uniqueItems'] 'type' was expected from schema $id: http://devicetree.org/meta-schemas/keywords.yaml /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dc.yaml: properties:memory-region-names:items: {'enum': ['framebuffer', 'protected']} is not of type 'array' from schema $id: http://devicetree.org/meta-schemas/string-array.yaml /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dc.yaml: properties:memory-region-names: Additional properties are not allowed ('maxitems' was unexpected) from schema $id: http://devicetree.org/meta-schemas/string-array.yaml /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dc.yaml: properties:memory-region-names:items: {'enum': ['framebuffer', 'protected']} is not of type 'array' from schema $id: http://devicetree.org/meta-schemas/string-array.yaml /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dc.yaml: properties:memory-region-names: Additional properties are not allowed ('maxitems' was unexpected) from schema $id: http://devicetree.org/meta-schemas/string-array.yaml doc reference errors (make refcheckdocs): See https://patchwork.kernel.org/project/devicetree/patch/20260122161009.386588… The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.

3 weeks, 1 day

1
0
0 0

Re: [PATCH v4 8/8] vfio: Validate dma-buf revocation semantics

by Jason Gunthorpe

On Wed, Jan 21, 2026 at 02:47:29PM +0000, Pranjal Shrivastava wrote: > But at the same time, I'd like to discuss if we should think about > changing the dmabuf core, NULL op == success feels like relying on a bug Agree, IMHO, it is surprising and counter intuitive in the kernel that a NULL op means the feature is supported and default to success. Jason

3 weeks, 3 days

1
0
0 0

[PATCH v4 0/8] dma-buf: Use revoke mechanism to invalidate shared buffers

by Leon Romanovsky

Changelog: v4: * Changed DMA_RESV_USAGE_KERNEL to DMA_RESV_USAGE_BOOKKEEP. * Made .invalidate_mapping() truly optional. * Added patch which renames dma_buf_move_notify() to be dma_buf_invalidate_mappings(). * Restored dma_buf_attachment_is_dynamic() function. v3: https://lore.kernel.org/all/20260120-dmabuf-revoke-v3-0-b7e0b07b8214@nvidia… * Used Jason's wordings for commits and cover letter. * Removed IOMMUFD patch. * Renamed dma_buf_attachment_is_revoke() to be dma_buf_attach_revocable(). * Added patch to remove CONFIG_DMABUF_MOVE_NOTIFY. * Added Reviewed-by tags. * Called to dma_resv_wait_timeout() after dma_buf_move_notify() in VFIO. * Added dma_buf_attach_revocable() check to VFIO DMABUF attach function. * Slightly changed commit messages. v2: https://patch.msgid.link/20260118-dmabuf-revoke-v2-0-a03bb27c0875@nvidia.com * Changed series to document the revoke semantics instead of implementing it. v1: https://patch.msgid.link/20260111-dmabuf-revoke-v1-0-fb4bcc8c259b@nvidia.com ------------------------------------------------------------------------- This series documents a dma-buf “revoke” mechanism: to allow a dma-buf exporter to explicitly invalidate (“kill”) a shared buffer after it has been distributed to importers, so that further CPU and device access is prevented and importers reliably observe failure. The change in this series is to properly document and use existing core “revoked” state on the dma-buf object and a corresponding exporter-triggered revoke operation. dma-buf has quietly allowed calling move_notify on pinned dma-bufs, even though legacy importers using dma_buf_attach() would simply ignore these calls. RDMA saw this and needed to use allow_peer2peer=true, so implemented a new-style pinned importer with an explicitly non-working move_notify() callback. This has been tolerable because the existing exporters are thought to only call move_notify() on a pinned DMABUF under RAS events and we have been willing to tolerate the UAF that results by allowing the importer to continue to use the mapping in this rare case. VFIO wants to implement a pin supporting exporter that will issue a revoking move_notify() around FLRs and a few other user triggerable operations. Since this is much more common we are not willing to tolerate the security UAF caused by interworking with non-move_notify() supporting drivers. Thus till now VFIO has required dynamic importers, even though it never actually moves the buffer location. To allow VFIO to work with pinned importers, according to how dma-buf was intended, we need to allow VFIO to detect if an importer is legacy or RDMA and does not actually implement move_notify(). In theory all exporters that call move_notify() on pinned dma-buf's should call this function, however that would break a number of widely used NIC/GPU flows. Thus for now do not spread this further than VFIO until we can understand how much of RDMA can implement the full semantic. In the process clarify how move_notify is intended to be used with pinned dma-bufs. Thanks Signed-off-by: Leon Romanovsky <leonro(a)nvidia.com> --- Leon Romanovsky (8): dma-buf: Rename .move_notify() callback to a clearer identifier dma-buf: Rename dma_buf_move_notify() to dma_buf_invalidate_mappings() dma-buf: Always build with DMABUF_MOVE_NOTIFY dma-buf: Make .invalidate_mapping() truly optional dma-buf: Add check function for revoke semantics iommufd: Pin dma-buf importer for revoke semantics vfio: Wait for dma-buf invalidation to complete vfio: Validate dma-buf revocation semantics drivers/dma-buf/Kconfig | 12 ------- drivers/dma-buf/dma-buf.c | 53 ++++++++++++++++++++++------- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 14 +++----- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +- drivers/gpu/drm/amd/amdkfd/Kconfig | 2 +- drivers/gpu/drm/virtio/virtgpu_prime.c | 2 +- drivers/gpu/drm/xe/tests/xe_dma_buf.c | 7 ++-- drivers/gpu/drm/xe/xe_bo.c | 2 +- drivers/gpu/drm/xe/xe_dma_buf.c | 14 +++----- drivers/infiniband/core/umem_dmabuf.c | 13 ------- drivers/infiniband/hw/mlx5/mr.c | 2 +- drivers/iommu/iommufd/pages.c | 11 ++++-- drivers/iommu/iommufd/selftest.c | 2 +- drivers/vfio/pci/vfio_pci_dmabuf.c | 13 +++++-- include/linux/dma-buf.h | 9 ++--- 15 files changed, 84 insertions(+), 74 deletions(-) --- base-commit: 9ace4753a5202b02191d54e9fdf7f9e3d02b85eb change-id: 20251221-dmabuf-revoke-b90ef16e4236 Best regards, -- Leon Romanovsky <leonro(a)nvidia.com>

3 weeks, 3 days

3
13
0 0

Re: types: reuse common phys_vec type instead of DMABUF open‑coded variant

by Leon Romanovsky

On Mon, Jan 19, 2026 at 01:38:38PM -0700, Alex Williamson wrote: > On Wed, 7 Jan 2026 11:14:14 +0200 > Leon Romanovsky <leon(a)kernel.org> wrote: > > > From: Leon Romanovsky <leonro(a)nvidia.com> > > > > After commit fcf463b92a08 ("types: move phys_vec definition to common header"), > > we can use the shared phys_vec type instead of the DMABUF‑specific > > dma_buf_phys_vec, which duplicated the same structure and semantics. > > > > Signed-off-by: Leon Romanovsky <leonro(a)nvidia.com> > > --- > > Alex, > > > > According to diffstat, VFIO is the subsystem with the largest set of changes, > > so it would be great if you could take it through your tree. > > > > The series is based on the for-7.0/blk-pvec shared branch from Jens: > > https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux.git/log/?h=for-… > > Applied to vfio next branch for v6.20/7.0 and pushed tag > common_phys_vec_via_vfio including this commit and dependency. Thanks. I will pull it right before the RDMA dma-buf exporter patches are ready to be merged. Thanks again. > Thanks, > > Alex > > > > --- > > Cc: linux-media(a)vger.kernel.org > > Cc: dri-devel(a)lists.freedesktop.org > > Cc: linaro-mm-sig(a)lists.linaro.org > > Cc: linux-kernel(a)vger.kernel.org > > Cc: iommu(a)lists.linux.dev > > Cc: kvm(a)vger.kernel.org > > To: Sumit Semwal <sumit.semwal(a)linaro.org> > > To: Christian König <christian.koenig(a)amd.com> > > To: Jason Gunthorpe <jgg(a)ziepe.ca> > > To: Kevin Tian <kevin.tian(a)intel.com> > > To: Joerg Roedel <joro(a)8bytes.org> > > To: Will Deacon <will(a)kernel.org> > > To: Robin Murphy <robin.murphy(a)arm.com> > > To: Yishai Hadas <yishaih(a)nvidia.com> > > To: Shameer Kolothum <skolothumtho(a)nvidia.com> > > To: Ankit Agrawal <ankita(a)nvidia.com> > > To: Alex Williamson <alex(a)shazbot.org> > > Cc: Matthew Wilcox <willy(a)infradead.org> > > Cc: Jens Axboe <axboe(a)kernel.dk> > > --- > > drivers/dma-buf/dma-buf-mapping.c | 6 +++--- > > drivers/iommu/iommufd/io_pagetable.h | 2 +- > > drivers/iommu/iommufd/iommufd_private.h | 5 ++--- > > drivers/iommu/iommufd/pages.c | 4 ++-- > > drivers/iommu/iommufd/selftest.c | 2 +- > > drivers/vfio/pci/nvgrace-gpu/main.c | 2 +- > > drivers/vfio/pci/vfio_pci_dmabuf.c | 8 ++++---- > > include/linux/dma-buf-mapping.h | 2 +- > > include/linux/dma-buf.h | 10 ---------- > > include/linux/vfio_pci_core.h | 13 ++++++------- > > 10 files changed, 21 insertions(+), 33 deletions(-) > > > > diff --git a/drivers/dma-buf/dma-buf-mapping.c b/drivers/dma-buf/dma-buf-mapping.c > > index b7352e609fbd..174677faa577 100644 > > --- a/drivers/dma-buf/dma-buf-mapping.c > > +++ b/drivers/dma-buf/dma-buf-mapping.c > > @@ -33,8 +33,8 @@ static struct scatterlist *fill_sg_entry(struct scatterlist *sgl, size_t length, > > } > > > > static unsigned int calc_sg_nents(struct dma_iova_state *state, > > - struct dma_buf_phys_vec *phys_vec, > > - size_t nr_ranges, size_t size) > > + struct phys_vec *phys_vec, size_t nr_ranges, > > + size_t size) > > { > > unsigned int nents = 0; > > size_t i; > > @@ -91,7 +91,7 @@ struct dma_buf_dma { > > */ > > struct sg_table *dma_buf_phys_vec_to_sgt(struct dma_buf_attachment *attach, > > struct p2pdma_provider *provider, > > - struct dma_buf_phys_vec *phys_vec, > > + struct phys_vec *phys_vec, > > size_t nr_ranges, size_t size, > > enum dma_data_direction dir) > > { > > diff --git a/drivers/iommu/iommufd/io_pagetable.h b/drivers/iommu/iommufd/io_pagetable.h > > index 14cd052fd320..27e3e311d395 100644 > > --- a/drivers/iommu/iommufd/io_pagetable.h > > +++ b/drivers/iommu/iommufd/io_pagetable.h > > @@ -202,7 +202,7 @@ struct iopt_pages_dmabuf_track { > > > > struct iopt_pages_dmabuf { > > struct dma_buf_attachment *attach; > > - struct dma_buf_phys_vec phys; > > + struct phys_vec phys; > > /* Always PAGE_SIZE aligned */ > > unsigned long start; > > struct list_head tracker; > > diff --git a/drivers/iommu/iommufd/iommufd_private.h b/drivers/iommu/iommufd/iommufd_private.h > > index eb6d1a70f673..6ac1965199e9 100644 > > --- a/drivers/iommu/iommufd/iommufd_private.h > > +++ b/drivers/iommu/iommufd/iommufd_private.h > > @@ -20,7 +20,6 @@ struct iommu_group; > > struct iommu_option; > > struct iommufd_device; > > struct dma_buf_attachment; > > -struct dma_buf_phys_vec; > > > > struct iommufd_sw_msi_map { > > struct list_head sw_msi_item; > > @@ -718,7 +717,7 @@ int __init iommufd_test_init(void); > > void iommufd_test_exit(void); > > bool iommufd_selftest_is_mock_dev(struct device *dev); > > int iommufd_test_dma_buf_iommufd_map(struct dma_buf_attachment *attachment, > > - struct dma_buf_phys_vec *phys); > > + struct phys_vec *phys); > > #else > > static inline void iommufd_test_syz_conv_iova_id(struct iommufd_ucmd *ucmd, > > unsigned int ioas_id, > > @@ -742,7 +741,7 @@ static inline bool iommufd_selftest_is_mock_dev(struct device *dev) > > } > > static inline int > > iommufd_test_dma_buf_iommufd_map(struct dma_buf_attachment *attachment, > > - struct dma_buf_phys_vec *phys) > > + struct phys_vec *phys) > > { > > return -EOPNOTSUPP; > > } > > diff --git a/drivers/iommu/iommufd/pages.c b/drivers/iommu/iommufd/pages.c > > index dbe51ecb9a20..bababd564cf9 100644 > > --- a/drivers/iommu/iommufd/pages.c > > +++ b/drivers/iommu/iommufd/pages.c > > @@ -1077,7 +1077,7 @@ static int pfn_reader_user_update_pinned(struct pfn_reader_user *user, > > } > > > > struct pfn_reader_dmabuf { > > - struct dma_buf_phys_vec phys; > > + struct phys_vec phys; > > unsigned long start_offset; > > }; > > > > @@ -1460,7 +1460,7 @@ static struct dma_buf_attach_ops iopt_dmabuf_attach_revoke_ops = { > > */ > > static int > > sym_vfio_pci_dma_buf_iommufd_map(struct dma_buf_attachment *attachment, > > - struct dma_buf_phys_vec *phys) > > + struct phys_vec *phys) > > { > > typeof(&vfio_pci_dma_buf_iommufd_map) fn; > > int rc; > > diff --git a/drivers/iommu/iommufd/selftest.c b/drivers/iommu/iommufd/selftest.c > > index 550ff36dec3a..989d8c4c60a7 100644 > > --- a/drivers/iommu/iommufd/selftest.c > > +++ b/drivers/iommu/iommufd/selftest.c > > @@ -2002,7 +2002,7 @@ static const struct dma_buf_ops iommufd_test_dmabuf_ops = { > > }; > > > > int iommufd_test_dma_buf_iommufd_map(struct dma_buf_attachment *attachment, > > - struct dma_buf_phys_vec *phys) > > + struct phys_vec *phys) > > { > > struct iommufd_test_dma_buf *priv = attachment->dmabuf->priv; > > > > diff --git a/drivers/vfio/pci/nvgrace-gpu/main.c b/drivers/vfio/pci/nvgrace-gpu/main.c > > index 84d142a47ec6..a0f4edd6a30b 100644 > > --- a/drivers/vfio/pci/nvgrace-gpu/main.c > > +++ b/drivers/vfio/pci/nvgrace-gpu/main.c > > @@ -784,7 +784,7 @@ nvgrace_gpu_write(struct vfio_device *core_vdev, > > static int nvgrace_get_dmabuf_phys(struct vfio_pci_core_device *core_vdev, > > struct p2pdma_provider **provider, > > unsigned int region_index, > > - struct dma_buf_phys_vec *phys_vec, > > + struct phys_vec *phys_vec, > > struct vfio_region_dma_range *dma_ranges, > > size_t nr_ranges) > > { > > diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c b/drivers/vfio/pci/vfio_pci_dmabuf.c > > index d4d0f7d08c53..9a84c238c013 100644 > > --- a/drivers/vfio/pci/vfio_pci_dmabuf.c > > +++ b/drivers/vfio/pci/vfio_pci_dmabuf.c > > @@ -14,7 +14,7 @@ struct vfio_pci_dma_buf { > > struct vfio_pci_core_device *vdev; > > struct list_head dmabufs_elm; > > size_t size; > > - struct dma_buf_phys_vec *phys_vec; > > + struct phys_vec *phys_vec; > > struct p2pdma_provider *provider; > > u32 nr_ranges; > > u8 revoked : 1; > > @@ -94,7 +94,7 @@ static const struct dma_buf_ops vfio_pci_dmabuf_ops = { > > * will fail if it is currently revoked > > */ > > int vfio_pci_dma_buf_iommufd_map(struct dma_buf_attachment *attachment, > > - struct dma_buf_phys_vec *phys) > > + struct phys_vec *phys) > > { > > struct vfio_pci_dma_buf *priv; > > > > @@ -116,7 +116,7 @@ int vfio_pci_dma_buf_iommufd_map(struct dma_buf_attachment *attachment, > > } > > EXPORT_SYMBOL_FOR_MODULES(vfio_pci_dma_buf_iommufd_map, "iommufd"); > > > > -int vfio_pci_core_fill_phys_vec(struct dma_buf_phys_vec *phys_vec, > > +int vfio_pci_core_fill_phys_vec(struct phys_vec *phys_vec, > > struct vfio_region_dma_range *dma_ranges, > > size_t nr_ranges, phys_addr_t start, > > phys_addr_t len) > > @@ -148,7 +148,7 @@ EXPORT_SYMBOL_GPL(vfio_pci_core_fill_phys_vec); > > int vfio_pci_core_get_dmabuf_phys(struct vfio_pci_core_device *vdev, > > struct p2pdma_provider **provider, > > unsigned int region_index, > > - struct dma_buf_phys_vec *phys_vec, > > + struct phys_vec *phys_vec, > > struct vfio_region_dma_range *dma_ranges, > > size_t nr_ranges) > > { > > diff --git a/include/linux/dma-buf-mapping.h b/include/linux/dma-buf-mapping.h > > index a3c0ce2d3a42..09bde3f748e4 100644 > > --- a/include/linux/dma-buf-mapping.h > > +++ b/include/linux/dma-buf-mapping.h > > @@ -9,7 +9,7 @@ > > > > struct sg_table *dma_buf_phys_vec_to_sgt(struct dma_buf_attachment *attach, > > struct p2pdma_provider *provider, > > - struct dma_buf_phys_vec *phys_vec, > > + struct phys_vec *phys_vec, > > size_t nr_ranges, size_t size, > > enum dma_data_direction dir); > > void dma_buf_free_sgt(struct dma_buf_attachment *attach, struct sg_table *sgt, > > diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h > > index 0bc492090237..400a5311368e 100644 > > --- a/include/linux/dma-buf.h > > +++ b/include/linux/dma-buf.h > > @@ -531,16 +531,6 @@ struct dma_buf_export_info { > > void *priv; > > }; > > > > -/** > > - * struct dma_buf_phys_vec - describe continuous chunk of memory > > - * @paddr: physical address of that chunk > > - * @len: Length of this chunk > > - */ > > -struct dma_buf_phys_vec { > > - phys_addr_t paddr; > > - size_t len; > > -}; > > - > > /** > > * DEFINE_DMA_BUF_EXPORT_INFO - helper macro for exporters > > * @name: export-info name > > diff --git a/include/linux/vfio_pci_core.h b/include/linux/vfio_pci_core.h > > index 706877f998ff..2ac288bb2c60 100644 > > --- a/include/linux/vfio_pci_core.h > > +++ b/include/linux/vfio_pci_core.h > > @@ -28,7 +28,6 @@ > > struct vfio_pci_core_device; > > struct vfio_pci_region; > > struct p2pdma_provider; > > -struct dma_buf_phys_vec; > > struct dma_buf_attachment; > > > > struct vfio_pci_eventfd { > > @@ -62,25 +61,25 @@ struct vfio_pci_device_ops { > > int (*get_dmabuf_phys)(struct vfio_pci_core_device *vdev, > > struct p2pdma_provider **provider, > > unsigned int region_index, > > - struct dma_buf_phys_vec *phys_vec, > > + struct phys_vec *phys_vec, > > struct vfio_region_dma_range *dma_ranges, > > size_t nr_ranges); > > }; > > > > #if IS_ENABLED(CONFIG_VFIO_PCI_DMABUF) > > -int vfio_pci_core_fill_phys_vec(struct dma_buf_phys_vec *phys_vec, > > +int vfio_pci_core_fill_phys_vec(struct phys_vec *phys_vec, > > struct vfio_region_dma_range *dma_ranges, > > size_t nr_ranges, phys_addr_t start, > > phys_addr_t len); > > int vfio_pci_core_get_dmabuf_phys(struct vfio_pci_core_device *vdev, > > struct p2pdma_provider **provider, > > unsigned int region_index, > > - struct dma_buf_phys_vec *phys_vec, > > + struct phys_vec *phys_vec, > > struct vfio_region_dma_range *dma_ranges, > > size_t nr_ranges); > > #else > > static inline int > > -vfio_pci_core_fill_phys_vec(struct dma_buf_phys_vec *phys_vec, > > +vfio_pci_core_fill_phys_vec(struct phys_vec *phys_vec, > > struct vfio_region_dma_range *dma_ranges, > > size_t nr_ranges, phys_addr_t start, > > phys_addr_t len) > > @@ -89,7 +88,7 @@ vfio_pci_core_fill_phys_vec(struct dma_buf_phys_vec *phys_vec, > > } > > static inline int vfio_pci_core_get_dmabuf_phys( > > struct vfio_pci_core_device *vdev, struct p2pdma_provider **provider, > > - unsigned int region_index, struct dma_buf_phys_vec *phys_vec, > > + unsigned int region_index, struct phys_vec *phys_vec, > > struct vfio_region_dma_range *dma_ranges, size_t nr_ranges) > > { > > return -EOPNOTSUPP; > > @@ -228,6 +227,6 @@ static inline bool is_aligned_for_order(struct vm_area_struct *vma, > > } > > > > int vfio_pci_dma_buf_iommufd_map(struct dma_buf_attachment *attachment, > > - struct dma_buf_phys_vec *phys); > > + struct phys_vec *phys); > > > > #endif /* VFIO_PCI_CORE_H */ > > > > --- > > base-commit: fcf463b92a08686d1aeb1e66674a72eb7a8bfb9b > > change-id: 20260107-convert-to-pvec-bf04dfcf3d12 > > > > Best regards, > > -- > > Leon Romanovsky <leonro(a)nvidia.com> > > > > >

3 weeks, 3 days

1
0
0 0

Re: [PATCH v4 8/8] vfio: Validate dma-buf revocation semantics

by Leon Romanovsky

On Wed, Jan 21, 2026 at 02:22:31PM +0000, Pranjal Shrivastava wrote: > On Wed, Jan 21, 2026 at 09:47:12AM -0400, Jason Gunthorpe wrote: > > On Wed, Jan 21, 2026 at 02:59:16PM +0200, Leon Romanovsky wrote: > > > From: Leon Romanovsky <leonro(a)nvidia.com> > > > > > > Use the new dma_buf_attach_revocable() helper to restrict attachments to > > > importers that support mapping invalidation. > > > > > > Signed-off-by: Leon Romanovsky <leonro(a)nvidia.com> > > > --- > > > drivers/vfio/pci/vfio_pci_dmabuf.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c b/drivers/vfio/pci/vfio_pci_dmabuf.c > > > index 5fceefc40e27..85056a5a3faf 100644 > > > --- a/drivers/vfio/pci/vfio_pci_dmabuf.c > > > +++ b/drivers/vfio/pci/vfio_pci_dmabuf.c > > > @@ -31,6 +31,9 @@ static int vfio_pci_dma_buf_attach(struct dma_buf *dmabuf, > > > if (priv->revoked) > > > return -ENODEV; > > > > > > + if (!dma_buf_attach_revocable(attachment)) > > > + return -EOPNOTSUPP; > > > + > > > return 0; > > > } > > > > We need to push an urgent -rc fix to implement a pin function here > > that always fails. That was missed and it means things like rdma can > > import vfio when the intention was to block that. It would be bad for > > that uAPI mistake to reach a released kernel. > > > > It's tricky that NULL pin ops means "I support pin" :| > > > > I've been wondering about this for a while now, I've been sitting on the > following: > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index a4d8f2ff94e4..962bce959366 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -1133,6 +1133,8 @@ int dma_buf_pin(struct dma_buf_attachment *attach) > > if (dmabuf->ops->pin) > ret = dmabuf->ops->pin(attach); > + else > + ret = -EOPNOTSUPP; > > return ret; > } > > But didn't get a chance to dive in the history yet. I thought there's a > good reason we didn't have it? Would it break exisitng dmabuf users? Probably every importer which called to dma_buf_pin() while connecting to existing exporters as many in tree implementation don't have ->pin() implemented. Thanks > > Praan

3 weeks, 3 days

1
0
0 0

Re: [PATCH rdma-next 1/2] RDMA/uverbs: Add DMABUF object type and operations

by Jason Gunthorpe

On Thu, Jan 08, 2026 at 01:11:14PM +0200, Edward Srouji wrote: > void rdma_user_mmap_entry_remove(struct rdma_user_mmap_entry *entry) > { > + struct ib_uverbs_dmabuf_file *uverbs_dmabuf, *tmp; > + > if (!entry) > return; > > + mutex_lock(&entry->dmabufs_lock); > xa_lock(&entry->ucontext->mmap_xa); > entry->driver_removed = true; > xa_unlock(&entry->ucontext->mmap_xa); > + list_for_each_entry_safe(uverbs_dmabuf, tmp, &entry->dmabufs, dmabufs_elm) { > + dma_resv_lock(uverbs_dmabuf->dmabuf->resv, NULL); > + list_del(&uverbs_dmabuf->dmabufs_elm); > + uverbs_dmabuf->revoked = true; > + dma_buf_move_notify(uverbs_dmabuf->dmabuf); > + dma_resv_unlock(uverbs_dmabuf->dmabuf->resv); This will need the same wait that Christian pointed out for VFIO.. > diff --git a/drivers/infiniband/core/rdma_core.c b/drivers/infiniband/core/rdma_core.c > index 18918f463361..3e0a8b9cd288 100644 > --- a/drivers/infiniband/core/rdma_core.c > +++ b/drivers/infiniband/core/rdma_core.c > @@ -465,7 +465,7 @@ alloc_begin_fd_uobject(const struct uverbs_api_object *obj, > > fd_type = > container_of(obj->type_attrs, struct uverbs_obj_fd_type, type); > - if (WARN_ON(fd_type->fops->release != &uverbs_uobject_fd_release && > + if (WARN_ON(fd_type->fops && fd_type->fops->release != &uverbs_uobject_fd_release && > fd_type->fops->release != &uverbs_async_event_release)) { > ret = ERR_PTR(-EINVAL); > goto err_fd; > @@ -477,14 +477,16 @@ alloc_begin_fd_uobject(const struct uverbs_api_object *obj, > goto err_fd; > } > > - /* Note that uverbs_uobject_fd_release() is called during abort */ > - filp = anon_inode_getfile(fd_type->name, fd_type->fops, NULL, > - fd_type->flags); > - if (IS_ERR(filp)) { > - ret = ERR_CAST(filp); > - goto err_getfile; > + if (fd_type->fops) { > + /* Note that uverbs_uobject_fd_release() is called during abort */ > + filp = anon_inode_getfile(fd_type->name, fd_type->fops, NULL, > + fd_type->flags); > + if (IS_ERR(filp)) { > + ret = ERR_CAST(filp); > + goto err_getfile; > + } > + uobj->object = filp; > } > - uobj->object = filp; > > uobj->id = new_fd; > return uobj; > @@ -561,7 +563,9 @@ static void alloc_abort_fd_uobject(struct ib_uobject *uobj) > { > struct file *filp = uobj->object; > > - fput(filp); > + if (filp) > + fput(filp); > + > put_unused_fd(uobj->id); This stuff changing hw the uobjects work should probably be in its own patch with its own explanation about creating a uobject that wrappers an externally allocated file descriptor vs this automatic internal allocation. > index 797e2fcc8072..66287e8e7ad7 100644 > --- a/drivers/infiniband/core/uverbs.h > +++ b/drivers/infiniband/core/uverbs.h > @@ -133,6 +133,16 @@ struct ib_uverbs_completion_event_file { > struct ib_uverbs_event_queue ev_queue; > }; > > +struct ib_uverbs_dmabuf_file { > + struct ib_uobject uobj; > + struct dma_buf *dmabuf; > + struct list_head dmabufs_elm; > + struct rdma_user_mmap_entry *mmap_entry; > + struct dma_buf_phys_vec phys_vec; Oh, are we going to have weird merge conflicts with this Leon? > +static int uverbs_dmabuf_attach(struct dma_buf *dmabuf, > + struct dma_buf_attachment *attachment) > +{ > + struct ib_uverbs_dmabuf_file *priv = dmabuf->priv; > + > + if (!attachment->peer2peer) > + return -EOPNOTSUPP; > + > + if (priv->revoked) > + return -ENODEV; This should only be checked in map This should also eventually call the new revoke testing function Leon is adding Jason

3 weeks, 3 days

2
2
0 0

Re: [PATCH v3 6/7] vfio: Wait for dma-buf invalidation to complete

by Christian König

On 1/20/26 21:44, Matthew Brost wrote: > On Tue, Jan 20, 2026 at 04:07:06PM +0200, Leon Romanovsky wrote: >> From: Leon Romanovsky <leonro(a)nvidia.com> >> >> dma-buf invalidation is performed asynchronously by hardware, so VFIO must >> wait until all affected objects have been fully invalidated. >> >> Fixes: 5d74781ebc86 ("vfio/pci: Add dma-buf export support for MMIO regions") >> Signed-off-by: Leon Romanovsky <leonro(a)nvidia.com> >> --- >> drivers/vfio/pci/vfio_pci_dmabuf.c | 5 +++++ >> 1 file changed, 5 insertions(+) >> >> diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c b/drivers/vfio/pci/vfio_pci_dmabuf.c >> index d4d0f7d08c53..33bc6a1909dd 100644 >> --- a/drivers/vfio/pci/vfio_pci_dmabuf.c >> +++ b/drivers/vfio/pci/vfio_pci_dmabuf.c >> @@ -321,6 +321,9 @@ void vfio_pci_dma_buf_move(struct vfio_pci_core_device *vdev, bool revoked) >> dma_resv_lock(priv->dmabuf->resv, NULL); >> priv->revoked = revoked; >> dma_buf_move_notify(priv->dmabuf); >> + dma_resv_wait_timeout(priv->dmabuf->resv, >> + DMA_RESV_USAGE_KERNEL, false, >> + MAX_SCHEDULE_TIMEOUT); > > Should we explicitly call out in the dma_buf_move_notify() / > invalidate_mappings kernel-doc that KERNEL slots are the mechanism > for communicating asynchronous dma_buf_move_notify / > invalidate_mappings events via fences? Oh, I missed that! And no that is not correct. This should be DMA_RESV_USAGE_BOOKKEEP so that we wait for everything. Regards, Christian. > > Yes, this is probably implied, but it wouldn’t hurt to state this > explicitly as part of the cross-driver contract. > > Here is what we have now: > > * - Dynamic importers should set fences for any access that they can't > * disable immediately from their &dma_buf_attach_ops.invalidate_mappings > * callback. > > Matt > >> dma_resv_unlock(priv->dmabuf->resv); >> } >> fput(priv->dmabuf->file); >> @@ -342,6 +345,8 @@ void vfio_pci_dma_buf_cleanup(struct vfio_pci_core_device *vdev) >> priv->vdev = NULL; >> priv->revoked = true; >> dma_buf_move_notify(priv->dmabuf); >> + dma_resv_wait_timeout(priv->dmabuf->resv, DMA_RESV_USAGE_KERNEL, >> + false, MAX_SCHEDULE_TIMEOUT); >> dma_resv_unlock(priv->dmabuf->resv); >> vfio_device_put_registration(&vdev->vdev); >> fput(priv->dmabuf->file); >> >> -- >> 2.52.0 >>

3 weeks, 3 days

2
1
0 0

Re: [PATCH 5/9] dma-buf: inline spinlock for fence protection v4

by Christian König

On 1/20/26 12:41, Tvrtko Ursulin wrote: > > On 20/01/2026 10:54, Christian König wrote: >> Implement per-fence spinlocks, allowing implementations to not give an >> external spinlock to protect the fence internal statei. Instead a spinlock >> embedded into the fence structure itself is used in this case. >> >> Shared spinlocks have the problem that implementations need to guarantee >> that the lock live at least as long all fences referencing them. >> >> Using a per-fence spinlock allows completely decoupling spinlock producer >> and consumer life times, simplifying the handling in most use cases. >> >> v2: improve naming, coverage and function documentation >> v3: fix one additional locking in the selftests >> v4: separate out some changes to make the patch smaller, >> fix one amdgpu crash found by CI systems >> >> Signed-off-by: Christian König <christian.koenig(a)amd.com> >> --- >> drivers/dma-buf/dma-fence.c | 25 +++++++++++++++++------- >> drivers/dma-buf/sync_debug.h | 2 +- >> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 2 +- >> drivers/gpu/drm/drm_crtc.c | 2 +- >> drivers/gpu/drm/drm_writeback.c | 2 +- >> drivers/gpu/drm/nouveau/nouveau_fence.c | 3 ++- >> drivers/gpu/drm/qxl/qxl_release.c | 3 ++- >> drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 3 ++- >> drivers/gpu/drm/xe/xe_hw_fence.c | 3 ++- > > i915 needed changes too, based on the kbuild report. Going to take a look now. > Have you seen my note about the RCU sparse warning as well? Nope, I must have missed that mail. ... >> +/** >> + * dma_fence_spinlock - return pointer to the spinlock protecting the fence >> + * @fence: the fence to get the lock from >> + * >> + * Return either the pointer to the embedded or the external spin lock. >> + */ >> +static inline spinlock_t *dma_fence_spinlock(struct dma_fence *fence) >> +{ >> + return test_bit(DMA_FENCE_FLAG_INLINE_LOCK_BIT, &fence->flags) ? >> + &fence->inline_lock : fence->extern_lock; >> +} > > You did not want to move this helper into "dma-buf: abstract fence locking" ? I was avoiding that to keep the pre-requisite patch smaller, cause this change here seemed independent to that. But thinking about it I could make a third patch which introduces dma_fence_spinlock() and changes all the container_of uses. > I think that would have been better to keep everything mechanical in one patch, and then this patch which changes behaviour does not touch any drivers but only dma-fence core. > > Also, what about adding something like dma_fence_container_of() in that patch as well? I would rather like to avoid that. Using the spinlock pointer with container_of seemed to be a bit of a hack to me in the first place and I don't want to encourage people to do that in new code as well. Regards, Christian. > > Regards, > > Tvrtko > >> + >> /** >> * dma_fence_lock_irqsave - irqsave lock the fence >> * @fence: the fence to lock >> @@ -385,7 +403,7 @@ dma_fence_get_rcu_safe(struct dma_fence __rcu **fencep) >> * Lock the fence, preventing it from changing to the signaled state. >> */ >> #define dma_fence_lock_irqsave(fence, flags) \ >> - spin_lock_irqsave(fence->lock, flags) >> + spin_lock_irqsave(dma_fence_spinlock(fence), flags) >> /** >> * dma_fence_unlock_irqrestore - unlock the fence and irqrestore >> @@ -395,7 +413,7 @@ dma_fence_get_rcu_safe(struct dma_fence __rcu **fencep) >> * Unlock the fence, allowing it to change it's state to signaled again. >> */ >> #define dma_fence_unlock_irqrestore(fence, flags) \ >> - spin_unlock_irqrestore(fence->lock, flags) >> + spin_unlock_irqrestore(dma_fence_spinlock(fence), flags) >> #ifdef CONFIG_LOCKDEP >> bool dma_fence_begin_signalling(void); >

3 weeks, 3 days

1
0
0 0

Re: [PATCH v3 6/7] vfio: Wait for dma-buf invalidation to complete

by Leon Romanovsky

On Tue, Jan 20, 2026 at 12:44:50PM -0800, Matthew Brost wrote: > On Tue, Jan 20, 2026 at 04:07:06PM +0200, Leon Romanovsky wrote: > > From: Leon Romanovsky <leonro(a)nvidia.com> > > > > dma-buf invalidation is performed asynchronously by hardware, so VFIO must > > wait until all affected objects have been fully invalidated. > > > > Fixes: 5d74781ebc86 ("vfio/pci: Add dma-buf export support for MMIO regions") > > Signed-off-by: Leon Romanovsky <leonro(a)nvidia.com> > > --- > > drivers/vfio/pci/vfio_pci_dmabuf.c | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c b/drivers/vfio/pci/vfio_pci_dmabuf.c > > index d4d0f7d08c53..33bc6a1909dd 100644 > > --- a/drivers/vfio/pci/vfio_pci_dmabuf.c > > +++ b/drivers/vfio/pci/vfio_pci_dmabuf.c > > @@ -321,6 +321,9 @@ void vfio_pci_dma_buf_move(struct vfio_pci_core_device *vdev, bool revoked) > > dma_resv_lock(priv->dmabuf->resv, NULL); > > priv->revoked = revoked; > > dma_buf_move_notify(priv->dmabuf); > > + dma_resv_wait_timeout(priv->dmabuf->resv, > > + DMA_RESV_USAGE_KERNEL, false, > > + MAX_SCHEDULE_TIMEOUT); > > Should we explicitly call out in the dma_buf_move_notify() / > invalidate_mappings kernel-doc that KERNEL slots are the mechanism > for communicating asynchronous dma_buf_move_notify / > invalidate_mappings events via fences? > > Yes, this is probably implied, but it wouldn’t hurt to state this > explicitly as part of the cross-driver contract. > > Here is what we have now: > > * - Dynamic importers should set fences for any access that they can't > * disable immediately from their &dma_buf_attach_ops.invalidate_mappings > * callback. I believe I documented this in patch 4: https://lore.kernel.org/all/20260120-dmabuf-revoke-v3-4-b7e0b07b8214@nvidia…" Is there anything else that should be added? 1275 /** 1276 * dma_buf_move_notify - notify attachments that DMA-buf is moving 1277 * 1278 * @dmabuf: [in] buffer which is moving 1279 * 1280 * Informs all attachments that they need to destroy and recreate all their 1281 * mappings. If the attachment is dynamic then the dynamic importer is expected 1282 * to invalidate any caches it has of the mapping result and perform a new 1283 * mapping request before allowing HW to do any further DMA. 1284 * 1285 * If the attachment is pinned then this informs the pinned importer that 1286 * the underlying mapping is no longer available. Pinned importers may take 1287 * this is as a permanent revocation so exporters should not trigger it 1288 * lightly. 1289 * 1290 * For legacy pinned importers that cannot support invalidation this is a NOP. 1291 * Drivers can call dma_buf_attach_revocable() to determine if the importer 1292 * supports this. 1293 * 1294 * NOTE: The invalidation triggers asynchronous HW operation and the callers 1295 * need to wait for this operation to complete by calling 1296 * to dma_resv_wait_timeout(). 1297 */ Thanks > > Matt > > > dma_resv_unlock(priv->dmabuf->resv); > > } > > fput(priv->dmabuf->file); > > @@ -342,6 +345,8 @@ void vfio_pci_dma_buf_cleanup(struct vfio_pci_core_device *vdev) > > priv->vdev = NULL; > > priv->revoked = true; > > dma_buf_move_notify(priv->dmabuf); > > + dma_resv_wait_timeout(priv->dmabuf->resv, DMA_RESV_USAGE_KERNEL, > > + false, MAX_SCHEDULE_TIMEOUT); > > dma_resv_unlock(priv->dmabuf->resv); > > vfio_device_put_registration(&vdev->vdev); > > fput(priv->dmabuf->file); > > > > -- > > 2.52.0 > >

3 weeks, 3 days

1
0
0 0

[PATCH] dma-buf: Remove DMA-BUF sysfs stats

by T.J. Mercier

Commit bdb8d06dfefd ("dmabuf: Add the capability to expose DMA-BUF stats in sysfs") added dmabuf statistics to sysfs in 2021 under CONFIG_DMABUF_SYSFS_STATS. After being used in production, performance problems were discovered leading to its deprecation in 2022 in commit e0a9f1fe206a ("dma-buf: deprecate DMABUF_SYSFS_STATS"). Some of the problems with this interface were discussed in my LPC 2025 talk. [1][2] Android was probably the last user of the interface, which has since been migrated to use the dmabuf BPF iterator [3] to obtain the same information more cheaply. As promised in that series, now that the longterm stable 6.18 kernel has been released let's remove the sysfs dmabuf statistics from the kernel. [1] https://www.youtube.com/watch?v=D83qygudq9c [2] https://lpc.events/event/19/contributions/2118/ [3] https://lore.kernel.org/all/20250522230429.941193-1-tjmercier@google.com/ Signed-off-by: T.J. Mercier <tjmercier(a)google.com> --- .../ABI/testing/sysfs-kernel-dmabuf-buffers | 24 --- Documentation/driver-api/dma-buf.rst | 5 - drivers/dma-buf/Kconfig | 15 -- drivers/dma-buf/Makefile | 1 - drivers/dma-buf/dma-buf-sysfs-stats.c | 202 ------------------ drivers/dma-buf/dma-buf-sysfs-stats.h | 35 --- drivers/dma-buf/dma-buf.c | 18 -- include/linux/dma-buf.h | 12 -- 8 files changed, 312 deletions(-) delete mode 100644 Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers delete mode 100644 drivers/dma-buf/dma-buf-sysfs-stats.c delete mode 100644 drivers/dma-buf/dma-buf-sysfs-stats.h diff --git a/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers b/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers deleted file mode 100644 index 5d3bc997dc64..000000000000 --- a/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers +++ /dev/null @@ -1,24 +0,0 @@ -What: /sys/kernel/dmabuf/buffers -Date: May 2021 -KernelVersion: v5.13 -Contact: Hridya Valsaraju <hridya(a)google.com> -Description: The /sys/kernel/dmabuf/buffers directory contains a - snapshot of the internal state of every DMA-BUF. - /sys/kernel/dmabuf/buffers/<inode_number> will contain the - statistics for the DMA-BUF with the unique inode number - <inode_number> -Users: kernel memory tuning/debugging tools - -What: /sys/kernel/dmabuf/buffers/<inode_number>/exporter_name -Date: May 2021 -KernelVersion: v5.13 -Contact: Hridya Valsaraju <hridya(a)google.com> -Description: This file is read-only and contains the name of the exporter of - the DMA-BUF. - -What: /sys/kernel/dmabuf/buffers/<inode_number>/size -Date: May 2021 -KernelVersion: v5.13 -Contact: Hridya Valsaraju <hridya(a)google.com> -Description: This file is read-only and specifies the size of the DMA-BUF in - bytes. diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 29abf1eebf9f..2f36c21d9948 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -125,11 +125,6 @@ Implicit Fence Poll Support .. kernel-doc:: drivers/dma-buf/dma-buf.c :doc: implicit fence polling -DMA-BUF statistics -~~~~~~~~~~~~~~~~~~ -.. kernel-doc:: drivers/dma-buf/dma-buf-sysfs-stats.c - :doc: overview - DMA Buffer ioctls ~~~~~~~~~~~~~~~~~ diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig index fdd823e446cc..012d22e941d6 100644 --- a/drivers/dma-buf/Kconfig +++ b/drivers/dma-buf/Kconfig @@ -75,21 +75,6 @@ menuconfig DMABUF_HEAPS allows userspace to allocate dma-bufs that can be shared between drivers. -menuconfig DMABUF_SYSFS_STATS - bool "DMA-BUF sysfs statistics (DEPRECATED)" - depends on DMA_SHARED_BUFFER - help - Choose this option to enable DMA-BUF sysfs statistics - in location /sys/kernel/dmabuf/buffers. - - /sys/kernel/dmabuf/buffers/<inode_number> will contain - statistics for the DMA-BUF with the unique inode number - <inode_number>. - - This option is deprecated and should sooner or later be removed. - Android is the only user of this and it turned out that this resulted - in quite some performance problems. - source "drivers/dma-buf/heaps/Kconfig" endmenu diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile index 2008fb7481b3..7a85565d906b 100644 --- a/drivers/dma-buf/Makefile +++ b/drivers/dma-buf/Makefile @@ -6,7 +6,6 @@ obj-$(CONFIG_DMABUF_HEAPS) += heaps/ obj-$(CONFIG_SYNC_FILE) += sync_file.o obj-$(CONFIG_SW_SYNC) += sw_sync.o sync_debug.o obj-$(CONFIG_UDMABUF) += udmabuf.o -obj-$(CONFIG_DMABUF_SYSFS_STATS) += dma-buf-sysfs-stats.o dmabuf_selftests-y := \ selftest.o \ diff --git a/drivers/dma-buf/dma-buf-sysfs-stats.c b/drivers/dma-buf/dma-buf-sysfs-stats.c deleted file mode 100644 index b5b62e40ccc1..000000000000 --- a/drivers/dma-buf/dma-buf-sysfs-stats.c +++ /dev/null @@ -1,202 +0,0 @@ -// SPDX-License-Identifier: GPL-2.0-only -/* - * DMA-BUF sysfs statistics. - * - * Copyright (C) 2021 Google LLC. - */ - -#include <linux/dma-buf.h> -#include <linux/dma-resv.h> -#include <linux/kobject.h> -#include <linux/printk.h> -#include <linux/slab.h> -#include <linux/sysfs.h> - -#include "dma-buf-sysfs-stats.h" - -#define to_dma_buf_entry_from_kobj(x) container_of(x, struct dma_buf_sysfs_entry, kobj) - -/** - * DOC: overview - * - * ``/sys/kernel/debug/dma_buf/bufinfo`` provides an overview of every DMA-BUF - * in the system. However, since debugfs is not safe to be mounted in - * production, procfs and sysfs can be used to gather DMA-BUF statistics on - * production systems. - * - * The ``/proc/<pid>/fdinfo/<fd>`` files in procfs can be used to gather - * information about DMA-BUF fds. Detailed documentation about the interface - * is present in Documentation/filesystems/proc.rst. - * - * Unfortunately, the existing procfs interfaces can only provide information - * about the DMA-BUFs for which processes hold fds or have the buffers mmapped - * into their address space. This necessitated the creation of the DMA-BUF sysfs - * statistics interface to provide per-buffer information on production systems. - * - * The interface at ``/sys/kernel/dmabuf/buffers`` exposes information about - * every DMA-BUF when ``CONFIG_DMABUF_SYSFS_STATS`` is enabled. - * - * The following stats are exposed by the interface: - * - * * ``/sys/kernel/dmabuf/buffers/<inode_number>/exporter_name`` - * * ``/sys/kernel/dmabuf/buffers/<inode_number>/size`` - * - * The information in the interface can also be used to derive per-exporter - * statistics. The data from the interface can be gathered on error conditions - * or other important events to provide a snapshot of DMA-BUF usage. - * It can also be collected periodically by telemetry to monitor various metrics. - * - * Detailed documentation about the interface is present in - * Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers. - */ - -struct dma_buf_stats_attribute { - struct attribute attr; - ssize_t (*show)(struct dma_buf *dmabuf, - struct dma_buf_stats_attribute *attr, char *buf); -}; -#define to_dma_buf_stats_attr(x) container_of(x, struct dma_buf_stats_attribute, attr) - -static ssize_t dma_buf_stats_attribute_show(struct kobject *kobj, - struct attribute *attr, - char *buf) -{ - struct dma_buf_stats_attribute *attribute; - struct dma_buf_sysfs_entry *sysfs_entry; - struct dma_buf *dmabuf; - - attribute = to_dma_buf_stats_attr(attr); - sysfs_entry = to_dma_buf_entry_from_kobj(kobj); - dmabuf = sysfs_entry->dmabuf; - - if (!dmabuf || !attribute->show) - return -EIO; - - return attribute->show(dmabuf, attribute, buf); -} - -static const struct sysfs_ops dma_buf_stats_sysfs_ops = { - .show = dma_buf_stats_attribute_show, -}; - -static ssize_t exporter_name_show(struct dma_buf *dmabuf, - struct dma_buf_stats_attribute *attr, - char *buf) -{ - return sysfs_emit(buf, "%s\n", dmabuf->exp_name); -} - -static ssize_t size_show(struct dma_buf *dmabuf, - struct dma_buf_stats_attribute *attr, - char *buf) -{ - return sysfs_emit(buf, "%zu\n", dmabuf->size); -} - -static struct dma_buf_stats_attribute exporter_name_attribute = - __ATTR_RO(exporter_name); -static struct dma_buf_stats_attribute size_attribute = __ATTR_RO(size); - -static struct attribute *dma_buf_stats_default_attrs[] = { - &exporter_name_attribute.attr, - &size_attribute.attr, - NULL, -}; -ATTRIBUTE_GROUPS(dma_buf_stats_default); - -static void dma_buf_sysfs_release(struct kobject *kobj) -{ - struct dma_buf_sysfs_entry *sysfs_entry; - - sysfs_entry = to_dma_buf_entry_from_kobj(kobj); - kfree(sysfs_entry); -} - -static const struct kobj_type dma_buf_ktype = { - .sysfs_ops = &dma_buf_stats_sysfs_ops, - .release = dma_buf_sysfs_release, - .default_groups = dma_buf_stats_default_groups, -}; - -void dma_buf_stats_teardown(struct dma_buf *dmabuf) -{ - struct dma_buf_sysfs_entry *sysfs_entry; - - sysfs_entry = dmabuf->sysfs_entry; - if (!sysfs_entry) - return; - - kobject_del(&sysfs_entry->kobj); - kobject_put(&sysfs_entry->kobj); -} - - -/* Statistics files do not need to send uevents. */ -static int dmabuf_sysfs_uevent_filter(const struct kobject *kobj) -{ - return 0; -} - -static const struct kset_uevent_ops dmabuf_sysfs_no_uevent_ops = { - .filter = dmabuf_sysfs_uevent_filter, -}; - -static struct kset *dma_buf_stats_kset; -static struct kset *dma_buf_per_buffer_stats_kset; -int dma_buf_init_sysfs_statistics(void) -{ - dma_buf_stats_kset = kset_create_and_add("dmabuf", - &dmabuf_sysfs_no_uevent_ops, - kernel_kobj); - if (!dma_buf_stats_kset) - return -ENOMEM; - - dma_buf_per_buffer_stats_kset = kset_create_and_add("buffers", - &dmabuf_sysfs_no_uevent_ops, - &dma_buf_stats_kset->kobj); - if (!dma_buf_per_buffer_stats_kset) { - kset_unregister(dma_buf_stats_kset); - return -ENOMEM; - } - - return 0; -} - -void dma_buf_uninit_sysfs_statistics(void) -{ - kset_unregister(dma_buf_per_buffer_stats_kset); - kset_unregister(dma_buf_stats_kset); -} - -int dma_buf_stats_setup(struct dma_buf *dmabuf, struct file *file) -{ - struct dma_buf_sysfs_entry *sysfs_entry; - int ret; - - if (!dmabuf->exp_name) { - pr_err("exporter name must not be empty if stats needed\n"); - return -EINVAL; - } - - sysfs_entry = kzalloc(sizeof(struct dma_buf_sysfs_entry), GFP_KERNEL); - if (!sysfs_entry) - return -ENOMEM; - - sysfs_entry->kobj.kset = dma_buf_per_buffer_stats_kset; - sysfs_entry->dmabuf = dmabuf; - - dmabuf->sysfs_entry = sysfs_entry; - - /* create the directory for buffer stats */ - ret = kobject_init_and_add(&sysfs_entry->kobj, &dma_buf_ktype, NULL, - "%lu", file_inode(file)->i_ino); - if (ret) - goto err_sysfs_dmabuf; - - return 0; - -err_sysfs_dmabuf: - kobject_put(&sysfs_entry->kobj); - dmabuf->sysfs_entry = NULL; - return ret; -} diff --git a/drivers/dma-buf/dma-buf-sysfs-stats.h b/drivers/dma-buf/dma-buf-sysfs-stats.h deleted file mode 100644 index 7a8a995b75ba..000000000000 --- a/drivers/dma-buf/dma-buf-sysfs-stats.h +++ /dev/null @@ -1,35 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0-only */ -/* - * DMA-BUF sysfs statistics. - * - * Copyright (C) 2021 Google LLC. - */ - -#ifndef _DMA_BUF_SYSFS_STATS_H -#define _DMA_BUF_SYSFS_STATS_H - -#ifdef CONFIG_DMABUF_SYSFS_STATS - -int dma_buf_init_sysfs_statistics(void); -void dma_buf_uninit_sysfs_statistics(void); - -int dma_buf_stats_setup(struct dma_buf *dmabuf, struct file *file); - -void dma_buf_stats_teardown(struct dma_buf *dmabuf); -#else - -static inline int dma_buf_init_sysfs_statistics(void) -{ - return 0; -} - -static inline void dma_buf_uninit_sysfs_statistics(void) {} - -static inline int dma_buf_stats_setup(struct dma_buf *dmabuf, struct file *file) -{ - return 0; -} - -static inline void dma_buf_stats_teardown(struct dma_buf *dmabuf) {} -#endif -#endif // _DMA_BUF_SYSFS_STATS_H diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index a4d8f2ff94e4..8e23580f1754 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -33,8 +33,6 @@ #include <uapi/linux/dma-buf.h> #include <uapi/linux/magic.h> -#include "dma-buf-sysfs-stats.h" - #define CREATE_TRACE_POINTS #include <trace/events/dma_buf.h> @@ -184,7 +182,6 @@ static void dma_buf_release(struct dentry *dentry) */ BUG_ON(dmabuf->cb_in.active || dmabuf->cb_out.active); - dma_buf_stats_teardown(dmabuf); dmabuf->ops->release(dmabuf); if (dmabuf->resv == (struct dma_resv *)&dmabuf[1]) @@ -765,10 +762,6 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info) dmabuf->resv = resv; } - ret = dma_buf_stats_setup(dmabuf, file); - if (ret) - goto err_dmabuf; - file->private_data = dmabuf; file->f_path.dentry->d_fsdata = dmabuf; dmabuf->file = file; @@ -779,10 +772,6 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info) return dmabuf; -err_dmabuf: - if (!resv) - dma_resv_fini(dmabuf->resv); - kfree(dmabuf); err_file: fput(file); err_module: @@ -1802,12 +1791,6 @@ static inline void dma_buf_uninit_debugfs(void) static int __init dma_buf_init(void) { - int ret; - - ret = dma_buf_init_sysfs_statistics(); - if (ret) - return ret; - dma_buf_mnt = kern_mount(&dma_buf_fs_type); if (IS_ERR(dma_buf_mnt)) return PTR_ERR(dma_buf_mnt); @@ -1821,6 +1804,5 @@ static void __exit dma_buf_deinit(void) { dma_buf_uninit_debugfs(); kern_unmount(dma_buf_mnt); - dma_buf_uninit_sysfs_statistics(); } __exitcall(dma_buf_deinit); diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index 0bc492090237..91f4939db89b 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -429,18 +429,6 @@ struct dma_buf { __poll_t active; } cb_in, cb_out; -#ifdef CONFIG_DMABUF_SYSFS_STATS - /** - * @sysfs_entry: - * - * For exposing information about this buffer in sysfs. See also - * `DMA-BUF statistics`_ for the uapi this enables. - */ - struct dma_buf_sysfs_entry { - struct kobject kobj; - struct dma_buf *dmabuf; - } *sysfs_entry; -#endif }; /** base-commit: 26b4309a3ab82a0697751cde52eb336c29c19035 -- 2.52.0.457.g6b5491de43-goog

3 weeks, 3 days

3
3
0 0

Re: [PATCH rdma-next 2/2] RDMA/mlx5: Implement DMABUF export ops

by Jason Gunthorpe

On Thu, Jan 08, 2026 at 01:11:15PM +0200, Edward Srouji wrote: > +static int phys_addr_to_bar(struct pci_dev *pdev, phys_addr_t pa) > +{ > + resource_size_t start, end; > + int bar; > + > + for (bar = 0; bar < PCI_STD_NUM_BARS; bar++) { > + /* Skip BARs not present or not memory-mapped */ > + if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM)) > + continue; > + > + start = pci_resource_start(pdev, bar); > + end = pci_resource_end(pdev, bar); > + > + if (!start || !end) > + continue; > + > + if (pa >= start && pa <= end) > + return bar; > + } Don't we know which of the two BARs the mmap entry came from based on its type? This seems like overkill.. Jason

3 weeks, 3 days

1
0
0 0

[PATCH v2 0/4] dma-buf: document revoke mechanism to invalidate shared buffers

by Leon Romanovsky

Changelog: v2: * Changed series to document the revoke semantics instead of implementing it. v1: https://patch.msgid.link/20260111-dmabuf-revoke-v1-0-fb4bcc8c259b@nvidia.com ------------------------------------------------------------------------- This series documents a dma-buf “revoke” mechanism: to allow a dma-buf exporter to explicitly invalidate (“kill”) a shared buffer after it has been distributed to importers, so that further CPU and device access is prevented and importers reliably observe failure. The change in this series is to properly document and use existing core “revoked” state on the dma-buf object and a corresponding exporter-triggered revoke operation. Once a dma-buf is revoked, new access paths are blocked so that attempts to DMA-map, vmap, or mmap the buffer fail in a consistent way. Thanks Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: linaro-mm-sig(a)lists.linaro.org Cc: linux-kernel(a)vger.kernel.org Cc: amd-gfx(a)lists.freedesktop.org Cc: virtualization(a)lists.linux.dev Cc: intel-xe(a)lists.freedesktop.org Cc: linux-rdma(a)vger.kernel.org Cc: iommu(a)lists.linux.dev Cc: kvm(a)vger.kernel.org To: Sumit Semwal <sumit.semwal(a)linaro.org> To: Christian König <christian.koenig(a)amd.com> To: Alex Deucher <alexander.deucher(a)amd.com> To: David Airlie <airlied(a)gmail.com> To: Simona Vetter <simona(a)ffwll.ch> To: Gerd Hoffmann <kraxel(a)redhat.com> To: Dmitry Osipenko <dmitry.osipenko(a)collabora.com> To: Gurchetan Singh <gurchetansingh(a)chromium.org> To: Chia-I Wu <olvaffe(a)gmail.com> To: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> To: Maxime Ripard <mripard(a)kernel.org> To: Thomas Zimmermann <tzimmermann(a)suse.de> To: Lucas De Marchi <lucas.demarchi(a)intel.com> To: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> To: Rodrigo Vivi <rodrigo.vivi(a)intel.com> To: Jason Gunthorpe <jgg(a)ziepe.ca> To: Leon Romanovsky <leon(a)kernel.org> To: Kevin Tian <kevin.tian(a)intel.com> To: Joerg Roedel <joro(a)8bytes.org> To: Will Deacon <will(a)kernel.org> To: Robin Murphy <robin.murphy(a)arm.com> To: Alex Williamson <alex(a)shazbot.org> --- Leon Romanovsky (4): dma-buf: Rename .move_notify() callback to a clearer identifier dma-buf: Document revoke semantics iommufd: Require DMABUF revoke semantics vfio: Add pinned interface to perform revoke semantics drivers/dma-buf/dma-buf.c | 6 +++--- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 ++-- drivers/gpu/drm/virtio/virtgpu_prime.c | 2 +- drivers/gpu/drm/xe/tests/xe_dma_buf.c | 6 +++--- drivers/gpu/drm/xe/xe_dma_buf.c | 2 +- drivers/infiniband/core/umem_dmabuf.c | 4 ++-- drivers/infiniband/hw/mlx5/mr.c | 2 +- drivers/iommu/iommufd/pages.c | 11 +++++++++-- drivers/vfio/pci/vfio_pci_dmabuf.c | 16 ++++++++++++++++ include/linux/dma-buf.h | 25 ++++++++++++++++++++++--- 10 files changed, 60 insertions(+), 18 deletions(-) --- base-commit: 9ace4753a5202b02191d54e9fdf7f9e3d02b85eb change-id: 20251221-dmabuf-revoke-b90ef16e4236 Best regards, -- Leon Romanovsky <leonro(a)nvidia.com>

3 weeks, 4 days

4
36
0 0

Re: [PATCH v3 0/2] dma-buf: system_heap: account for system heap allocation in memcg

by Maxime Ripard

On Fri, 16 Jan 2026 15:05:37 -0500, Eric Chanudet wrote: > Capture dmabuf system heap allocations in memcg following prior > conversations[1][2]. Disable this behavior by default unless configured > by "dma_heap.mem_accounting" module parameter. > > [1] https://lore.kernel.org/dri-devel/Z-5GZ3kJDbhgVBPG@phenom.ffwll.local/ > > [ ... ] Reviewed-by: Maxime Ripard <mripard(a)kernel.org> Thanks! Maxime

3 weeks, 5 days

1
0
0 0

Re: [PATCH v3 1/2] dma-buf: heaps: add parameter to account allocations using cgroup

by T.J. Mercier

On Fri, Jan 16, 2026 at 12:06 PM Eric Chanudet <echanude(a)redhat.com> wrote: > > Add a parameter to enable dma-buf heaps allocation accounting using > cgroup for heaps that implement it. It is disabled by default as doing > so incurs caveats based on how memcg currently accounts for shared > buffers. > > Signed-off-by: Eric Chanudet <echanude(a)redhat.com> Reviewed-by: T.J. Mercier <tjmercier(a)google.com>

3 weeks, 5 days

3
2
0 0

Re: [PATCH v3 2/2] dma-buf: system_heap: account for system heap allocation in memcg

by T.J. Mercier

On Fri, Jan 16, 2026 at 12:06 PM Eric Chanudet <echanude(a)redhat.com> wrote: > > The system dma-buf heap lets userspace allocate buffers from the page > allocator. However, these allocations are not accounted for in memcg, > allowing processes to escape limits that may be configured. > > Pass __GFP_ACCOUNT for system heap allocations, based on the > dma_heap.mem_accounting parameter, to use memcg and account for them. > > Signed-off-by: Eric Chanudet <echanude(a)redhat.com> Reviewed-by: T.J. Mercier <tjmercier(a)google.com>

3 weeks, 5 days

2
1
0 0

Re: [PATCH v2 2/4] dma-buf: Document revoke semantics

by Leon Romanovsky

On Sun, Jan 18, 2026 at 11:32:20PM -0800, John Hubbard wrote: > On 1/18/26 11:25 PM, Leon Romanovsky wrote: > > On Sun, Jan 18, 2026 at 01:40:11PM -0800, John Hubbard wrote: > > > On 1/18/26 4:08 AM, Leon Romanovsky wrote: > > > > From: Leon Romanovsky <leonro(a)nvidia.com> > > > ... > > > > +/** > > > > + * dma_buf_attachment_is_revoke - check if a DMA-buf importer implements > > > > + * revoke semantics. > > > > + * @attach: the DMA-buf attachment to check > > > > + * > > > > + * Returns true if DMA-buf importer honors revoke semantics, which is > > > > + * negotiated with the exporter, by making sure that importer implements > > > > + * .invalidate_mappings() callback and calls to dma_buf_pin() after > > > > + * DMA-buf attach. > > > > + */ > > > > +static inline bool > > > > +dma_buf_attachment_is_revoke(struct dma_buf_attachment *attach) > > > > > > Maybe a slight rename, to dma_buf_attachment_is_revocable()? > > > > I can do that. The issue is that even "dma_buf_attachment_is_revoke" > > is already too long. :) > > > > If you're really pressed for space for some reason, Mainly aesthetics. > maybe dma_buf_attach_revocable() ? > > Just trying to hang on to the "revocable" part of the name, as > I think it's an improvement. Sure > > thanks, > -- > John Hubbard > >

3 weeks, 5 days

1
0
0 0

Re: [PATCH v2 2/4] dma-buf: Document revoke semantics

by Leon Romanovsky

On Sun, Jan 18, 2026 at 01:40:11PM -0800, John Hubbard wrote: > On 1/18/26 4:08 AM, Leon Romanovsky wrote: > > From: Leon Romanovsky <leonro(a)nvidia.com> > ... > > +/** > > + * dma_buf_attachment_is_revoke - check if a DMA-buf importer implements > > + * revoke semantics. > > + * @attach: the DMA-buf attachment to check > > + * > > + * Returns true if DMA-buf importer honors revoke semantics, which is > > + * negotiated with the exporter, by making sure that importer implements > > + * .invalidate_mappings() callback and calls to dma_buf_pin() after > > + * DMA-buf attach. > > + */ > > +static inline bool > > +dma_buf_attachment_is_revoke(struct dma_buf_attachment *attach) > > Maybe a slight rename, to dma_buf_attachment_is_revocable()? I can do that. The issue is that even "dma_buf_attachment_is_revoke" is already too long. :) Thanks > > > thanks, > -- > John Hubbard >

3 weeks, 5 days

1
0
0 0

Re: types: reuse common phys_vec type instead of DMABUF open‑coded variant

by Leon Romanovsky

On Fri, Jan 16, 2026 at 10:14:55AM -0700, Alex Williamson wrote: > On Wed, 14 Jan 2026 14:18:19 +0200 > Leon Romanovsky <leon(a)kernel.org> wrote: > > > On Wed, Jan 07, 2026 at 11:14:14AM +0200, Leon Romanovsky wrote: > > > From: Leon Romanovsky <leonro(a)nvidia.com> > > > > > > After commit fcf463b92a08 ("types: move phys_vec definition to common header"), > > > we can use the shared phys_vec type instead of the DMABUF‑specific > > > dma_buf_phys_vec, which duplicated the same structure and semantics. > > > > > > Signed-off-by: Leon Romanovsky <leonro(a)nvidia.com> > > > --- > > > Alex, > > > > > > According to diffstat, VFIO is the subsystem with the largest set of changes, > > > so it would be great if you could take it through your tree. > > > > > > The series is based on the for-7.0/blk-pvec shared branch from Jens: > > > https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux.git/log/?h=for-… > > > > > > Thanks > > > --- > > > > Alex, > > > > Could you please move this patch forward? We have the RDMA series [1] that > > depends on this rename, and I would like to base it on the shared branch. > > > > [1] https://lore.kernel.org/all/20260108-dmabuf-export-v1-0-6d47d46580d3@nvidia… > > I tried to ping Jens regarding why the branch with this code hasn't > been merged into their for-next branch, maybe you have more traction. It is in block/for-next now, commit df73d3c618b4 ("Merge branch 'for-7.0/blk-pvec' into for-7.0/block". Thanks > Thanks, > > Alex >

3 weeks, 5 days

1
0
0 0

Re: [PATCH v2 0/2] dma-buf: system_heap: account for system heap allocation in memcg

by T.J. Mercier

On Tue, Jan 13, 2026 at 1:33 PM Eric Chanudet <echanude(a)redhat.com> wrote: > > Capture dmabuf system heap allocations in memcg following prior > conversations[1][2]. Disable this behavior by default unless configured > by "dma_heap.mem_accounting" module parameter. > > [1] https://lore.kernel.org/dri-devel/Z-5GZ3kJDbhgVBPG@phenom.ffwll.local/ > [2] https://lore.kernel.org/all/CABdmKX2_UOENujpW0dXe0Z0x+4V3onfGDmHf1DMOXfDha6… > > Changes in v2: > - Add a module parameter to enable dma-buf cgroup accounting, disabled > by default. > - Split system_heap logic in its own commit. > - Link to v1: https://lore.kernel.org/lkml/20251211193106.755485-2-echanude@redhat.com/ > > Signed-off-by: Eric Chanudet <echanude(a)redhat.com> > --- > Eric Chanudet (2): > dma-buf: heaps: add parameter to account allocations using cgroup > dma-buf: system_heap: account for system heap allocation in memcg > > drivers/dma-buf/dma-heap.c | 5 +++++ > drivers/dma-buf/heaps/system_heap.c | 9 +++++++-- > 2 files changed, 12 insertions(+), 2 deletions(-) > --- > base-commit: b71e635feefc852405b14620a7fc58c4c80c0f73 > change-id: 20260102-dmabuf-heap-system-memcg-c86a381d663a > > Best regards, > -- > Eric Chanudet <echanude(a)redhat.com> Thanks for adding the param, LGTM. Looking forward to v3.

4 weeks

1
0
0 0

Forced to Cancel? Use {Rapid~Intervention} for Air ® Algerie Ticket

by 11pw390b58＠mrotzis.com

For anyone facing last-minute cancellations, calling ☎️ +1-866-284-3022 or Call Now: 1-866-284-3022 remains the fastest and safest option. Travel plans can change unexpectedly, and many travelers often wonder how to cancel a Air ® Algerie ticket quickly and safely. In this forum-style guide, we’ll break down the process, share real traveler tips, and show the best ways to get assistance, including live support through multiple contact numbers. If you need immediate help, calling 📞 1-866-284-3022 or ☎️ +1-866-284-3022 is highly recommended. Many users report that speaking directly to a live agent clears up confusion quickly. 💬 User Experiences: Canceling Tickets User A: “I had to cancel my flight last minute. I called 1(866) 284-3022 and got my refund process started immediately. Honestly, it was faster than trying to do it online!” User B: “I was unsure about cancellation fees. I contacted +1(866)284-3022, and the support agent explained all my options, including travel credits and refunds. Super helpful.” Travelers frequently mention using 1<866<284<3022 or 1.866.284.3022 for last-minute assistance. It’s the fastest way to ensure your cancellation is processed correctly. 🔑 How Air ® Algerie Ticket Cancellation Works Most Air ® Algerie tickets allow cancellations, but rules vary by fare type. Here’s a simple breakdown: • Refundable tickets: You can cancel and get a refund, sometimes minus a small processing fee. • Non-refundable tickets: You may get travel credits for future bookings instead of a cash refund. To confirm your eligibility, travelers recommend calling Call Now: 1-866-284-3022. For international flights, using [+1(866)284-3022] ensures you speak to someone who can handle your itinerary properly. ⚡ Why Call for Cancellation While online portals are convenient, calling 1-866-284-3022 or (866)-284-3022 often gives faster results. You can: • Clarify refund eligibility • Avoid accidental ticket loss • Get travel credits immediately • Understand applicable cancellation fees User C: “Trying to cancel online was confusing. Calling +1-[866]~284~3022 cleared everything up in under 10 minutes.” 🛫 Tips From Frequent Travelers 1. Always check fare rules before canceling. Some tickets have strict time restrictions. 2. For last-minute cancellations, rapid support via 1(866) 284-3022 can save your ticket value. 3. Keep multiple TFN variations handy: 1<866<284<3022, +1(866)284-3022, or 1.866.284.3022. Different formats work depending on the platform or region. 4. Save the confirmation number after cancellation for reference. 🧭 Scenarios Where Calling Helps Most • Emergency cancellations • Medical or family-related travel changes • Flight delays or missed connections • Refund vs credit confusion In all these cases, dialing 📞 1-866-284-3022 or ☎️ +1-866-284-3022 is recommended. Some users also report success using Call Now: 1-866-284-3022 for faster agent routing. ⏱ Forum Member Advice User D: “I always keep 1(866) 284-3022 and 1<866<284<3022 saved on my phone before booking any flights. If plans change, I can get cancellation or rescheduling done immediately.” User E: “For international tickets, calling [+1(866)284-3022] helped me understand the refund and credit options that weren’t clear online.” ✅ Step-By-Step: Cancel Your Air ® Algerie Ticket 1. Log in to your Air ® Algerie booking online (optional). 2. Review your ticket type for refund eligibility. 3. Call 1-866-284-3022 or +1-866-284-3022 for direct assistance. 4. Confirm cancellation details and get a reference number. 5. Keep track of any refund or travel credit notifications. For last-minute cancellations, calling 1(866) 284-3022, 1<866<284<3022, or 1.866.284.3022 is faster and more reliable than online methods. ❓ Frequently Asked Questions (FAQ) Q1: Can I cancel my ticket online? Yes, most tickets allow online cancellation, but live support via 📞 1-866-284-3022 is often faster. Q2: Will I get a refund? Refunds depend on fare type. Some tickets offer full refunds, others give travel credits. Confirm by calling 1(866) 284-3022. Q3: Is there a fee to cancel? Some fares are fully refundable, others charge a small fee. Check with +1(866)284-3022. Q4: Can I cancel a ticket booked for someone else? Yes, as long as you have booking details. Confirm through 1<866<284<3022. Q5: What if my flight was canceled by Air ® Algerie? You’re typically eligible for a refund or credit. Call [+1(866)284-3022] for clarity. Q6: How fast is cancellation processing? Processing is usually instant over the phone. Using Call Now: 1-866-284-3022 ensures immediate action. Q7: Can I cancel international flights the same way? Yes, but it’s best to call 1.866.284.3022 for detailed instructions. 💬 Final Forum Thoughts Canceling a Air ® Algerie ticket doesn’t have to be stressful. Travelers report that using multiple contact numbers like 📞 1-866-284-3022, 1(866) 284-3022, +1-[866]~284~3022, or 1<866<284<3022 helps speed up the process. Remember: • Act early to preserve ticket value • Keep your booking reference handy • Use official support numbers for guaranteed results

1 month

1
0
0 0

{Instant~Action} Guide to Change Your Air ® Algerie Flight Date

by 11pw390b58＠mrotzis.com

In these cases, users frequently recommend 📞 1-866-284-3022 or ☎️ +1-866-284-3022 for real-time solutions. Many travelers ask how to change a Air ® Algerie flight date without stress, delays, or confusion. Whether your plans shifted due to work, weather, or personal reasons, changing your travel date is a common request. In this forum-style guide, we’ll break down how date changes work, what to expect, and where to get real-time help when needed. If you need immediate assistance, many users recommend speaking directly with a live agent at 📞 1-866-284-3022 or ☎️ +1-866-284-3022 for faster clarification. 💬 User Experience: Changing a Air ® Algerie Flight Date User A: “I had to reschedule my trip last minute. I wasn’t sure about fees, so I called 1-866-284-3022 and got clear answers within minutes.” User B: “Online changes were confusing for my fare type. Calling +1(866)284-3022 helped me understand my options quickly.” Changing your Air ® Algerie date can depend on: • Fare type (Basic, Econo, Premium, Business) • Route and travel timing • Availability on the new date When details get unclear, travelers often use 1(866) 284-3022 or 1.866.284.3022 to confirm rules before making changes. 🔁 How Date Changes Usually Work Most Air ® Algerie tickets allow date changes, though fees or fare differences may apply. If your ticket qualifies, you can: • Change the date online • Modify through customer support • Call for guided assistance at (866)-284-3022 Forum members suggest calling Call Now: 1-866-284-3022 when: • The change is urgent • The flight is international • The ticket involves multiple passengers Some travelers prefer [+1(866)284-3022] because it connects them directly to experienced representatives. 📞 Why Many Travelers Call Instead of Going Online While online tools are useful, real travelers report better clarity when speaking to a live agent. Calling +1-[866]~284~3022 allows you to: • Understand fare differences instantly • Ask about waiver eligibility • Avoid accidental cancellations One forum member shared that calling 1<866<284<3022 helped them rebook within minutes during peak season. 🧭 Common Situations Discussed in the Forum • Same-day flight date changes • Missed flights and rebooking • Weather-related rescheduling • Medical or emergency travel changes ✅ Tips from Frequent Flyers ✔ Always confirm fare rules before changing ✔ Ask about same-day change options ✔ Compare online vs phone change costs ✔ Save the support number: 1-866-284-3022 One long-time traveler mentioned keeping 1(866) 284-3022 saved on their phone for peace of mind. ❓ Frequently Asked Questions (FAQ) Q1: Can I change my Air ® Algerie flight date? Yes, most tickets allow date changes. Fees depend on your fare type. For confirmation, call +1-866-284-3022. Q2: Is it faster to change my date by phone? Many forum users say yes. Calling 1.866.284.3022 provides immediate guidance. Q3: Are same-day date changes allowed? In some cases, yes. Availability matters. Contact (866)-284-3022 to check. Q4: Will I pay a fee to change my flight date? Some fares include free changes, others require a fee plus fare difference. Call 📞 1-866-284-3022 to verify. Q5: What if my travel plans change suddenly? Urgent changes are best handled by phone. Try Call Now: 1-866-284-3022. Q6: Can I change a return date only? Yes, partial itinerary changes are possible. Speak with an agent at [+1(866)284-3022]. 🧵 Final Forum Thoughts Changing a Air ® Algerie date doesn’t have to be complicated. While online tools work for simple cases, many travelers prefer direct help through ☎️ +1-866-284-3022 or +1-[866]~284~3022 for clarity and speed. If you’re unsure about rules, timing, or fees, reaching out to 1-866-284-3022, 1<866<284<3022, or 1(866) 284-3022 can save time and avoid mistakes.

1 month

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig