[PATCH 0/2] dma-mapping: benchmark: modify the dma_map_benchmark directory

[PATCH 0/2] dma-mapping: benchmark: modify the dma_map_benchmark directory

[Qinxin Xia]

This series moves the dma_map_benchmark utility out of the selftests
directory and fixes an ABI regression introduced in an earlier change.
No functional behaviour of the benchmark itself is changed.

Qinxin Xia (2):
  tools/dma: move dma_map_benchmark from selftests to tools/dma
  dma-mapping: benchmark: Add padding to ensure uABI remained consistent

 include/linux/map_benchmark.h                     |  1 +
 tools/Makefile                                    | 13 +++++++------
 tools/dma/Makefile                                | 15 +++++++++++++++
 tools/{testing/selftests => }/dma/config          |  0
 .../selftests => }/dma/dma_map_benchmark.c        |  0
 tools/testing/selftests/dma/Makefile              |  7 -------
 6 files changed, 23 insertions(+), 13 deletions(-)
 create mode 100644 tools/dma/Makefile
 rename tools/{testing/selftests => }/dma/config (100%)
 rename tools/{testing/selftests => }/dma/dma_map_benchmark.c (100%)
 delete mode 100644 tools/testing/selftests/dma/Makefile

-- 
2.33.0

[PATCH 1/2] tools/dma: move dma_map_benchmark from selftests to tools/dma

[Qinxin Xia]

dma_map_benchmark is a standalone developer tool rather than an
automated selftest.  It has no pass/fail criteria, expects manual
invocation, and is built as a normal userspace binary.Move it to
tools/dma/ and add a minimal, the original selftest.Makefile entry
is removed to avoid duplication.

Signed-off-by: Qinxin Xia <xiaqinxin@huawei.com>
---
 tools/Makefile                                    | 13 +++++++------
 tools/dma/Makefile                                | 15 +++++++++++++++
 tools/{testing/selftests => }/dma/config          |  0
 .../selftests => }/dma/dma_map_benchmark.c        |  0
 tools/testing/selftests/dma/Makefile              |  7 -------
 5 files changed, 22 insertions(+), 13 deletions(-)
 create mode 100644 tools/dma/Makefile
 rename tools/{testing/selftests => }/dma/config (100%)
 rename tools/{testing/selftests => }/dma/dma_map_benchmark.c (100%)
 delete mode 100644 tools/testing/selftests/dma/Makefile

diff --git a/tools/Makefile b/tools/Makefile
index c31cbbd12c45..72dc0e936632 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -14,6 +14,7 @@ help:
 	@echo '  counter                - counter tools'
 	@echo '  cpupower               - a tool for all things x86 CPU power'
 	@echo '  debugging              - tools for debugging'
+	@echo '  dma                    - dma map benchmark'
 	@echo '  firewire               - the userspace part of nosy, an IEEE-1394 traffic sniffer'
 	@echo '  firmware               - Firmware tools'
 	@echo '  freefall               - laptop accelerometer program for disk protection'
@@ -69,7 +70,7 @@ acpi: FORCE
 cpupower: FORCE
 	$(call descend,power/$@)
 
-counter firewire hv guest bootconfig spi usb virtio mm bpf iio gpio objtool leds wmi firmware debugging tracing: FORCE
+counter dma firewire hv guest bootconfig spi usb virtio mm bpf iio gpio objtool leds wmi firmware debugging tracing: FORCE
 	$(call descend,$@)
 
 bpf/%: FORCE
@@ -122,7 +123,7 @@ kvm_stat: FORCE
 ynl: FORCE
 	$(call descend,net/ynl)
 
-all: acpi counter cpupower gpio hv firewire \
+all: acpi counter cpupower dma gpio hv firewire \
 		perf selftests bootconfig spi turbostat usb \
 		virtio mm bpf x86_energy_perf_policy \
 		tmon freefall iio objtool kvm_stat wmi \
@@ -134,7 +135,7 @@ acpi_install:
 cpupower_install:
 	$(call descend,power/$(@:_install=),install)
 
-counter_install firewire_install gpio_install hv_install iio_install perf_install bootconfig_install spi_install usb_install virtio_install mm_install bpf_install objtool_install wmi_install debugging_install tracing_install:
+counter_install dma_install firewire_install gpio_install hv_install iio_install perf_install bootconfig_install spi_install usb_install virtio_install mm_install bpf_install objtool_install wmi_install debugging_install tracing_install:
 	$(call descend,$(@:_install=),install)
 
 selftests_install:
@@ -164,7 +165,7 @@ kvm_stat_install:
 ynl_install:
 	$(call descend,net/$(@:_install=),install)
 
-install: acpi_install counter_install cpupower_install gpio_install \
+install: acpi_install counter_install cpupower_install dma_install gpio_install \
 		hv_install firewire_install iio_install \
 		perf_install selftests_install turbostat_install usb_install \
 		virtio_install mm_install bpf_install x86_energy_perf_policy_install \
@@ -178,7 +179,7 @@ acpi_clean:
 cpupower_clean:
 	$(call descend,power/cpupower,clean)
 
-counter_clean hv_clean firewire_clean bootconfig_clean spi_clean usb_clean virtio_clean mm_clean wmi_clean bpf_clean iio_clean gpio_clean objtool_clean leds_clean firmware_clean debugging_clean tracing_clean:
+counter_clean dma_clean hv_clean firewire_clean bootconfig_clean spi_clean usb_clean virtio_clean mm_clean wmi_clean bpf_clean iio_clean gpio_clean objtool_clean leds_clean firmware_clean debugging_clean tracing_clean:
 	$(call descend,$(@:_clean=),clean)
 
 libapi_clean:
@@ -224,7 +225,7 @@ build_clean:
 ynl_clean:
 	$(call descend,net/$(@:_clean=),clean)
 
-clean: acpi_clean counter_clean cpupower_clean hv_clean firewire_clean \
+clean: acpi_clean counter_clean cpupower_clean dma_clean hv_clean firewire_clean \
 		perf_clean selftests_clean turbostat_clean bootconfig_clean spi_clean usb_clean virtio_clean \
 		mm_clean bpf_clean iio_clean x86_energy_perf_policy_clean tmon_clean \
 		freefall_clean build_clean libbpf_clean libsubcmd_clean \
diff --git a/tools/dma/Makefile b/tools/dma/Makefile
new file mode 100644
index 000000000000..6282eb41e51a
--- /dev/null
+++ b/tools/dma/Makefile
@@ -0,0 +1,15 @@
+# SPDX-License-Identifier: GPL-2.0
+bindir ?= /usr/bin
+
+CFLAGS += -I../../include -I../../usr/include
+
+all:
+	$(CC) $(CFLAGS) dma_map_benchmark.c -o dma_map_benchmark
+
+install: all
+	install -D dma_map_benchmark $(bindir)/bin/dma_map_benchmark
+
+clean:
+	rm -f dma_map_benchmark
+
+.PHONY: all install clean
diff --git a/tools/testing/selftests/dma/config b/tools/dma/config
similarity index 100%
rename from tools/testing/selftests/dma/config
rename to tools/dma/config
diff --git a/tools/testing/selftests/dma/dma_map_benchmark.c b/tools/dma/dma_map_benchmark.c
similarity index 100%
rename from tools/testing/selftests/dma/dma_map_benchmark.c
rename to tools/dma/dma_map_benchmark.c
diff --git a/tools/testing/selftests/dma/Makefile b/tools/testing/selftests/dma/Makefile
deleted file mode 100644
index cd8c5ece1cba..000000000000
--- a/tools/testing/selftests/dma/Makefile
+++ /dev/null
@@ -1,7 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-CFLAGS += -I../../../../usr/include/
-CFLAGS += -I../../../../include/
-
-TEST_GEN_PROGS := dma_map_benchmark
-
-include ../lib.mk
-- 
2.33.0

[PATCH 2/2] dma-mapping: benchmark: Add padding to ensure uABI remained consistent

[Qinxin Xia]

The padding field in the structure was previously reserved to
maintain a stable interface for potential new fields, ensuring
compatibility with user-space shared data structures.
However,it was accidentally removed by tiantao in a prior commit,
which may lead to incompatibility between user space and the kernel.

This patch reinstates the padding to restore the original structure
layout and preserve compatibility.

Fixes: 8ddde07a3d28 ("dma-mapping: benchmark: extract a common header file for map_benchmark definition")
Cc: stable@vger.kernel.org
Acked-by: Barry Song <baohua@kernel.org>
Signed-off-by: Qinxin Xia <xiaqinxin@huawei.com>
---
 include/linux/map_benchmark.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/map_benchmark.h b/include/linux/map_benchmark.h
index 62674c83bde4..2ac2fe52f248 100644
--- a/include/linux/map_benchmark.h
+++ b/include/linux/map_benchmark.h
@@ -27,5 +27,6 @@ struct map_benchmark {
 	__u32 dma_dir; /* DMA data direction */
 	__u32 dma_trans_ns; /* time for DMA transmission in ns */
 	__u32 granule;  /* how many PAGE_SIZE will do map/unmap once a time */
+	__u8 expansion[76];     /* For future use */
 };
 #endif /* _KERNEL_DMA_BENCHMARK_H */
-- 
2.33.0

Re: [PATCH 2/2] dma-mapping: benchmark: Add padding to ensure uABI remained consistent

[Barry Song]

On Thu, Jul 24, 2025 at 4:56 PM Qinxin Xia <xiaqinxin@huawei.com> wrote:
>
> The padding field in the structure was previously reserved to
> maintain a stable interface for potential new fields, ensuring
> compatibility with user-space shared data structures.
> However,it was accidentally removed by tiantao in a prior commit,
> which may lead to incompatibility between user space and the kernel.
>
> This patch reinstates the padding to restore the original structure
> layout and preserve compatibility.
>
> Fixes: 8ddde07a3d28 ("dma-mapping: benchmark: extract a common header file for map_benchmark definition")
> Cc: stable@vger.kernel.org
> Acked-by: Barry Song <baohua@kernel.org>
> Signed-off-by: Qinxin Xia <xiaqinxin@huawei.com>

I don’t think these two patches should be part of the same series. This
one is a bug fix and should be handled separately—ideally picked up on
its own and backported to stable.

Also, the subject should not say "Add"—it should be "Restore". I assume
Marek can handle it?

> ---
>  include/linux/map_benchmark.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/map_benchmark.h b/include/linux/map_benchmark.h
> index 62674c83bde4..2ac2fe52f248 100644
> --- a/include/linux/map_benchmark.h
> +++ b/include/linux/map_benchmark.h
> @@ -27,5 +27,6 @@ struct map_benchmark {
>         __u32 dma_dir; /* DMA data direction */
>         __u32 dma_trans_ns; /* time for DMA transmission in ns */
>         __u32 granule;  /* how many PAGE_SIZE will do map/unmap once a time */
> +       __u8 expansion[76];     /* For future use */
>  };
>  #endif /* _KERNEL_DMA_BENCHMARK_H */
> --
> 2.33.0
>

Thanks
Barry

Re: [PATCH 1/2] tools/dma: move dma_map_benchmark from selftests to tools/dma

[Barry Song]

On Thu, Jul 24, 2025 at 4:56 PM Qinxin Xia <xiaqinxin@huawei.com> wrote:
>
> dma_map_benchmark is a standalone developer tool rather than an
> automated selftest.  It has no pass/fail criteria, expects manual
> invocation, and is built as a normal userspace binary.Move it to
> tools/dma/ and add a minimal, the original selftest.Makefile entry
> is removed to avoid duplication.
>
> Signed-off-by: Qinxin Xia <xiaqinxin@huawei.com>
> ---
>  tools/Makefile                                    | 13 +++++++------
>  tools/dma/Makefile                                | 15 +++++++++++++++
>  tools/{testing/selftests => }/dma/config          |  0
>  .../selftests => }/dma/dma_map_benchmark.c        |  0
>  tools/testing/selftests/dma/Makefile              |  7 -------
>  5 files changed, 22 insertions(+), 13 deletions(-)
>  create mode 100644 tools/dma/Makefile
>  rename tools/{testing/selftests => }/dma/config (100%)
>  rename tools/{testing/selftests => }/dma/dma_map_benchmark.c (100%)
>  delete mode 100644 tools/testing/selftests/dma/Makefile
>
> diff --git a/tools/Makefile b/tools/Makefile
> index c31cbbd12c45..72dc0e936632 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -14,6 +14,7 @@ help:
>         @echo '  counter                - counter tools'
>         @echo '  cpupower               - a tool for all things x86 CPU power'
>         @echo '  debugging              - tools for debugging'
> +       @echo '  dma                    - dma map benchmark'

Please make it more general. Right now we only have the DMA map
benchmark, but we might add more DMA mapping tools in the future.
For examples: tools for dma mapping

>         @echo '  firewire               - the userspace part of nosy, an IEEE-1394 traffic sniffer'
>         @echo '  firmware               - Firmware tools'
>         @echo '  freefall               - laptop accelerometer program for disk protection'
> @@ -69,7 +70,7 @@ acpi: FORCE
>  cpupower: FORCE
>         $(call descend,power/$@)
>
> -counter firewire hv guest bootconfig spi usb virtio mm bpf iio gpio objtool leds wmi firmware debugging tracing: FORCE
> +counter dma firewire hv guest bootconfig spi usb virtio mm bpf iio gpio objtool leds wmi firmware debugging tracing: FORCE
>         $(call descend,$@)
>
>  bpf/%: FORCE
> @@ -122,7 +123,7 @@ kvm_stat: FORCE
>  ynl: FORCE
>         $(call descend,net/ynl)
>
> -all: acpi counter cpupower gpio hv firewire \
> +all: acpi counter cpupower dma gpio hv firewire \
>                 perf selftests bootconfig spi turbostat usb \
>                 virtio mm bpf x86_energy_perf_policy \
>                 tmon freefall iio objtool kvm_stat wmi \
> @@ -134,7 +135,7 @@ acpi_install:
>  cpupower_install:
>         $(call descend,power/$(@:_install=),install)
>
> -counter_install firewire_install gpio_install hv_install iio_install perf_install bootconfig_install spi_install usb_install virtio_install mm_install bpf_install objtool_install wmi_install debugging_install tracing_install:
> +counter_install dma_install firewire_install gpio_install hv_install iio_install perf_install bootconfig_install spi_install usb_install virtio_install mm_install bpf_install objtool_install wmi_install debugging_install tracing_install:
>         $(call descend,$(@:_install=),install)
>
>  selftests_install:
> @@ -164,7 +165,7 @@ kvm_stat_install:
>  ynl_install:
>         $(call descend,net/$(@:_install=),install)
>
> -install: acpi_install counter_install cpupower_install gpio_install \
> +install: acpi_install counter_install cpupower_install dma_install gpio_install \
>                 hv_install firewire_install iio_install \
>                 perf_install selftests_install turbostat_install usb_install \
>                 virtio_install mm_install bpf_install x86_energy_perf_policy_install \
> @@ -178,7 +179,7 @@ acpi_clean:
>  cpupower_clean:
>         $(call descend,power/cpupower,clean)
>
> -counter_clean hv_clean firewire_clean bootconfig_clean spi_clean usb_clean virtio_clean mm_clean wmi_clean bpf_clean iio_clean gpio_clean objtool_clean leds_clean firmware_clean debugging_clean tracing_clean:
> +counter_clean dma_clean hv_clean firewire_clean bootconfig_clean spi_clean usb_clean virtio_clean mm_clean wmi_clean bpf_clean iio_clean gpio_clean objtool_clean leds_clean firmware_clean debugging_clean tracing_clean:
>         $(call descend,$(@:_clean=),clean)
>
>  libapi_clean:
> @@ -224,7 +225,7 @@ build_clean:
>  ynl_clean:
>         $(call descend,net/$(@:_clean=),clean)
>
> -clean: acpi_clean counter_clean cpupower_clean hv_clean firewire_clean \
> +clean: acpi_clean counter_clean cpupower_clean dma_clean hv_clean firewire_clean \
>                 perf_clean selftests_clean turbostat_clean bootconfig_clean spi_clean usb_clean virtio_clean \
>                 mm_clean bpf_clean iio_clean x86_energy_perf_policy_clean tmon_clean \
>                 freefall_clean build_clean libbpf_clean libsubcmd_clean \
> diff --git a/tools/dma/Makefile b/tools/dma/Makefile
> new file mode 100644
> index 000000000000..6282eb41e51a
> --- /dev/null
> +++ b/tools/dma/Makefile
> @@ -0,0 +1,15 @@
> +# SPDX-License-Identifier: GPL-2.0
> +bindir ?= /usr/bin
> +
> +CFLAGS += -I../../include -I../../usr/include
> +
> +all:
> +       $(CC) $(CFLAGS) dma_map_benchmark.c -o dma_map_benchmark
> +
> +install: all
> +       install -D dma_map_benchmark $(bindir)/bin/dma_map_benchmark
> +
> +clean:
> +       rm -f dma_map_benchmark

Please make the Makefile more general. Right now I only have
dma_map_benchmark, but the Makefile shouldn't be tailored specifically
for just that one. dma_map_benchmark is one of those targets.

And I feel $(bindir)/bin/dma_map_benchmark is an incorrect folder.

Thanks
Barry

Re: [PATCH 1/2] tools/dma: move dma_map_benchmark from selftests to tools/dma

[Qinxin Xia]

On 2025/7/24 17:25:16, Barry Song <21cnbao@gmail.com> wrote:
> On Thu, Jul 24, 2025 at 4:56 PM Qinxin Xia <xiaqinxin@huawei.com> wrote:
>>
>> dma_map_benchmark is a standalone developer tool rather than an
>> automated selftest.  It has no pass/fail criteria, expects manual
>> invocation, and is built as a normal userspace binary.Move it to
>> tools/dma/ and add a minimal, the original selftest.Makefile entry
>> is removed to avoid duplication.
>>
>> Signed-off-by: Qinxin Xia <xiaqinxin@huawei.com>
>> ---
>>   tools/Makefile                                    | 13 +++++++------
>>   tools/dma/Makefile                                | 15 +++++++++++++++
>>   tools/{testing/selftests => }/dma/config          |  0
>>   .../selftests => }/dma/dma_map_benchmark.c        |  0
>>   tools/testing/selftests/dma/Makefile              |  7 -------
>>   5 files changed, 22 insertions(+), 13 deletions(-)
>>   create mode 100644 tools/dma/Makefile
>>   rename tools/{testing/selftests => }/dma/config (100%)
>>   rename tools/{testing/selftests => }/dma/dma_map_benchmark.c (100%)
>>   delete mode 100644 tools/testing/selftests/dma/Makefile
>>
>> diff --git a/tools/Makefile b/tools/Makefile
>> index c31cbbd12c45..72dc0e936632 100644
>> --- a/tools/Makefile
>> +++ b/tools/Makefile
>> @@ -14,6 +14,7 @@ help:
>>          @echo '  counter                - counter tools'
>>          @echo '  cpupower               - a tool for all things x86 CPU power'
>>          @echo '  debugging              - tools for debugging'
>> +       @echo '  dma                    - dma map benchmark'
> 
> Please make it more general. Right now we only have the DMA map
> benchmark, but we might add more DMA mapping tools in the future.
> For examples: tools for dma mapping
> 
ok,I will fix in next version.>>          @echo '  firewire 
  - the userspace part of nosy, an IEEE-1394 traffic sniffer'
>>          @echo '  firmware               - Firmware tools'
>>          @echo '  freefall               - laptop accelerometer program for disk protection'
>> @@ -69,7 +70,7 @@ acpi: FORCE
>>   cpupower: FORCE
>>          $(call descend,power/$@)
>>
>> -counter firewire hv guest bootconfig spi usb virtio mm bpf iio gpio objtool leds wmi firmware debugging tracing: FORCE
>> +counter dma firewire hv guest bootconfig spi usb virtio mm bpf iio gpio objtool leds wmi firmware debugging tracing: FORCE
>>          $(call descend,$@)
>>
>>   bpf/%: FORCE
>> @@ -122,7 +123,7 @@ kvm_stat: FORCE
>>   ynl: FORCE
>>          $(call descend,net/ynl)
>>
>> -all: acpi counter cpupower gpio hv firewire \
>> +all: acpi counter cpupower dma gpio hv firewire \
>>                  perf selftests bootconfig spi turbostat usb \
>>                  virtio mm bpf x86_energy_perf_policy \
>>                  tmon freefall iio objtool kvm_stat wmi \
>> @@ -134,7 +135,7 @@ acpi_install:
>>   cpupower_install:
>>          $(call descend,power/$(@:_install=),install)
>>
>> -counter_install firewire_install gpio_install hv_install iio_install perf_install bootconfig_install spi_install usb_install virtio_install mm_install bpf_install objtool_install wmi_install debugging_install tracing_install:
>> +counter_install dma_install firewire_install gpio_install hv_install iio_install perf_install bootconfig_install spi_install usb_install virtio_install mm_install bpf_install objtool_install wmi_install debugging_install tracing_install:
>>          $(call descend,$(@:_install=),install)
>>
>>   selftests_install:
>> @@ -164,7 +165,7 @@ kvm_stat_install:
>>   ynl_install:
>>          $(call descend,net/$(@:_install=),install)
>>
>> -install: acpi_install counter_install cpupower_install gpio_install \
>> +install: acpi_install counter_install cpupower_install dma_install gpio_install \
>>                  hv_install firewire_install iio_install \
>>                  perf_install selftests_install turbostat_install usb_install \
>>                  virtio_install mm_install bpf_install x86_energy_perf_policy_install \
>> @@ -178,7 +179,7 @@ acpi_clean:
>>   cpupower_clean:
>>          $(call descend,power/cpupower,clean)
>>
>> -counter_clean hv_clean firewire_clean bootconfig_clean spi_clean usb_clean virtio_clean mm_clean wmi_clean bpf_clean iio_clean gpio_clean objtool_clean leds_clean firmware_clean debugging_clean tracing_clean:
>> +counter_clean dma_clean hv_clean firewire_clean bootconfig_clean spi_clean usb_clean virtio_clean mm_clean wmi_clean bpf_clean iio_clean gpio_clean objtool_clean leds_clean firmware_clean debugging_clean tracing_clean:
>>          $(call descend,$(@:_clean=),clean)
>>
>>   libapi_clean:
>> @@ -224,7 +225,7 @@ build_clean:
>>   ynl_clean:
>>          $(call descend,net/$(@:_clean=),clean)
>>
>> -clean: acpi_clean counter_clean cpupower_clean hv_clean firewire_clean \
>> +clean: acpi_clean counter_clean cpupower_clean dma_clean hv_clean firewire_clean \
>>                  perf_clean selftests_clean turbostat_clean bootconfig_clean spi_clean usb_clean virtio_clean \
>>                  mm_clean bpf_clean iio_clean x86_energy_perf_policy_clean tmon_clean \
>>                  freefall_clean build_clean libbpf_clean libsubcmd_clean \
>> diff --git a/tools/dma/Makefile b/tools/dma/Makefile
>> new file mode 100644
>> index 000000000000..6282eb41e51a
>> --- /dev/null
>> +++ b/tools/dma/Makefile
>> @@ -0,0 +1,15 @@
>> +# SPDX-License-Identifier: GPL-2.0
>> +bindir ?= /usr/bin
>> +
>> +CFLAGS += -I../../include -I../../usr/include
>> +
>> +all:
>> +       $(CC) $(CFLAGS) dma_map_benchmark.c -o dma_map_benchmark
>> +
>> +install: all
>> +       install -D dma_map_benchmark $(bindir)/bin/dma_map_benchmark
>> +
>> +clean:
>> +       rm -f dma_map_benchmark
> 
> Please make the Makefile more general. Right now I only have
> dma_map_benchmark, but the Makefile shouldn't be tailored specifically
> for just that one. dma_map_benchmark is one of those targets.
> 
> And I feel $(bindir)/bin/dma_map_benchmark is an incorrect folder.
> 
> Thanks
> Barry
Ok, in next version.I will make it more general.

Re: [PATCH 2/2] dma-mapping: benchmark: Add padding to ensure uABI remained consistent

[Qinxin Xia]

On 2025/7/24 17:07:08, Barry Song <21cnbao@gmail.com> wrote:
> On Thu, Jul 24, 2025 at 4:56 PM Qinxin Xia <xiaqinxin@huawei.com> wrote:
>>
>> The padding field in the structure was previously reserved to
>> maintain a stable interface for potential new fields, ensuring
>> compatibility with user-space shared data structures.
>> However,it was accidentally removed by tiantao in a prior commit,
>> which may lead to incompatibility between user space and the kernel.
>>
>> This patch reinstates the padding to restore the original structure
>> layout and preserve compatibility.
>>
>> Fixes: 8ddde07a3d28 ("dma-mapping: benchmark: extract a common header file for map_benchmark definition")
>> Cc: stable@vger.kernel.org
>> Acked-by: Barry Song <baohua@kernel.org>
>> Signed-off-by: Qinxin Xia <xiaqinxin@huawei.com>
> 
> I don’t think these two patches should be part of the same series. This
> one is a bug fix and should be handled separately—ideally picked up on
> its own and backported to stable.
> 
> Also, the subject should not say "Add"—it should be "Restore". I assume
> Marek can handle it?
> 
>> ---
>>   include/linux/map_benchmark.h | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/include/linux/map_benchmark.h b/include/linux/map_benchmark.h
>> index 62674c83bde4..2ac2fe52f248 100644
>> --- a/include/linux/map_benchmark.h
>> +++ b/include/linux/map_benchmark.h
>> @@ -27,5 +27,6 @@ struct map_benchmark {
>>          __u32 dma_dir; /* DMA data direction */
>>          __u32 dma_trans_ns; /* time for DMA transmission in ns */
>>          __u32 granule;  /* how many PAGE_SIZE will do map/unmap once a time */
>> +       __u8 expansion[76];     /* For future use */
>>   };
>>   #endif /* _KERNEL_DMA_BENCHMARK_H */
>> --
>> 2.33.0
>>
> 
> Thanks
> Barry

Ok, I will send a new version to fix it.
Thanks

Re: [PATCH 2/2] dma-mapping: benchmark: Add padding to ensure uABI remained consistent

[Barry Song]

On Thu, Jul 24, 2025 at 5:35 PM Qinxin Xia <xiaqinxin@huawei.com> wrote:
>
>
>
> On 2025/7/24 17:07:08, Barry Song <21cnbao@gmail.com> wrote:
> > On Thu, Jul 24, 2025 at 4:56 PM Qinxin Xia <xiaqinxin@huawei.com> wrote:
> >>
> >> The padding field in the structure was previously reserved to
> >> maintain a stable interface for potential new fields, ensuring
> >> compatibility with user-space shared data structures.
> >> However,it was accidentally removed by tiantao in a prior commit,
> >> which may lead to incompatibility between user space and the kernel.
> >>
> >> This patch reinstates the padding to restore the original structure
> >> layout and preserve compatibility.
> >>
> >> Fixes: 8ddde07a3d28 ("dma-mapping: benchmark: extract a common header file for map_benchmark definition")
> >> Cc: stable@vger.kernel.org
> >> Acked-by: Barry Song <baohua@kernel.org>
> >> Signed-off-by: Qinxin Xia <xiaqinxin@huawei.com>
> >
> > I don’t think these two patches should be part of the same series. This
> > one is a bug fix and should be handled separately—ideally picked up on
> > its own and backported to stable.
> >
> > Also, the subject should not say "Add"—it should be "Restore". I assume
> > Marek can handle it?
...
> Ok, I will send a new version to fix it.

If Marek can help fix it while picking it up into the dma-mapping tree, you
might not need to send a new version.

Honestly, I hope this gets merged soon—it feels like it's been
overdue for quite a while.

Thanks
Barry

Re: [PATCH 2/2] dma-mapping: benchmark: Add padding to ensure uABI remained consistent

[Marek Szyprowski]

On 24.07.2025 11:42, Barry Song wrote:
> On Thu, Jul 24, 2025 at 5:35 PM Qinxin Xia <xiaqinxin@huawei.com> wrote:
>> On 2025/7/24 17:07:08, Barry Song <21cnbao@gmail.com> wrote:
>>> On Thu, Jul 24, 2025 at 4:56 PM Qinxin Xia <xiaqinxin@huawei.com> wrote:
>>>> The padding field in the structure was previously reserved to
>>>> maintain a stable interface for potential new fields, ensuring
>>>> compatibility with user-space shared data structures.
>>>> However,it was accidentally removed by tiantao in a prior commit,
>>>> which may lead to incompatibility between user space and the kernel.
>>>>
>>>> This patch reinstates the padding to restore the original structure
>>>> layout and preserve compatibility.
>>>>
>>>> Fixes: 8ddde07a3d28 ("dma-mapping: benchmark: extract a common header file for map_benchmark definition")
>>>> Cc: stable@vger.kernel.org
>>>> Acked-by: Barry Song <baohua@kernel.org>
>>>> Signed-off-by: Qinxin Xia <xiaqinxin@huawei.com>
>>> I don’t think these two patches should be part of the same series. This
>>> one is a bug fix and should be handled separately—ideally picked up on
>>> its own and backported to stable.
>>>
>>> Also, the subject should not say "Add"—it should be "Restore". I assume
>>> Marek can handle it?
> ...
>> Ok, I will send a new version to fix it.
> If Marek can help fix it while picking it up into the dma-mapping tree, you
> might not need to send a new version.
>
> Honestly, I hope this gets merged soon—it feels like it's been
> overdue for quite a while.

I'm sorry, I wasn't aware that this need to go via dma-mapping tree. I 
will take it after this merge window.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [PATCH 2/2] dma-mapping: benchmark: Add padding to ensure uABI remained consistent

[Barry Song]

On Tue, Jul 29, 2025 at 8:32 PM Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
>
> On 24.07.2025 11:42, Barry Song wrote:
> > On Thu, Jul 24, 2025 at 5:35 PM Qinxin Xia <xiaqinxin@huawei.com> wrote:
> >> On 2025/7/24 17:07:08, Barry Song <21cnbao@gmail.com> wrote:
> >>> On Thu, Jul 24, 2025 at 4:56 PM Qinxin Xia <xiaqinxin@huawei.com> wrote:
> >>>> The padding field in the structure was previously reserved to
> >>>> maintain a stable interface for potential new fields, ensuring
> >>>> compatibility with user-space shared data structures.
> >>>> However,it was accidentally removed by tiantao in a prior commit,
> >>>> which may lead to incompatibility between user space and the kernel.
> >>>>
> >>>> This patch reinstates the padding to restore the original structure
> >>>> layout and preserve compatibility.
> >>>>
> >>>> Fixes: 8ddde07a3d28 ("dma-mapping: benchmark: extract a common header file for map_benchmark definition")
> >>>> Cc: stable@vger.kernel.org
> >>>> Acked-by: Barry Song <baohua@kernel.org>
> >>>> Signed-off-by: Qinxin Xia <xiaqinxin@huawei.com>
> >>> I don’t think these two patches should be part of the same series. This
> >>> one is a bug fix and should be handled separately—ideally picked up on
> >>> its own and backported to stable.
> >>>
> >>> Also, the subject should not say "Add"—it should be "Restore". I assume
> >>> Marek can handle it?
> > ...
> >> Ok, I will send a new version to fix it.
> > If Marek can help fix it while picking it up into the dma-mapping tree, you
> > might not need to send a new version.
> >
> > Honestly, I hope this gets merged soon—it feels like it's been
> > overdue for quite a while.
>
> I'm sorry, I wasn't aware that this need to go via dma-mapping tree. I
> will take it after this merge window.

Thank you, Marek! I also noticed that Xiang Chen’s email has been invalid
for quite a while, likely he moved to another company some time ago. It looks
like Yicong has volunteered to take this on:

https://lkml.indiana.edu/2408.1/08865.html

I'm not sure if that's still the case. If it is, would Yicong be able to
resend the email with my ack?

>
> Best regards
> --
> Marek Szyprowski, PhD
> Samsung R&D Institute Poland
>

Thanks
Barry

Re: [PATCH 2/2] dma-mapping: benchmark: Add padding to ensure uABI remained consistent

[Yicong Yang]

Hi Barry,

On 2025/8/4 12:47, Barry Song wrote:
> On Tue, Jul 29, 2025 at 8:32 PM Marek Szyprowski
> <m.szyprowski@samsung.com> wrote:
>>
>> On 24.07.2025 11:42, Barry Song wrote:
>>> On Thu, Jul 24, 2025 at 5:35 PM Qinxin Xia <xiaqinxin@huawei.com> wrote:
>>>> On 2025/7/24 17:07:08, Barry Song <21cnbao@gmail.com> wrote:
>>>>> On Thu, Jul 24, 2025 at 4:56 PM Qinxin Xia <xiaqinxin@huawei.com> wrote:
>>>>>> The padding field in the structure was previously reserved to
>>>>>> maintain a stable interface for potential new fields, ensuring
>>>>>> compatibility with user-space shared data structures.
>>>>>> However,it was accidentally removed by tiantao in a prior commit,
>>>>>> which may lead to incompatibility between user space and the kernel.
>>>>>>
>>>>>> This patch reinstates the padding to restore the original structure
>>>>>> layout and preserve compatibility.
>>>>>>
>>>>>> Fixes: 8ddde07a3d28 ("dma-mapping: benchmark: extract a common header file for map_benchmark definition")
>>>>>> Cc: stable@vger.kernel.org
>>>>>> Acked-by: Barry Song <baohua@kernel.org>
>>>>>> Signed-off-by: Qinxin Xia <xiaqinxin@huawei.com>
>>>>> I don’t think these two patches should be part of the same series. This
>>>>> one is a bug fix and should be handled separately—ideally picked up on
>>>>> its own and backported to stable.
>>>>>
>>>>> Also, the subject should not say "Add"—it should be "Restore". I assume
>>>>> Marek can handle it?
>>> ...
>>>> Ok, I will send a new version to fix it.
>>> If Marek can help fix it while picking it up into the dma-mapping tree, you
>>> might not need to send a new version.
>>>
>>> Honestly, I hope this gets merged soon—it feels like it's been
>>> overdue for quite a while.
>>
>> I'm sorry, I wasn't aware that this need to go via dma-mapping tree. I
>> will take it after this merge window.
> 
> Thank you, Marek! I also noticed that Xiang Chen’s email has been invalid
> for quite a while, likely he moved to another company some time ago. It looks
> like Yicong has volunteered to take this on:
> 
> https://lkml.indiana.edu/2408.1/08865.html
> 
> I'm not sure if that's still the case. If it is, would Yicong be able to
> resend the email with my ack?
> 

thanks for reminding. I think currently Qinxin is more suitable to help with this.
she's working on the smmu stuffs and help look after this benchmark tool internally
for some time :)

Maybe she can help along with you (ack the fact that you're always helping to review
the codes) if it's ok with you.

Thanks.

Re: [PATCH 2/2] dma-mapping: benchmark: Add padding to ensure uABI remained consistent

[Barry Song]

On Mon, Aug 4, 2025 at 8:12 PM Yicong Yang <yangyicong@huawei.com> wrote:
>
> Hi Barry,
>
> On 2025/8/4 12:47, Barry Song wrote:
> > On Tue, Jul 29, 2025 at 8:32 PM Marek Szyprowski
> > <m.szyprowski@samsung.com> wrote:
> >>
> >> On 24.07.2025 11:42, Barry Song wrote:
> >>> On Thu, Jul 24, 2025 at 5:35 PM Qinxin Xia <xiaqinxin@huawei.com> wrote:
> >>>> On 2025/7/24 17:07:08, Barry Song <21cnbao@gmail.com> wrote:
> >>>>> On Thu, Jul 24, 2025 at 4:56 PM Qinxin Xia <xiaqinxin@huawei.com> wrote:
> >>>>>> The padding field in the structure was previously reserved to
> >>>>>> maintain a stable interface for potential new fields, ensuring
> >>>>>> compatibility with user-space shared data structures.
> >>>>>> However,it was accidentally removed by tiantao in a prior commit,
> >>>>>> which may lead to incompatibility between user space and the kernel.
> >>>>>>
> >>>>>> This patch reinstates the padding to restore the original structure
> >>>>>> layout and preserve compatibility.
> >>>>>>
> >>>>>> Fixes: 8ddde07a3d28 ("dma-mapping: benchmark: extract a common header file for map_benchmark definition")
> >>>>>> Cc: stable@vger.kernel.org
> >>>>>> Acked-by: Barry Song <baohua@kernel.org>
> >>>>>> Signed-off-by: Qinxin Xia <xiaqinxin@huawei.com>
> >>>>> I don’t think these two patches should be part of the same series. This
> >>>>> one is a bug fix and should be handled separately—ideally picked up on
> >>>>> its own and backported to stable.
> >>>>>
> >>>>> Also, the subject should not say "Add"—it should be "Restore". I assume
> >>>>> Marek can handle it?
> >>> ...
> >>>> Ok, I will send a new version to fix it.
> >>> If Marek can help fix it while picking it up into the dma-mapping tree, you
> >>> might not need to send a new version.
> >>>
> >>> Honestly, I hope this gets merged soon—it feels like it's been
> >>> overdue for quite a while.
> >>
> >> I'm sorry, I wasn't aware that this need to go via dma-mapping tree. I
> >> will take it after this merge window.
> >
> > Thank you, Marek! I also noticed that Xiang Chen’s email has been invalid
> > for quite a while, likely he moved to another company some time ago. It looks
> > like Yicong has volunteered to take this on:
> >
> > https://lkml.indiana.edu/2408.1/08865.html
> >
> > I'm not sure if that's still the case. If it is, would Yicong be able to
> > resend the email with my ack?
> >
>
> thanks for reminding. I think currently Qinxin is more suitable to help with this.
> she's working on the smmu stuffs and help look after this benchmark tool internally
> for some time :)
>
> Maybe she can help along with you (ack the fact that you're always helping to review
> the codes) if it's ok with you.

Certainly, Qinxin is welcome to take over. I will be glad to review
the code when time
permits, although my schedule is typically quite occupied with mm.

Thanks
Barry

[PATCH 1/2] tools/dma: move dma_map_benchmark from selftests to tools/dma

[Qinxin Xia]

dma_map_benchmark is a standalone developer tool rather than an
automated selftest. It has no pass/fail criteria, expects manual
invocation, and is built as a normal userspace binary. Move it to
tools/dma/ and add a minimal, the original selftest/dma/Makefile
entry is removed to avoid duplication.

Signed-off-by: Qinxin Xia <xiaqinxin@huawei.com>
---
 tools/Makefile                                  | 13 +++++++------
 tools/dma/Makefile                              | 17 +++++++++++++++++
 tools/{testing/selftests => }/dma/config        |  0
 .../selftests => }/dma/dma_map_benchmark.c      |  0
 tools/testing/selftests/dma/Makefile            |  7 -------
 5 files changed, 24 insertions(+), 13 deletions(-)
 create mode 100644 tools/dma/Makefile
 rename tools/{testing/selftests => }/dma/config (100%)
 rename tools/{testing/selftests => }/dma/dma_map_benchmark.c (100%)
 delete mode 100644 tools/testing/selftests/dma/Makefile

diff --git a/tools/Makefile b/tools/Makefile
index c31cbbd12c45..cb40961a740f 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -14,6 +14,7 @@ help:
 	@echo '  counter                - counter tools'
 	@echo '  cpupower               - a tool for all things x86 CPU power'
 	@echo '  debugging              - tools for debugging'
+	@echo '  dma                    - tools for DMA mapping'
 	@echo '  firewire               - the userspace part of nosy, an IEEE-1394 traffic sniffer'
 	@echo '  firmware               - Firmware tools'
 	@echo '  freefall               - laptop accelerometer program for disk protection'
@@ -69,7 +70,7 @@ acpi: FORCE
 cpupower: FORCE
 	$(call descend,power/$@)
 
-counter firewire hv guest bootconfig spi usb virtio mm bpf iio gpio objtool leds wmi firmware debugging tracing: FORCE
+counter dma firewire hv guest bootconfig spi usb virtio mm bpf iio gpio objtool leds wmi firmware debugging tracing: FORCE
 	$(call descend,$@)
 
 bpf/%: FORCE
@@ -122,7 +123,7 @@ kvm_stat: FORCE
 ynl: FORCE
 	$(call descend,net/ynl)
 
-all: acpi counter cpupower gpio hv firewire \
+all: acpi counter cpupower dma gpio hv firewire \
 		perf selftests bootconfig spi turbostat usb \
 		virtio mm bpf x86_energy_perf_policy \
 		tmon freefall iio objtool kvm_stat wmi \
@@ -134,7 +135,7 @@ acpi_install:
 cpupower_install:
 	$(call descend,power/$(@:_install=),install)
 
-counter_install firewire_install gpio_install hv_install iio_install perf_install bootconfig_install spi_install usb_install virtio_install mm_install bpf_install objtool_install wmi_install debugging_install tracing_install:
+counter_install dma_install firewire_install gpio_install hv_install iio_install perf_install bootconfig_install spi_install usb_install virtio_install mm_install bpf_install objtool_install wmi_install debugging_install tracing_install:
 	$(call descend,$(@:_install=),install)
 
 selftests_install:
@@ -164,7 +165,7 @@ kvm_stat_install:
 ynl_install:
 	$(call descend,net/$(@:_install=),install)
 
-install: acpi_install counter_install cpupower_install gpio_install \
+install: acpi_install counter_install cpupower_install dma_install gpio_install \
 		hv_install firewire_install iio_install \
 		perf_install selftests_install turbostat_install usb_install \
 		virtio_install mm_install bpf_install x86_energy_perf_policy_install \
@@ -178,7 +179,7 @@ acpi_clean:
 cpupower_clean:
 	$(call descend,power/cpupower,clean)
 
-counter_clean hv_clean firewire_clean bootconfig_clean spi_clean usb_clean virtio_clean mm_clean wmi_clean bpf_clean iio_clean gpio_clean objtool_clean leds_clean firmware_clean debugging_clean tracing_clean:
+counter_clean dma_clean hv_clean firewire_clean bootconfig_clean spi_clean usb_clean virtio_clean mm_clean wmi_clean bpf_clean iio_clean gpio_clean objtool_clean leds_clean firmware_clean debugging_clean tracing_clean:
 	$(call descend,$(@:_clean=),clean)
 
 libapi_clean:
@@ -224,7 +225,7 @@ build_clean:
 ynl_clean:
 	$(call descend,net/$(@:_clean=),clean)
 
-clean: acpi_clean counter_clean cpupower_clean hv_clean firewire_clean \
+clean: acpi_clean counter_clean cpupower_clean dma_clean hv_clean firewire_clean \
 		perf_clean selftests_clean turbostat_clean bootconfig_clean spi_clean usb_clean virtio_clean \
 		mm_clean bpf_clean iio_clean x86_energy_perf_policy_clean tmon_clean \
 		freefall_clean build_clean libbpf_clean libsubcmd_clean \
diff --git a/tools/dma/Makefile b/tools/dma/Makefile
new file mode 100644
index 000000000000..841b54896288
--- /dev/null
+++ b/tools/dma/Makefile
@@ -0,0 +1,17 @@
+# SPDX-License-Identifier: GPL-2.0
+bindir ?= /usr/bin
+
+CFLAGS += -I../../include -I../../usr/include
+
+TARGET = dma_map_benchmark
+
+all: $(TARGET)
+
+$(TARGET): $(TARGET).c
+	$(CC) $(CFLAGS) $< -o $@
+
+install: all
+	install -D -m 755 $(TARGET) $(DESTDIR)$(bindir)/$(TARGET)
+
+clean:
+	rm -f $(TARGET)
diff --git a/tools/testing/selftests/dma/config b/tools/dma/config
similarity index 100%
rename from tools/testing/selftests/dma/config
rename to tools/dma/config
diff --git a/tools/testing/selftests/dma/dma_map_benchmark.c b/tools/dma/dma_map_benchmark.c
similarity index 100%
rename from tools/testing/selftests/dma/dma_map_benchmark.c
rename to tools/dma/dma_map_benchmark.c
diff --git a/tools/testing/selftests/dma/Makefile b/tools/testing/selftests/dma/Makefile
deleted file mode 100644
index cd8c5ece1cba..000000000000
--- a/tools/testing/selftests/dma/Makefile
+++ /dev/null
@@ -1,7 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-CFLAGS += -I../../../../usr/include/
-CFLAGS += -I../../../../include/
-
-TEST_GEN_PROGS := dma_map_benchmark
-
-include ../lib.mk
-- 
2.33.0

Re: [PATCH 1/2] tools/dma: move dma_map_benchmark from selftests to tools/dma

[Barry Song]

On Fri, Aug 15, 2025 at 1:35 AM Qinxin Xia <xiaqinxin@huawei.com> wrote:
>
> dma_map_benchmark is a standalone developer tool rather than an
> automated selftest. It has no pass/fail criteria, expects manual
> invocation, and is built as a normal userspace binary. Move it to
> tools/dma/ and add a minimal, the original selftest/dma/Makefile
> entry is removed to avoid duplication.
>
> Signed-off-by: Qinxin Xia <xiaqinxin@huawei.com>
> ---
>  tools/Makefile                                  | 13 +++++++------
>  tools/dma/Makefile                              | 17 +++++++++++++++++
>  tools/{testing/selftests => }/dma/config        |  0
>  .../selftests => }/dma/dma_map_benchmark.c      |  0
>  tools/testing/selftests/dma/Makefile            |  7 -------
>  5 files changed, 24 insertions(+), 13 deletions(-)
>  create mode 100644 tools/dma/Makefile
>  rename tools/{testing/selftests => }/dma/config (100%)
>  rename tools/{testing/selftests => }/dma/dma_map_benchmark.c (100%)
>  delete mode 100644 tools/testing/selftests/dma/Makefile
>

Please ensure the build passes at least. If you cd into tools/mm or
tools/spi, everything builds fine.

tools/spi$ make
mkdir -p include/linux/spi 2>&1 || true
ln -sf /home/barrysong/develop/mm/tools/spi/../../include/uapi/linux/spi/spidev.h
include/linux/spi
ln -sf /home/barrysong/develop/mm/tools/spi/../../include/uapi/linux/spi/spi.h
include/linux/spi
make[1]: Entering directory '/home/barrysong/develop/mm/tools/spi'
  CC      spidev_test.o
  LD      spidev_test-in.o
make[1]: Leaving directory '/home/barrysong/develop/mm/tools/spi'
  LINK    spidev_test
make[1]: Entering directory '/home/barrysong/develop/mm/tools/spi'
  CC      spidev_fdx.o
  LD      spidev_fdx-in.o
make[1]: Leaving directory '/home/barrysong/develop/mm/tools/spi'
  LINK    spidev_fdx


tools/mm$ make
make -C ../lib/api
make[1]: Entering directory '/home/barrysong/develop/mm/tools/lib/api'
  CC      fd/array.o
  LD      fd/libapi-in.o
  CC      fs/fs.o
  CC      fs/tracing_path.o
  CC      fs/cgroup.o
  LD      fs/libapi-in.o
  CC      cpu.o
  CC      debug.o
  CC      str_error_r.o
  LD      libapi-in.o
  AR      libapi.a
make[1]: Leaving directory '/home/barrysong/develop/mm/tools/lib/api'
gcc -Wall -Wextra -I../lib/ -pthread -o page-types page-types.c
../lib/api/libapi.a -pthread
gcc -Wall -Wextra -I../lib/ -pthread -o slabinfo slabinfo.c
../lib/api/libapi.a -pthread
gcc -Wall -Wextra -I../lib/ -pthread -o page_owner_sort
page_owner_sort.c ../lib/api/libapi.a -pthread
gcc -Wall -Wextra -I../lib/ -pthread -o thp_swap_allocator_test
thp_swap_allocator_test.c ../lib/api/libapi.a -pthread


If you navigate to tools/dma and run make:

tools/dma$ make
cc -I../../include -I../../usr/include dma_map_benchmark.c -o dma_map_benchmark
In file included from dma_map_benchmark.c:13:
../../include/linux/types.h:20:33: error: conflicting types for
‘fd_set’; have ‘__kernel_fd_set’
   20 | typedef __kernel_fd_set         fd_set;
      |                                 ^~~~~~
In file included from /usr/include/x86_64-linux-gnu/sys/types.h:179,
                 from /usr/include/stdlib.h:395,
                 from dma_map_benchmark.c:8:
/usr/include/x86_64-linux-gnu/sys/select.h:70:5: note: previous
declaration of ‘fd_set’ with type ‘fd_set’
   70 |   } fd_set;
      |     ^~~~~~
In file included from dma_map_benchmark.c:13:
../../include/linux/types.h:21:33: error: conflicting types for
‘dev_t’; have ‘__kernel_dev_t’ {aka ‘unsigned int’}
   21 | typedef __kernel_dev_t          dev_t;
      |                                 ^~~~~
In file included from /usr/include/stdlib.h:395,
                 from dma_map_benchmark.c:8:
/usr/include/x86_64-linux-gnu/sys/types.h:59:17: note: previous
declaration of ‘dev_t’ with type ‘dev_t’ {aka ‘long unsigned int’}
   59 | typedef __dev_t dev_t;
      |                 ^~~~~
In file included from dma_map_benchmark.c:13:
../../include/linux/types.h:25:33: error: conflicting types for
‘nlink_t’; have ‘u32’ {aka ‘unsigned int’}
   25 | typedef u32                     nlink_t;
      |                                 ^~~~~~~
In file included from /usr/include/stdlib.h:395,
                 from dma_map_benchmark.c:8:
/usr/include/x86_64-linux-gnu/sys/types.h:74:19: note: previous
declaration of ‘nlink_t’ with type ‘nlink_t’ {aka ‘long unsigned int’}
   74 | typedef __nlink_t nlink_t;
      |                   ^~~~~~~
In file included from dma_map_benchmark.c:13:
../../include/linux/types.h:31:33: error: conflicting types for
‘timer_t’; have ‘__kernel_timer_t’ {aka ‘int’}
   31 | typedef __kernel_timer_t        timer_t;
      |                                 ^~~~~~~
In file included from /usr/include/x86_64-linux-gnu/sys/types.h:130,
                 from /usr/include/stdlib.h:395,
                 from dma_map_benchmark.c:8:
/usr/include/x86_64-linux-gnu/bits/types/timer_t.h:7:19: note:
previous declaration of ‘timer_t’ with type ‘timer_t’ {aka ‘void *’}
    7 | typedef __timer_t timer_t;
      |                   ^~~~~~~
In file included from dma_map_benchmark.c:13:
../../include/linux/types.h:52:33: error: conflicting types for
‘loff_t’; have ‘__kernel_loff_t’ {aka ‘long long int’}
   52 | typedef __kernel_loff_t         loff_t;
      |                                 ^~~~~~
In file included from /usr/include/stdlib.h:395,
                 from dma_map_benchmark.c:8:
/usr/include/x86_64-linux-gnu/sys/types.h:42:18: note: previous
declaration of ‘loff_t’ with type ‘loff_t’ {aka ‘long int’}
   42 | typedef __loff_t loff_t;
      |                  ^~~~~~
In file included from dma_map_benchmark.c:13:
../../include/linux/types.h:115:33: error: conflicting types for
‘u_int64_t’; have ‘u64’ {aka ‘long long unsigned int’}
  115 | typedef u64                     u_int64_t;
      |                                 ^~~~~~~~~
In file included from /usr/include/stdlib.h:395,
                 from dma_map_benchmark.c:8:
/usr/include/x86_64-linux-gnu/sys/types.h:161:20: note: previous
declaration of ‘u_int64_t’ with type ‘u_int64_t’ {aka ‘long unsigned
int’}
  161 | typedef __uint64_t u_int64_t;
      |                    ^~~~~~~~~
In file included from dma_map_benchmark.c:13:
../../include/linux/types.h:116:33: error: conflicting types for
‘int64_t’; have ‘s64’ {aka ‘long long int’}
  116 | typedef s64                     int64_t;
      |                                 ^~~~~~~
In file included from /usr/include/x86_64-linux-gnu/sys/types.h:155,
                 from /usr/include/stdlib.h:395,
                 from dma_map_benchmark.c:8:
/usr/include/x86_64-linux-gnu/bits/stdint-intn.h:27:19: note: previous
declaration of ‘int64_t’ with type ‘int64_t’ {aka ‘long int’}
   27 | typedef __int64_t int64_t;
      |                   ^~~~~~~
In file included from dma_map_benchmark.c:13:
../../include/linux/types.h:137:13: error: conflicting types for
‘blkcnt_t’; have ‘u64’ {aka ‘long long unsigned int’}
  137 | typedef u64 blkcnt_t;
      |             ^~~~~~~~
In file included from /usr/include/stdlib.h:395,
                 from dma_map_benchmark.c:8:
/usr/include/x86_64-linux-gnu/sys/types.h:192:20: note: previous
declaration of ‘blkcnt_t’ with type ‘blkcnt_t’ {aka ‘long int’}
  192 | typedef __blkcnt_t blkcnt_t;     /* Type to count number of
disk blocks.  */
      |                    ^~~~~~~~
make: *** [Makefile:11: dma_map_benchmark] Error 1

Thanks
Barry

Re: [PATCH 1/2] tools/dma: move dma_map_benchmark from selftests to tools/dma

[Qinxin Xia]

On 2025/8/15 18:03:28, Barry Song <21cnbao@gmail.com> wrote:
> On Fri, Aug 15, 2025 at 1:35 AM Qinxin Xia <xiaqinxin@huawei.com> wrote:
>>
>> dma_map_benchmark is a standalone developer tool rather than an
>> automated selftest. It has no pass/fail criteria, expects manual
>> invocation, and is built as a normal userspace binary. Move it to
>> tools/dma/ and add a minimal, the original selftest/dma/Makefile
>> entry is removed to avoid duplication.
>>
>> Signed-off-by: Qinxin Xia <xiaqinxin@huawei.com>
>> ---
>>   tools/Makefile                                  | 13 +++++++------
>>   tools/dma/Makefile                              | 17 +++++++++++++++++
>>   tools/{testing/selftests => }/dma/config        |  0
>>   .../selftests => }/dma/dma_map_benchmark.c      |  0
>>   tools/testing/selftests/dma/Makefile            |  7 -------
>>   5 files changed, 24 insertions(+), 13 deletions(-)
>>   create mode 100644 tools/dma/Makefile
>>   rename tools/{testing/selftests => }/dma/config (100%)
>>   rename tools/{testing/selftests => }/dma/dma_map_benchmark.c (100%)
>>   delete mode 100644 tools/testing/selftests/dma/Makefile
>>
> 
> Please ensure the build passes at least. If you cd into tools/mm or
> tools/spi, everything builds fine.
> 
> tools/spi$ make
> mkdir -p include/linux/spi 2>&1 || true
> ln -sf /home/barrysong/develop/mm/tools/spi/../../include/uapi/linux/spi/spidev.h
> include/linux/spi
> ln -sf /home/barrysong/develop/mm/tools/spi/../../include/uapi/linux/spi/spi.h
> include/linux/spi
> make[1]: Entering directory '/home/barrysong/develop/mm/tools/spi'
>    CC      spidev_test.o
>    LD      spidev_test-in.o
> make[1]: Leaving directory '/home/barrysong/develop/mm/tools/spi'
>    LINK    spidev_test
> make[1]: Entering directory '/home/barrysong/develop/mm/tools/spi'
>    CC      spidev_fdx.o
>    LD      spidev_fdx-in.o
> make[1]: Leaving directory '/home/barrysong/develop/mm/tools/spi'
>    LINK    spidev_fdx
> 
> 
> tools/mm$ make
> make -C ../lib/api
> make[1]: Entering directory '/home/barrysong/develop/mm/tools/lib/api'
>    CC      fd/array.o
>    LD      fd/libapi-in.o
>    CC      fs/fs.o
>    CC      fs/tracing_path.o
>    CC      fs/cgroup.o
>    LD      fs/libapi-in.o
>    CC      cpu.o
>    CC      debug.o
>    CC      str_error_r.o
>    LD      libapi-in.o
>    AR      libapi.a
> make[1]: Leaving directory '/home/barrysong/develop/mm/tools/lib/api'
> gcc -Wall -Wextra -I../lib/ -pthread -o page-types page-types.c
> ../lib/api/libapi.a -pthread
> gcc -Wall -Wextra -I../lib/ -pthread -o slabinfo slabinfo.c
> ../lib/api/libapi.a -pthread
> gcc -Wall -Wextra -I../lib/ -pthread -o page_owner_sort
> page_owner_sort.c ../lib/api/libapi.a -pthread
> gcc -Wall -Wextra -I../lib/ -pthread -o thp_swap_allocator_test
> thp_swap_allocator_test.c ../lib/api/libapi.a -pthread
> 
> 
> If you navigate to tools/dma and run make:
> 
> tools/dma$ make
> cc -I../../include -I../../usr/include dma_map_benchmark.c -o dma_map_benchmark
> In file included from dma_map_benchmark.c:13:
> ../../include/linux/types.h:20:33: error: conflicting types for
> ‘fd_set’; have ‘__kernel_fd_set’
>     20 | typedef __kernel_fd_set         fd_set;
>        |                                 ^~~~~~
> In file included from /usr/include/x86_64-linux-gnu/sys/types.h:179,
>                   from /usr/include/stdlib.h:395,
>                   from dma_map_benchmark.c:8:
> /usr/include/x86_64-linux-gnu/sys/select.h:70:5: note: previous
> declaration of ‘fd_set’ with type ‘fd_set’
>     70 |   } fd_set;
>        |     ^~~~~~
> In file included from dma_map_benchmark.c:13:
> ../../include/linux/types.h:21:33: error: conflicting types for
> ‘dev_t’; have ‘__kernel_dev_t’ {aka ‘unsigned int’}
>     21 | typedef __kernel_dev_t          dev_t;
>        |                                 ^~~~~
> In file included from /usr/include/stdlib.h:395,
>                   from dma_map_benchmark.c:8:
> /usr/include/x86_64-linux-gnu/sys/types.h:59:17: note: previous
> declaration of ‘dev_t’ with type ‘dev_t’ {aka ‘long unsigned int’}
>     59 | typedef __dev_t dev_t;
>        |                 ^~~~~
> In file included from dma_map_benchmark.c:13:
> ../../include/linux/types.h:25:33: error: conflicting types for
> ‘nlink_t’; have ‘u32’ {aka ‘unsigned int’}
>     25 | typedef u32                     nlink_t;
>        |                                 ^~~~~~~
> In file included from /usr/include/stdlib.h:395,
>                   from dma_map_benchmark.c:8:
> /usr/include/x86_64-linux-gnu/sys/types.h:74:19: note: previous
> declaration of ‘nlink_t’ with type ‘nlink_t’ {aka ‘long unsigned int’}
>     74 | typedef __nlink_t nlink_t;
>        |                   ^~~~~~~
> In file included from dma_map_benchmark.c:13:
> ../../include/linux/types.h:31:33: error: conflicting types for
> ‘timer_t’; have ‘__kernel_timer_t’ {aka ‘int’}
>     31 | typedef __kernel_timer_t        timer_t;
>        |                                 ^~~~~~~
> In file included from /usr/include/x86_64-linux-gnu/sys/types.h:130,
>                   from /usr/include/stdlib.h:395,
>                   from dma_map_benchmark.c:8:
> /usr/include/x86_64-linux-gnu/bits/types/timer_t.h:7:19: note:
> previous declaration of ‘timer_t’ with type ‘timer_t’ {aka ‘void *’}
>      7 | typedef __timer_t timer_t;
>        |                   ^~~~~~~
> In file included from dma_map_benchmark.c:13:
> ../../include/linux/types.h:52:33: error: conflicting types for
> ‘loff_t’; have ‘__kernel_loff_t’ {aka ‘long long int’}
>     52 | typedef __kernel_loff_t         loff_t;
>        |                                 ^~~~~~
> In file included from /usr/include/stdlib.h:395,
>                   from dma_map_benchmark.c:8:
> /usr/include/x86_64-linux-gnu/sys/types.h:42:18: note: previous
> declaration of ‘loff_t’ with type ‘loff_t’ {aka ‘long int’}
>     42 | typedef __loff_t loff_t;
>        |                  ^~~~~~
> In file included from dma_map_benchmark.c:13:
> ../../include/linux/types.h:115:33: error: conflicting types for
> ‘u_int64_t’; have ‘u64’ {aka ‘long long unsigned int’}
>    115 | typedef u64                     u_int64_t;
>        |                                 ^~~~~~~~~
> In file included from /usr/include/stdlib.h:395,
>                   from dma_map_benchmark.c:8:
> /usr/include/x86_64-linux-gnu/sys/types.h:161:20: note: previous
> declaration of ‘u_int64_t’ with type ‘u_int64_t’ {aka ‘long unsigned
> int’}
>    161 | typedef __uint64_t u_int64_t;
>        |                    ^~~~~~~~~
> In file included from dma_map_benchmark.c:13:
> ../../include/linux/types.h:116:33: error: conflicting types for
> ‘int64_t’; have ‘s64’ {aka ‘long long int’}
>    116 | typedef s64                     int64_t;
>        |                                 ^~~~~~~
> In file included from /usr/include/x86_64-linux-gnu/sys/types.h:155,
>                   from /usr/include/stdlib.h:395,
>                   from dma_map_benchmark.c:8:
> /usr/include/x86_64-linux-gnu/bits/stdint-intn.h:27:19: note: previous
> declaration of ‘int64_t’ with type ‘int64_t’ {aka ‘long int’}
>     27 | typedef __int64_t int64_t;
>        |                   ^~~~~~~
> In file included from dma_map_benchmark.c:13:
> ../../include/linux/types.h:137:13: error: conflicting types for
> ‘blkcnt_t’; have ‘u64’ {aka ‘long long unsigned int’}
>    137 | typedef u64 blkcnt_t;
>        |             ^~~~~~~~
> In file included from /usr/include/stdlib.h:395,
>                   from dma_map_benchmark.c:8:
> /usr/include/x86_64-linux-gnu/sys/types.h:192:20: note: previous
> declaration of ‘blkcnt_t’ with type ‘blkcnt_t’ {aka ‘long int’}
>    192 | typedef __blkcnt_t blkcnt_t;     /* Type to count number of
> disk blocks.  */
>        |                    ^~~~~~~~
> make: *** [Makefile:11: dma_map_benchmark] Error 1
> 
> Thanks
> Barry
I'm so sorry, there were some mistake，'usr/include' should be placed
before 'include' during include :
CFLAGS += -I../../usr/include -I../../include
After the modification, it'll work.In the next version, I will submit
the two patches separately, and put the modification of the file path
in MAINTAINERS into this patch. Is there anything else that needs to be
modified?

Re: [PATCH 1/2] tools/dma: move dma_map_benchmark from selftests to tools/dma

[Barry Song]

> I'm so sorry, there were some mistake，'usr/include' should be placed
> before 'include' during include :
> CFLAGS += -I../../usr/include -I../../include
> After the modification, it'll work.In the next version, I will submit
> the two patches separately, and put the modification of the file path
> in MAINTAINERS into this patch. Is there anything else that needs to be
> modified?

i am still getting same build errors with the below:

tools/dma$ git diff .
diff --git a/tools/dma/Makefile b/tools/dma/Makefile
index 841b54896288..c37393a3e937 100644
--- a/tools/dma/Makefile
+++ b/tools/dma/Makefile
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 bindir ?= /usr/bin

-CFLAGS += -I../../include -I../../usr/include
+CFLAGS += -I../../usr/include  -I../../include

 TARGET = dma_map_benchmark


make:

cc -I../../usr/include  -I../../include dma_map_benchmark.c -o dma_map_benchmark
In file included from dma_map_benchmark.c:13:
../../include/linux/types.h:20:33: error: conflicting types for
‘fd_set’; have ‘__kernel_fd_set’
   20 | typedef __kernel_fd_set         fd_set;
      |                                 ^~~~~~
In file included from /usr/include/x86_64-linux-gnu/sys/types.h:179,
                 from /usr/include/stdlib.h:395,
                 from dma_map_benchmark.c:8:
/usr/include/x86_64-linux-gnu/sys/select.h:70:5: note: previous
declaration of ‘fd_set’ with type ‘fd_set’
   70 |   } fd_set;
      |     ^~~~~~
In file included from dma_map_benchmark.c:13:
../../include/linux/types.h:21:33: error: conflicting types for
‘dev_t’; have ‘__kernel_dev_t’ {aka ‘unsigned int’}
   21 | typedef __kernel_dev_t          dev_t;
      |                                 ^~~~~
In file included from /usr/include/stdlib.h:395,
                 from dma_map_benchmark.c:8:
/usr/include/x86_64-linux-gnu/sys/types.h:59:17: note: previous
declaration of ‘dev_t’ with type ‘dev_t’ {aka ‘long unsigned int’}
   59 | typedef __dev_t dev_t;
      |                 ^~~~~
In file included from dma_map_benchmark.c:13:
../../include/linux/types.h:25:33: error: conflicting types for
‘nlink_t’; have ‘u32’ {aka ‘unsigned int’}
   25 | typedef u32                     nlink_t;
      |                                 ^~~~~~~
In file included from /usr/include/stdlib.h:395,
                 from dma_map_benchmark.c:8:
/usr/include/x86_64-linux-gnu/sys/types.h:74:19: note: previous
declaration of ‘nlink_t’ with type ‘nlink_t’ {aka ‘long unsigned int’}
   74 | typedef __nlink_t nlink_t;
      |                   ^~~~~~~
In file included from dma_map_benchmark.c:13:
../../include/linux/types.h:31:33: error: conflicting types for
‘timer_t’; have ‘__kernel_timer_t’ {aka ‘int’}
   31 | typedef __kernel_timer_t        timer_t;
      |                                 ^~~~~~~
In file included from /usr/include/x86_64-linux-gnu/sys/types.h:130,
                 from /usr/include/stdlib.h:395,
                 from dma_map_benchmark.c:8:
/usr/include/x86_64-linux-gnu/bits/types/timer_t.h:7:19: note:
previous declaration of ‘timer_t’ with type ‘timer_t’ {aka ‘void *’}
    7 | typedef __timer_t timer_t;
      |                   ^~~~~~~
In file included from dma_map_benchmark.c:13:
../../include/linux/types.h:52:33: error: conflicting types for
‘loff_t’; have ‘__kernel_loff_t’ {aka ‘long long int’}
   52 | typedef __kernel_loff_t         loff_t;
      |                                 ^~~~~~
In file included from /usr/include/stdlib.h:395,
                 from dma_map_benchmark.c:8:
/usr/include/x86_64-linux-gnu/sys/types.h:42:18: note: previous
declaration of ‘loff_t’ with type ‘loff_t’ {aka ‘long int’}
   42 | typedef __loff_t loff_t;
      |                  ^~~~~~
In file included from dma_map_benchmark.c:13:
../../include/linux/types.h:115:33: error: conflicting types for
‘u_int64_t’; have ‘u64’ {aka ‘long long unsigned int’}
  115 | typedef u64                     u_int64_t;
      |                                 ^~~~~~~~~
In file included from /usr/include/stdlib.h:395,
                 from dma_map_benchmark.c:8:
/usr/include/x86_64-linux-gnu/sys/types.h:161:20: note: previous
declaration of ‘u_int64_t’ with type ‘u_int64_t’ {aka ‘long unsigned
int’}
  161 | typedef __uint64_t u_int64_t;
      |                    ^~~~~~~~~
In file included from dma_map_benchmark.c:13:
../../include/linux/types.h:116:33: error: conflicting types for
‘int64_t’; have ‘s64’ {aka ‘long long int’}
  116 | typedef s64                     int64_t;
      |                                 ^~~~~~~
In file included from /usr/include/x86_64-linux-gnu/sys/types.h:155,
                 from /usr/include/stdlib.h:395,
                 from dma_map_benchmark.c:8:
/usr/include/x86_64-linux-gnu/bits/stdint-intn.h:27:19: note: previous
declaration of ‘int64_t’ with type ‘int64_t’ {aka ‘long int’}
   27 | typedef __int64_t int64_t;
      |                   ^~~~~~~
In file included from dma_map_benchmark.c:13:
../../include/linux/types.h:137:13: error: conflicting types for
‘blkcnt_t’; have ‘u64’ {aka ‘long long unsigned int’}
  137 | typedef u64 blkcnt_t;
      |             ^~~~~~~~
In file included from /usr/include/stdlib.h:395,
                 from dma_map_benchmark.c:8:
/usr/include/x86_64-linux-gnu/sys/types.h:192:20: note: previous
declaration of ‘blkcnt_t’ with type ‘blkcnt_t’ {aka ‘long int’}
  192 | typedef __blkcnt_t blkcnt_t;     /* Type to count number of
disk blocks.  */
      |                    ^~~~~~~~

Thanks
Barry

Re: [PATCH 1/2] tools/dma: move dma_map_benchmark from selftests to tools/dma

[Qinxin Xia]

On 2025/8/21 11:39:14, Barry Song <21cnbao@gmail.com> wrote:
>> I'm so sorry, there were some mistake，'usr/include' should be placed
>> before 'include' during include :
>> CFLAGS += -I../../usr/include -I../../include
>> After the modification, it'll work.In the next version, I will submit
>> the two patches separately, and put the modification of the file path
>> in MAINTAINERS into this patch. Is there anything else that needs to be
>> modified?
> 
> i am still getting same build errors with the below:
> 
> tools/dma$ git diff .
> diff --git a/tools/dma/Makefile b/tools/dma/Makefile
> index 841b54896288..c37393a3e937 100644
> --- a/tools/dma/Makefile
> +++ b/tools/dma/Makefile
> @@ -1,7 +1,7 @@
>   # SPDX-License-Identifier: GPL-2.0
>   bindir ?= /usr/bin
> 
> -CFLAGS += -I../../include -I../../usr/include
> +CFLAGS += -I../../usr/include  -I../../include
> 
>   TARGET = dma_map_benchmark
> 
> 
> make:
> 
> cc -I../../usr/include  -I../../include dma_map_benchmark.c -o dma_map_benchmark
> In file included from dma_map_benchmark.c:13:
> ../../include/linux/types.h:20:33: error: conflicting types for
> ‘fd_set’; have ‘__kernel_fd_set’
>     20 | typedef __kernel_fd_set         fd_set;
>        |                                 ^~~~~~
> In file included from /usr/include/x86_64-linux-gnu/sys/types.h:179,
>                   from /usr/include/stdlib.h:395,
>                   from dma_map_benchmark.c:8:
> /usr/include/x86_64-linux-gnu/sys/select.h:70:5: note: previous
> declaration of ‘fd_set’ with type ‘fd_set’
>     70 |   } fd_set;
>        |     ^~~~~~
> In file included from dma_map_benchmark.c:13:
> ../../include/linux/types.h:21:33: error: conflicting types for
> ‘dev_t’; have ‘__kernel_dev_t’ {aka ‘unsigned int’}
>     21 | typedef __kernel_dev_t          dev_t;
>        |                                 ^~~~~
> In file included from /usr/include/stdlib.h:395,
>                   from dma_map_benchmark.c:8:
> /usr/include/x86_64-linux-gnu/sys/types.h:59:17: note: previous
> declaration of ‘dev_t’ with type ‘dev_t’ {aka ‘long unsigned int’}
>     59 | typedef __dev_t dev_t;
>        |                 ^~~~~
> In file included from dma_map_benchmark.c:13:
> ../../include/linux/types.h:25:33: error: conflicting types for
> ‘nlink_t’; have ‘u32’ {aka ‘unsigned int’}
>     25 | typedef u32                     nlink_t;
>        |                                 ^~~~~~~
> In file included from /usr/include/stdlib.h:395,
>                   from dma_map_benchmark.c:8:
> /usr/include/x86_64-linux-gnu/sys/types.h:74:19: note: previous
> declaration of ‘nlink_t’ with type ‘nlink_t’ {aka ‘long unsigned int’}
>     74 | typedef __nlink_t nlink_t;
>        |                   ^~~~~~~
> In file included from dma_map_benchmark.c:13:
> ../../include/linux/types.h:31:33: error: conflicting types for
> ‘timer_t’; have ‘__kernel_timer_t’ {aka ‘int’}
>     31 | typedef __kernel_timer_t        timer_t;
>        |                                 ^~~~~~~
> In file included from /usr/include/x86_64-linux-gnu/sys/types.h:130,
>                   from /usr/include/stdlib.h:395,
>                   from dma_map_benchmark.c:8:
> /usr/include/x86_64-linux-gnu/bits/types/timer_t.h:7:19: note:
> previous declaration of ‘timer_t’ with type ‘timer_t’ {aka ‘void *’}
>      7 | typedef __timer_t timer_t;
>        |                   ^~~~~~~
> In file included from dma_map_benchmark.c:13:
> ../../include/linux/types.h:52:33: error: conflicting types for
> ‘loff_t’; have ‘__kernel_loff_t’ {aka ‘long long int’}
>     52 | typedef __kernel_loff_t         loff_t;
>        |                                 ^~~~~~
> In file included from /usr/include/stdlib.h:395,
>                   from dma_map_benchmark.c:8:
> /usr/include/x86_64-linux-gnu/sys/types.h:42:18: note: previous
> declaration of ‘loff_t’ with type ‘loff_t’ {aka ‘long int’}
>     42 | typedef __loff_t loff_t;
>        |                  ^~~~~~
> In file included from dma_map_benchmark.c:13:
> ../../include/linux/types.h:115:33: error: conflicting types for
> ‘u_int64_t’; have ‘u64’ {aka ‘long long unsigned int’}
>    115 | typedef u64                     u_int64_t;
>        |                                 ^~~~~~~~~
> In file included from /usr/include/stdlib.h:395,
>                   from dma_map_benchmark.c:8:
> /usr/include/x86_64-linux-gnu/sys/types.h:161:20: note: previous
> declaration of ‘u_int64_t’ with type ‘u_int64_t’ {aka ‘long unsigned
> int’}
>    161 | typedef __uint64_t u_int64_t;
>        |                    ^~~~~~~~~
> In file included from dma_map_benchmark.c:13:
> ../../include/linux/types.h:116:33: error: conflicting types for
> ‘int64_t’; have ‘s64’ {aka ‘long long int’}
>    116 | typedef s64                     int64_t;
>        |                                 ^~~~~~~
> In file included from /usr/include/x86_64-linux-gnu/sys/types.h:155,
>                   from /usr/include/stdlib.h:395,
>                   from dma_map_benchmark.c:8:
> /usr/include/x86_64-linux-gnu/bits/stdint-intn.h:27:19: note: previous
> declaration of ‘int64_t’ with type ‘int64_t’ {aka ‘long int’}
>     27 | typedef __int64_t int64_t;
>        |                   ^~~~~~~
> In file included from dma_map_benchmark.c:13:
> ../../include/linux/types.h:137:13: error: conflicting types for
> ‘blkcnt_t’; have ‘u64’ {aka ‘long long unsigned int’}
>    137 | typedef u64 blkcnt_t;
>        |             ^~~~~~~~
> In file included from /usr/include/stdlib.h:395,
>                   from dma_map_benchmark.c:8:
> /usr/include/x86_64-linux-gnu/sys/types.h:192:20: note: previous
> declaration of ‘blkcnt_t’ with type ‘blkcnt_t’ {aka ‘long int’}
>    192 | typedef __blkcnt_t blkcnt_t;     /* Type to count number of
> disk blocks.  */
>        |                    ^~~~~~~~
> 
> Thanks
> Barry

Does usr/include have header files? Did you run make headers_install 
before make?
[xiaqinxin@localhost linux]$ make headers_install
   HOSTCC  scripts/basic/fixdep
   HOSTCC  scripts/unifdef
   WRAP    arch/arm64/include/generated/uapi/asm/socket.h
   SYSHDR  arch/arm64/include/generated/uapi/asm/unistd_64.h
   HDRINST usr/include/asm-generic/mman.h
   HDRINST usr/include/asm-generic/stat.h
   HDRINST usr/include/asm-generic/ucontext.h
   HDRINST usr/include/asm-generic/int-ll64.h
   HDRINST usr/include/asm-generic/unistd.h
   HDRINST usr/include/asm-generic/kvm_para.h
   HDRINST usr/include/asm-generic/types.h
   HDRINST usr/include/asm-generic/ipcbuf.h
   HDRINST usr/include/asm-generic/termbits-common.h
...
[xiaqinxin@localhost linux]$ cd tools/dma/
[xiaqinxin@localhost dma]$ make
cc -I../../usr/include -I../../include dma_map_benchmark.c -o 
dma_map_benchmark

My test is ok.

Re: [PATCH 1/2] tools/dma: move dma_map_benchmark from selftests to tools/dma

[Barry Song]

>
> Does usr/include have header files? Did you run make headers_install
> before make?
> [xiaqinxin@localhost linux]$ make headers_install
>    HOSTCC  scripts/basic/fixdep
>    HOSTCC  scripts/unifdef
>    WRAP    arch/arm64/include/generated/uapi/asm/socket.h
>    SYSHDR  arch/arm64/include/generated/uapi/asm/unistd_64.h
>    HDRINST usr/include/asm-generic/mman.h
>    HDRINST usr/include/asm-generic/stat.h
>    HDRINST usr/include/asm-generic/ucontext.h
>    HDRINST usr/include/asm-generic/int-ll64.h
>    HDRINST usr/include/asm-generic/unistd.h
>    HDRINST usr/include/asm-generic/kvm_para.h
>    HDRINST usr/include/asm-generic/types.h
>    HDRINST usr/include/asm-generic/ipcbuf.h
>    HDRINST usr/include/asm-generic/termbits-common.h
> ...
> [xiaqinxin@localhost linux]$ cd tools/dma/
> [xiaqinxin@localhost dma]$ make
> cc -I../../usr/include -I../../include dma_map_benchmark.c -o
> dma_map_benchmark

This is really frustrating. Why do other parts not need this, but
dma_map_benchmark does? It is also not acceptable to hardcode the
path to usr/include.

It is also not good practice to access a kernel header directly from a
userspace tool - such as -I../../include.

Shouldn't map_benchmark.h be a proper UAPI header that gets installed
into the toolchain like the others?

>
> My test is ok.


Thanks
Barry

Re: [PATCH 1/2] tools/dma: move dma_map_benchmark from selftests to tools/dma

[Qinxin Xia]

On 2025/8/22 09:12:07, Barry Song <21cnbao@gmail.com> wrote:
>>
>> Does usr/include have header files? Did you run make headers_install
>> before make?
>> [xiaqinxin@localhost linux]$ make headers_install
>>     HOSTCC  scripts/basic/fixdep
>>     HOSTCC  scripts/unifdef
>>     WRAP    arch/arm64/include/generated/uapi/asm/socket.h
>>     SYSHDR  arch/arm64/include/generated/uapi/asm/unistd_64.h
>>     HDRINST usr/include/asm-generic/mman.h
>>     HDRINST usr/include/asm-generic/stat.h
>>     HDRINST usr/include/asm-generic/ucontext.h
>>     HDRINST usr/include/asm-generic/int-ll64.h
>>     HDRINST usr/include/asm-generic/unistd.h
>>     HDRINST usr/include/asm-generic/kvm_para.h
>>     HDRINST usr/include/asm-generic/types.h
>>     HDRINST usr/include/asm-generic/ipcbuf.h
>>     HDRINST usr/include/asm-generic/termbits-common.h
>> ...
>> [xiaqinxin@localhost linux]$ cd tools/dma/
>> [xiaqinxin@localhost dma]$ make
>> cc -I../../usr/include -I../../include dma_map_benchmark.c -o
>> dma_map_benchmark
> 
> This is really frustrating. Why do other parts not need this, but
> dma_map_benchmark does? It is also not acceptable to hardcode the
> path to usr/include.
> 
> It is also not good practice to access a kernel header directly from a
> userspace tool - such as -I../../include.
> 
> Shouldn't map_benchmark.h be a proper UAPI header that gets installed
> into the toolchain like the others?
> 
Hello Barry :

This include file is inherited from the original version, and there are 
similar

method in other parts ：

pcmcia/Makefile:CFLAGS := -I../../usr/include
laptop/dslm/Makefile:CFLAGS := -I../../usr/include
accounting/Makefile:CFLAGS := -I../../usr/include

During compilation, the system searches for header files from 
../../usr/include first.

If no header file is found in ../../usr/include, the system attempts to 
get header files

from the system directory of the compilation environment. So maybe in 
some compilation

environments, compiling these modules might have the same problem...

'struct map_benchmark' is defined in map_benchmark.h which is used by 
map_benchmark.c

Do we need to define them separately in the kernel and uapi header files?>>
>> My test is ok.
> 
> 
> Thanks
> Barry

Re: [PATCH 1/2] tools/dma: move dma_map_benchmark from selftests to tools/dma

[Barry Song]

On Thu, Aug 28, 2025 at 12:07 AM Qinxin Xia <xiaqinxin@huawei.com> wrote:
>
>
>
> On 2025/8/22 09:12:07, Barry Song <21cnbao@gmail.com> wrote:
> >>
> >> Does usr/include have header files? Did you run make headers_install
> >> before make?
> >> [xiaqinxin@localhost linux]$ make headers_install
> >>     HOSTCC  scripts/basic/fixdep
> >>     HOSTCC  scripts/unifdef
> >>     WRAP    arch/arm64/include/generated/uapi/asm/socket.h
> >>     SYSHDR  arch/arm64/include/generated/uapi/asm/unistd_64.h
> >>     HDRINST usr/include/asm-generic/mman.h
> >>     HDRINST usr/include/asm-generic/stat.h
> >>     HDRINST usr/include/asm-generic/ucontext.h
> >>     HDRINST usr/include/asm-generic/int-ll64.h
> >>     HDRINST usr/include/asm-generic/unistd.h
> >>     HDRINST usr/include/asm-generic/kvm_para.h
> >>     HDRINST usr/include/asm-generic/types.h
> >>     HDRINST usr/include/asm-generic/ipcbuf.h
> >>     HDRINST usr/include/asm-generic/termbits-common.h
> >> ...
> >> [xiaqinxin@localhost linux]$ cd tools/dma/
> >> [xiaqinxin@localhost dma]$ make
> >> cc -I../../usr/include -I../../include dma_map_benchmark.c -o
> >> dma_map_benchmark
> >
> > This is really frustrating. Why do other parts not need this, but
> > dma_map_benchmark does? It is also not acceptable to hardcode the
> > path to usr/include.
> >
> > It is also not good practice to access a kernel header directly from a
> > userspace tool - such as -I../../include.
> >
> > Shouldn't map_benchmark.h be a proper UAPI header that gets installed
> > into the toolchain like the others?
> >
> Hello Barry :
>
> This include file is inherited from the original version, and there are
> similar
>
> method in other parts ：
>
> pcmcia/Makefile:CFLAGS := -I../../usr/include
> laptop/dslm/Makefile:CFLAGS := -I../../usr/include
> accounting/Makefile:CFLAGS := -I../../usr/include
>
> During compilation, the system searches for header files from
> ../../usr/include first.
>
> If no header file is found in ../../usr/include, the system attempts to
> get header files

The difference is that, for them, the build still passes even without
running `header_install` (and thus without `../../usr/include`).

tools/laptop/dslm$ make
gcc -I../../usr/include    dslm.c   -o dslm

tools/pcmcia$ make
gcc -I../../usr/include    crc32hash.c   -o crc32hash

For tools/accounting, the build fails mainly because the UAPI header
files in the toolchain may be older than those in the latest kernel. so
we need make headers_install to update.

But I don’t really understand why we need it. My guess is that the
"-I../../include" option overrides the system header files, which then
causes type conflicts.

cc -I../../include dma_map_benchmark.c -o dma_map_benchmark
In file included from dma_map_benchmark.c:13:
../../include/linux/types.h:20:33: error: conflicting types for
‘fd_set’; have ‘__kernel_fd_set’
   20 | typedef __kernel_fd_set         fd_set;
      |                                 ^~~~~~
In file included from /usr/include/x86_64-linux-gnu/sys/types.h:179,
                 from /usr/include/stdlib.h:395,
                 from dma_map_benchmark.c:8:
/usr/include/x86_64-linux-gnu/sys/select.h:70:5: note: previous
declaration of ‘fd_set’ with type ‘fd_set’
   70 |   } fd_set;
      |     ^~~~~~
In file included from dma_map_benchmark.c:13:
../../include/linux/types.h:21:33: error: conflicting types for
‘dev_t’; have ‘__kernel_dev_t’ {aka ‘unsigned int’}
   21 | typedef __kernel_dev_t          dev_t;
      |                                 ^~~~~

You should be referring to the system types.h, but the -I../../include
option makes you pick up the wrong kernel types.h. However, when you
do have "../../usr/include", you end up with the correct types.h from UAPI.

I really dislike all this *mess*. You can fix it by doing the following:

diff --git a/tools/dma/Makefile b/tools/dma/Makefile
index 841b54896288..cec09abf47cd 100644
--- a/tools/dma/Makefile
+++ b/tools/dma/Makefile
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 bindir ?= /usr/bin

-CFLAGS += -I../../include -I../../usr/include
+CFLAGS += -idirafter ../../include

>
> from the system directory of the compilation environment. So maybe in
> some compilation
>
> environments, compiling these modules might have the same problem...
>
> 'struct map_benchmark' is defined in map_benchmark.h which is used by
> map_benchmark.c
>
> Do we need to define them separately in the kernel and uapi header files?>>

Ideally, yes—then the -I../../include option would no longer be necessary.

Thanks
Barry

Re: [PATCH 1/2] tools/dma: move dma_map_benchmark from selftests to tools/dma

[Qinxin Xia]

On 2025/8/29 05:22:21, Barry Song <21cnbao@gmail.com> wrote:
> On Thu, Aug 28, 2025 at 12:07 AM Qinxin Xia <xiaqinxin@huawei.com> wrote:
>>
>>
>>
>> On 2025/8/22 09:12:07, Barry Song <21cnbao@gmail.com> wrote:
>>>>
>>>> Does usr/include have header files? Did you run make headers_install
>>>> before make?
>>>> [xiaqinxin@localhost linux]$ make headers_install
>>>>      HOSTCC  scripts/basic/fixdep
>>>>      HOSTCC  scripts/unifdef
>>>>      WRAP    arch/arm64/include/generated/uapi/asm/socket.h
>>>>      SYSHDR  arch/arm64/include/generated/uapi/asm/unistd_64.h
>>>>      HDRINST usr/include/asm-generic/mman.h
>>>>      HDRINST usr/include/asm-generic/stat.h
>>>>      HDRINST usr/include/asm-generic/ucontext.h
>>>>      HDRINST usr/include/asm-generic/int-ll64.h
>>>>      HDRINST usr/include/asm-generic/unistd.h
>>>>      HDRINST usr/include/asm-generic/kvm_para.h
>>>>      HDRINST usr/include/asm-generic/types.h
>>>>      HDRINST usr/include/asm-generic/ipcbuf.h
>>>>      HDRINST usr/include/asm-generic/termbits-common.h
>>>> ...
>>>> [xiaqinxin@localhost linux]$ cd tools/dma/
>>>> [xiaqinxin@localhost dma]$ make
>>>> cc -I../../usr/include -I../../include dma_map_benchmark.c -o
>>>> dma_map_benchmark
>>>
>>> This is really frustrating. Why do other parts not need this, but
>>> dma_map_benchmark does? It is also not acceptable to hardcode the
>>> path to usr/include.
>>>
>>> It is also not good practice to access a kernel header directly from a
>>> userspace tool - such as -I../../include.
>>>
>>> Shouldn't map_benchmark.h be a proper UAPI header that gets installed
>>> into the toolchain like the others?
>>>
>> Hello Barry :
>>
>> This include file is inherited from the original version, and there are
>> similar
>>
>> method in other parts ：
>>
>> pcmcia/Makefile:CFLAGS := -I../../usr/include
>> laptop/dslm/Makefile:CFLAGS := -I../../usr/include
>> accounting/Makefile:CFLAGS := -I../../usr/include
>>
>> During compilation, the system searches for header files from
>> ../../usr/include first.
>>
>> If no header file is found in ../../usr/include, the system attempts to
>> get header files
> 
> The difference is that, for them, the build still passes even without
> running `header_install` (and thus without `../../usr/include`).
> 
> tools/laptop/dslm$ make
> gcc -I../../usr/include    dslm.c   -o dslm
> 
> tools/pcmcia$ make
> gcc -I../../usr/include    crc32hash.c   -o crc32hash
> 
> For tools/accounting, the build fails mainly because the UAPI header
> files in the toolchain may be older than those in the latest kernel. so
> we need make headers_install to update.
> 
> But I don’t really understand why we need it. My guess is that the
> "-I../../include" option overrides the system header files, which then
> causes type conflicts.
> 
> cc -I../../include dma_map_benchmark.c -o dma_map_benchmark
> In file included from dma_map_benchmark.c:13:
> ../../include/linux/types.h:20:33: error: conflicting types for
> ‘fd_set’; have ‘__kernel_fd_set’
>     20 | typedef __kernel_fd_set         fd_set;
>        |                                 ^~~~~~
> In file included from /usr/include/x86_64-linux-gnu/sys/types.h:179,
>                   from /usr/include/stdlib.h:395,
>                   from dma_map_benchmark.c:8:
> /usr/include/x86_64-linux-gnu/sys/select.h:70:5: note: previous
> declaration of ‘fd_set’ with type ‘fd_set’
>     70 |   } fd_set;
>        |     ^~~~~~
> In file included from dma_map_benchmark.c:13:
> ../../include/linux/types.h:21:33: error: conflicting types for
> ‘dev_t’; have ‘__kernel_dev_t’ {aka ‘unsigned int’}
>     21 | typedef __kernel_dev_t          dev_t;
>        |                                 ^~~~~
> 
> You should be referring to the system types.h, but the -I../../include
> option makes you pick up the wrong kernel types.h. However, when you
> do have "../../usr/include", you end up with the correct types.h from UAPI.
> 
> I really dislike all this *mess*. You can fix it by doing the following:
> 
> diff --git a/tools/dma/Makefile b/tools/dma/Makefile
> index 841b54896288..cec09abf47cd 100644
> --- a/tools/dma/Makefile
> +++ b/tools/dma/Makefile
> @@ -1,7 +1,7 @@
>   # SPDX-License-Identifier: GPL-2.0
>   bindir ?= /usr/bin
> 
> -CFLAGS += -I../../include -I../../usr/include
> +CFLAGS += -idirafter ../../include
> 
Hello, Barry:

Let me see... 'make headers_install' installs the UAPI header files to 
the usr/include directory in the kernel source tree by default, rather 
than directly to the system's /usr/include directory.

This means that when 'map_benchmark.h' is moved to uapi/include, 
compilation tool chain cannot get the header file from the system path. 
Users need to install the UAPI header file to the system directory or 
set environment variables to reference it from the environment variables.

Could this get a little complex?  Should we keep ' -I ../../usr/include 
' ?>>
>> from the system directory of the compilation environment. So maybe in
>> some compilation
>>
>> environments, compiling these modules might have the same problem...
>>
>> 'struct map_benchmark' is defined in map_benchmark.h which is used by
>> map_benchmark.c
>>
>> Do we need to define them separately in the kernel and uapi header files?>>
> 
> Ideally, yes—then the -I../../include option would no longer be necessary.
> 
> Thanks
> Barry

Re: [PATCH 1/2] tools/dma: move dma_map_benchmark from selftests to tools/dma

[Barry Song]

On Tue, Sep 2, 2025 at 12:08 PM Qinxin Xia <xiaqinxin@huawei.com> wrote:
>
>
>
> On 2025/8/29 05:22:21, Barry Song <21cnbao@gmail.com> wrote:
> > On Thu, Aug 28, 2025 at 12:07 AM Qinxin Xia <xiaqinxin@huawei.com> wrote:
> >>
> >>
> >>
> >> On 2025/8/22 09:12:07, Barry Song <21cnbao@gmail.com> wrote:
> >>>>
> >>>> Does usr/include have header files? Did you run make headers_install
> >>>> before make?
> >>>> [xiaqinxin@localhost linux]$ make headers_install
> >>>>      HOSTCC  scripts/basic/fixdep
> >>>>      HOSTCC  scripts/unifdef
> >>>>      WRAP    arch/arm64/include/generated/uapi/asm/socket.h
> >>>>      SYSHDR  arch/arm64/include/generated/uapi/asm/unistd_64.h
> >>>>      HDRINST usr/include/asm-generic/mman.h
> >>>>      HDRINST usr/include/asm-generic/stat.h
> >>>>      HDRINST usr/include/asm-generic/ucontext.h
> >>>>      HDRINST usr/include/asm-generic/int-ll64.h
> >>>>      HDRINST usr/include/asm-generic/unistd.h
> >>>>      HDRINST usr/include/asm-generic/kvm_para.h
> >>>>      HDRINST usr/include/asm-generic/types.h
> >>>>      HDRINST usr/include/asm-generic/ipcbuf.h
> >>>>      HDRINST usr/include/asm-generic/termbits-common.h
> >>>> ...
> >>>> [xiaqinxin@localhost linux]$ cd tools/dma/
> >>>> [xiaqinxin@localhost dma]$ make
> >>>> cc -I../../usr/include -I../../include dma_map_benchmark.c -o
> >>>> dma_map_benchmark
> >>>
> >>> This is really frustrating. Why do other parts not need this, but
> >>> dma_map_benchmark does? It is also not acceptable to hardcode the
> >>> path to usr/include.
> >>>
> >>> It is also not good practice to access a kernel header directly from a
> >>> userspace tool - such as -I../../include.
> >>>
> >>> Shouldn't map_benchmark.h be a proper UAPI header that gets installed
> >>> into the toolchain like the others?
> >>>
> >> Hello Barry :
> >>
> >> This include file is inherited from the original version, and there are
> >> similar
> >>
> >> method in other parts ：
> >>
> >> pcmcia/Makefile:CFLAGS := -I../../usr/include
> >> laptop/dslm/Makefile:CFLAGS := -I../../usr/include
> >> accounting/Makefile:CFLAGS := -I../../usr/include
> >>
> >> During compilation, the system searches for header files from
> >> ../../usr/include first.
> >>
> >> If no header file is found in ../../usr/include, the system attempts to
> >> get header files
> >
> > The difference is that, for them, the build still passes even without
> > running `header_install` (and thus without `../../usr/include`).
> >
> > tools/laptop/dslm$ make
> > gcc -I../../usr/include    dslm.c   -o dslm
> >
> > tools/pcmcia$ make
> > gcc -I../../usr/include    crc32hash.c   -o crc32hash
> >
> > For tools/accounting, the build fails mainly because the UAPI header
> > files in the toolchain may be older than those in the latest kernel. so
> > we need make headers_install to update.
> >
> > But I don’t really understand why we need it. My guess is that the
> > "-I../../include" option overrides the system header files, which then
> > causes type conflicts.
> >
> > cc -I../../include dma_map_benchmark.c -o dma_map_benchmark
> > In file included from dma_map_benchmark.c:13:
> > ../../include/linux/types.h:20:33: error: conflicting types for
> > ‘fd_set’; have ‘__kernel_fd_set’
> >     20 | typedef __kernel_fd_set         fd_set;
> >        |                                 ^~~~~~
> > In file included from /usr/include/x86_64-linux-gnu/sys/types.h:179,
> >                   from /usr/include/stdlib.h:395,
> >                   from dma_map_benchmark.c:8:
> > /usr/include/x86_64-linux-gnu/sys/select.h:70:5: note: previous
> > declaration of ‘fd_set’ with type ‘fd_set’
> >     70 |   } fd_set;
> >        |     ^~~~~~
> > In file included from dma_map_benchmark.c:13:
> > ../../include/linux/types.h:21:33: error: conflicting types for
> > ‘dev_t’; have ‘__kernel_dev_t’ {aka ‘unsigned int’}
> >     21 | typedef __kernel_dev_t          dev_t;
> >        |                                 ^~~~~
> >
> > You should be referring to the system types.h, but the -I../../include
> > option makes you pick up the wrong kernel types.h. However, when you
> > do have "../../usr/include", you end up with the correct types.h from UAPI.
> >
> > I really dislike all this *mess*. You can fix it by doing the following:
> >
> > diff --git a/tools/dma/Makefile b/tools/dma/Makefile
> > index 841b54896288..cec09abf47cd 100644
> > --- a/tools/dma/Makefile
> > +++ b/tools/dma/Makefile
> > @@ -1,7 +1,7 @@
> >   # SPDX-License-Identifier: GPL-2.0
> >   bindir ?= /usr/bin
> >
> > -CFLAGS += -I../../include -I../../usr/include
> > +CFLAGS += -idirafter ../../include
> >
> Hello, Barry:
>
> Let me see... 'make headers_install' installs the UAPI header files to
> the usr/include directory in the kernel source tree by default, rather
> than directly to the system's /usr/include directory.
>
> This means that when 'map_benchmark.h' is moved to uapi/include,
> compilation tool chain cannot get the header file from the system path.
> Users need to install the UAPI header file to the system directory or
> set environment variables to reference it from the environment variables.
>
> Could this get a little complex?  Should we keep ' -I ../../usr/include
> ' ?>>
> >> from the system directory of the compilation environment. So maybe in
> >> some compilation
> >>
> >> environments, compiling these modules might have the same problem...

This is also true for any Linux application if the toolchain’s UAPI
headers lag behind the kernel version.

> >>
> >> 'struct map_benchmark' is defined in map_benchmark.h which is used by
> >> map_benchmark.c
> >>
> >> Do we need to define them separately in the kernel and uapi header files?>>

No, just move it to UAPI. When the Linux distribution is upgraded,
GCC will include this header automatically, like any other UAPI header.

If you don't move it to UAPI, please remove  -I ../../usr/include.

> >
> > Ideally, yes—then the -I../../include option would no longer be necessary.
> >

Thanks
Barry