* [PATCH 0/2] dma-mapping: benchmark: modify the dma_map_benchmark directory
@ 2025-07-24 8:55 Qinxin Xia
2025-07-24 8:55 ` [PATCH 1/2] tools/dma: move dma_map_benchmark from selftests to tools/dma Qinxin Xia
2025-07-24 8:56 ` [PATCH 2/2] dma-mapping: benchmark: Add padding to ensure uABI remained consistent Qinxin Xia
0 siblings, 2 replies; 22+ messages in thread
From: Qinxin Xia @ 2025-07-24 8:55 UTC (permalink / raw)
To: 21cnbao, m.szyprowski, robin.murphy, jonathan.cameron
Cc: prime.zeng, fanghao11, linux-kernel, linuxarm, xiaqinxin
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
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH 1/2] tools/dma: move dma_map_benchmark from selftests to tools/dma 2025-07-24 8:55 [PATCH 0/2] dma-mapping: benchmark: modify the dma_map_benchmark directory Qinxin Xia @ 2025-07-24 8:55 ` Qinxin Xia 2025-07-24 9:25 ` Barry Song 2025-07-24 8:56 ` [PATCH 2/2] dma-mapping: benchmark: Add padding to ensure uABI remained consistent Qinxin Xia 1 sibling, 1 reply; 22+ messages in thread From: Qinxin Xia @ 2025-07-24 8:55 UTC (permalink / raw) To: 21cnbao, m.szyprowski, robin.murphy, jonathan.cameron Cc: prime.zeng, fanghao11, linux-kernel, linuxarm, xiaqinxin 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 ^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] tools/dma: move dma_map_benchmark from selftests to tools/dma 2025-07-24 8:55 ` [PATCH 1/2] tools/dma: move dma_map_benchmark from selftests to tools/dma Qinxin Xia @ 2025-07-24 9:25 ` Barry Song 2025-07-24 9:33 ` Qinxin Xia 0 siblings, 1 reply; 22+ messages in thread From: Barry Song @ 2025-07-24 9:25 UTC (permalink / raw) To: Qinxin Xia Cc: m.szyprowski, robin.murphy, jonathan.cameron, prime.zeng, fanghao11, linux-kernel, linuxarm 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] tools/dma: move dma_map_benchmark from selftests to tools/dma 2025-07-24 9:25 ` Barry Song @ 2025-07-24 9:33 ` Qinxin Xia 0 siblings, 0 replies; 22+ messages in thread From: Qinxin Xia @ 2025-07-24 9:33 UTC (permalink / raw) To: Barry Song Cc: m.szyprowski, robin.murphy, jonathan.cameron, prime.zeng, fanghao11, linux-kernel, linuxarm 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 2/2] dma-mapping: benchmark: Add padding to ensure uABI remained consistent 2025-07-24 8:55 [PATCH 0/2] dma-mapping: benchmark: modify the dma_map_benchmark directory Qinxin Xia 2025-07-24 8:55 ` [PATCH 1/2] tools/dma: move dma_map_benchmark from selftests to tools/dma Qinxin Xia @ 2025-07-24 8:56 ` Qinxin Xia 2025-07-24 9:07 ` Barry Song 1 sibling, 1 reply; 22+ messages in thread From: Qinxin Xia @ 2025-07-24 8:56 UTC (permalink / raw) To: 21cnbao, m.szyprowski, robin.murphy, jonathan.cameron Cc: prime.zeng, fanghao11, linux-kernel, linuxarm, xiaqinxin 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 ^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2] dma-mapping: benchmark: Add padding to ensure uABI remained consistent 2025-07-24 8:56 ` [PATCH 2/2] dma-mapping: benchmark: Add padding to ensure uABI remained consistent Qinxin Xia @ 2025-07-24 9:07 ` Barry Song 2025-07-24 9:35 ` Qinxin Xia 0 siblings, 1 reply; 22+ messages in thread From: Barry Song @ 2025-07-24 9:07 UTC (permalink / raw) To: Qinxin Xia, m.szyprowski Cc: robin.murphy, jonathan.cameron, prime.zeng, fanghao11, linux-kernel, linuxarm, iommu 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2] dma-mapping: benchmark: Add padding to ensure uABI remained consistent 2025-07-24 9:07 ` Barry Song @ 2025-07-24 9:35 ` Qinxin Xia 2025-07-24 9:42 ` Barry Song 0 siblings, 1 reply; 22+ messages in thread From: Qinxin Xia @ 2025-07-24 9:35 UTC (permalink / raw) To: Barry Song, m.szyprowski Cc: robin.murphy, jonathan.cameron, prime.zeng, fanghao11, linux-kernel, linuxarm, iommu 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2] dma-mapping: benchmark: Add padding to ensure uABI remained consistent 2025-07-24 9:35 ` Qinxin Xia @ 2025-07-24 9:42 ` Barry Song 2025-07-29 12:32 ` Marek Szyprowski 0 siblings, 1 reply; 22+ messages in thread From: Barry Song @ 2025-07-24 9:42 UTC (permalink / raw) To: Qinxin Xia Cc: m.szyprowski, robin.murphy, jonathan.cameron, prime.zeng, fanghao11, linux-kernel, linuxarm, iommu 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2] dma-mapping: benchmark: Add padding to ensure uABI remained consistent 2025-07-24 9:42 ` Barry Song @ 2025-07-29 12:32 ` Marek Szyprowski 2025-08-04 4:47 ` Barry Song 0 siblings, 1 reply; 22+ messages in thread From: Marek Szyprowski @ 2025-07-29 12:32 UTC (permalink / raw) To: Barry Song, Qinxin Xia Cc: robin.murphy, jonathan.cameron, prime.zeng, fanghao11, linux-kernel, linuxarm, iommu 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2] dma-mapping: benchmark: Add padding to ensure uABI remained consistent 2025-07-29 12:32 ` Marek Szyprowski @ 2025-08-04 4:47 ` Barry Song 2025-08-04 8:12 ` Yicong Yang 0 siblings, 1 reply; 22+ messages in thread From: Barry Song @ 2025-08-04 4:47 UTC (permalink / raw) To: Marek Szyprowski Cc: Qinxin Xia, robin.murphy, jonathan.cameron, prime.zeng, fanghao11, linux-kernel, linuxarm, iommu 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2] dma-mapping: benchmark: Add padding to ensure uABI remained consistent 2025-08-04 4:47 ` Barry Song @ 2025-08-04 8:12 ` Yicong Yang 2025-08-04 21:57 ` Barry Song 0 siblings, 1 reply; 22+ messages in thread From: Yicong Yang @ 2025-08-04 8:12 UTC (permalink / raw) To: Barry Song, Marek Szyprowski, Qinxin Xia Cc: robin.murphy, jonathan.cameron, prime.zeng, fanghao11, linux-kernel, iommu, yangyicong 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2] dma-mapping: benchmark: Add padding to ensure uABI remained consistent 2025-08-04 8:12 ` Yicong Yang @ 2025-08-04 21:57 ` Barry Song 0 siblings, 0 replies; 22+ messages in thread From: Barry Song @ 2025-08-04 21:57 UTC (permalink / raw) To: Yicong Yang Cc: Marek Szyprowski, Qinxin Xia, robin.murphy, jonathan.cameron, prime.zeng, fanghao11, linux-kernel, iommu, yangyicong 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 0/2] move dma_map_benchmark from selftests to tools/dma
@ 2025-08-14 13:35 Qinxin Xia
2025-08-14 13:35 ` [PATCH 1/2] tools/dma: " Qinxin Xia
0 siblings, 1 reply; 22+ messages in thread
From: Qinxin Xia @ 2025-08-14 13:35 UTC (permalink / raw)
To: 21cnbao, m.szyprowski, robin.murphy, jonathan.cameron
Cc: prime.zeng, fanghao11, linux-kernel, linuxarm, xiaqinxin,
yangyicong
Move dma_map_benchmark from selftest/dma to tools/dma directory
and update the maintainer list.
Qinxin Xia (2):
tools/dma: move dma_map_benchmark from selftests to tools/dma
MAINTAINERS: add myself and Barry to dma_map_benchmark maintainers
MAINTAINERS | 5 +++--
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 -------
6 files changed, 27 insertions(+), 15 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
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH 1/2] tools/dma: move dma_map_benchmark from selftests to tools/dma 2025-08-14 13:35 [PATCH 0/2] move dma_map_benchmark from selftests to tools/dma Qinxin Xia @ 2025-08-14 13:35 ` Qinxin Xia 2025-08-15 10:03 ` Barry Song 0 siblings, 1 reply; 22+ messages in thread From: Qinxin Xia @ 2025-08-14 13:35 UTC (permalink / raw) To: 21cnbao, m.szyprowski, robin.murphy, jonathan.cameron Cc: prime.zeng, fanghao11, linux-kernel, linuxarm, xiaqinxin, yangyicong 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 ^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] tools/dma: move dma_map_benchmark from selftests to tools/dma 2025-08-14 13:35 ` [PATCH 1/2] tools/dma: " Qinxin Xia @ 2025-08-15 10:03 ` Barry Song 2025-08-18 2:53 ` Qinxin Xia 0 siblings, 1 reply; 22+ messages in thread From: Barry Song @ 2025-08-15 10:03 UTC (permalink / raw) To: Qinxin Xia Cc: m.szyprowski, robin.murphy, jonathan.cameron, prime.zeng, fanghao11, linux-kernel, linuxarm, yangyicong 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] tools/dma: move dma_map_benchmark from selftests to tools/dma 2025-08-15 10:03 ` Barry Song @ 2025-08-18 2:53 ` Qinxin Xia 2025-08-21 3:39 ` Barry Song 0 siblings, 1 reply; 22+ messages in thread From: Qinxin Xia @ 2025-08-18 2:53 UTC (permalink / raw) To: Barry Song Cc: m.szyprowski, robin.murphy, jonathan.cameron, prime.zeng, fanghao11, linux-kernel, linuxarm, yangyicong 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? ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] tools/dma: move dma_map_benchmark from selftests to tools/dma 2025-08-18 2:53 ` Qinxin Xia @ 2025-08-21 3:39 ` Barry Song 2025-08-21 3:55 ` Qinxin Xia 0 siblings, 1 reply; 22+ messages in thread From: Barry Song @ 2025-08-21 3:39 UTC (permalink / raw) To: Qinxin Xia Cc: m.szyprowski, robin.murphy, jonathan.cameron, prime.zeng, fanghao11, linux-kernel, linuxarm, yangyicong > 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 ^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] tools/dma: move dma_map_benchmark from selftests to tools/dma 2025-08-21 3:39 ` Barry Song @ 2025-08-21 3:55 ` Qinxin Xia 2025-08-22 1:12 ` Barry Song 0 siblings, 1 reply; 22+ messages in thread From: Qinxin Xia @ 2025-08-21 3:55 UTC (permalink / raw) To: Barry Song Cc: m.szyprowski, robin.murphy, jonathan.cameron, prime.zeng, fanghao11, linux-kernel, linuxarm, yangyicong 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] tools/dma: move dma_map_benchmark from selftests to tools/dma 2025-08-21 3:55 ` Qinxin Xia @ 2025-08-22 1:12 ` Barry Song 2025-08-27 12:07 ` Qinxin Xia 0 siblings, 1 reply; 22+ messages in thread From: Barry Song @ 2025-08-22 1:12 UTC (permalink / raw) To: Qinxin Xia Cc: m.szyprowski, robin.murphy, jonathan.cameron, prime.zeng, fanghao11, linux-kernel, linuxarm, yangyicong > > 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] tools/dma: move dma_map_benchmark from selftests to tools/dma 2025-08-22 1:12 ` Barry Song @ 2025-08-27 12:07 ` Qinxin Xia 2025-08-28 21:22 ` Barry Song 0 siblings, 1 reply; 22+ messages in thread From: Qinxin Xia @ 2025-08-27 12:07 UTC (permalink / raw) To: Barry Song Cc: m.szyprowski, robin.murphy, jonathan.cameron, prime.zeng, fanghao11, linux-kernel, linuxarm, yangyicong 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] tools/dma: move dma_map_benchmark from selftests to tools/dma 2025-08-27 12:07 ` Qinxin Xia @ 2025-08-28 21:22 ` Barry Song 2025-09-02 4:08 ` Qinxin Xia 0 siblings, 1 reply; 22+ messages in thread From: Barry Song @ 2025-08-28 21:22 UTC (permalink / raw) To: Qinxin Xia Cc: m.szyprowski, robin.murphy, jonathan.cameron, prime.zeng, fanghao11, linux-kernel, linuxarm, yangyicong 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 ^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] tools/dma: move dma_map_benchmark from selftests to tools/dma 2025-08-28 21:22 ` Barry Song @ 2025-09-02 4:08 ` Qinxin Xia 2025-09-02 4:45 ` Barry Song 0 siblings, 1 reply; 22+ messages in thread From: Qinxin Xia @ 2025-09-02 4:08 UTC (permalink / raw) To: Barry Song Cc: m.szyprowski, robin.murphy, jonathan.cameron, prime.zeng, fanghao11, linux-kernel, linuxarm, yangyicong 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] tools/dma: move dma_map_benchmark from selftests to tools/dma 2025-09-02 4:08 ` Qinxin Xia @ 2025-09-02 4:45 ` Barry Song 0 siblings, 0 replies; 22+ messages in thread From: Barry Song @ 2025-09-02 4:45 UTC (permalink / raw) To: Qinxin Xia Cc: m.szyprowski, robin.murphy, jonathan.cameron, prime.zeng, fanghao11, linux-kernel, linuxarm, yangyicong 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2025-09-02 4:45 UTC | newest] Thread overview: 22+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-07-24 8:55 [PATCH 0/2] dma-mapping: benchmark: modify the dma_map_benchmark directory Qinxin Xia 2025-07-24 8:55 ` [PATCH 1/2] tools/dma: move dma_map_benchmark from selftests to tools/dma Qinxin Xia 2025-07-24 9:25 ` Barry Song 2025-07-24 9:33 ` Qinxin Xia 2025-07-24 8:56 ` [PATCH 2/2] dma-mapping: benchmark: Add padding to ensure uABI remained consistent Qinxin Xia 2025-07-24 9:07 ` Barry Song 2025-07-24 9:35 ` Qinxin Xia 2025-07-24 9:42 ` Barry Song 2025-07-29 12:32 ` Marek Szyprowski 2025-08-04 4:47 ` Barry Song 2025-08-04 8:12 ` Yicong Yang 2025-08-04 21:57 ` Barry Song -- strict thread matches above, loose matches on Subject: below -- 2025-08-14 13:35 [PATCH 0/2] move dma_map_benchmark from selftests to tools/dma Qinxin Xia 2025-08-14 13:35 ` [PATCH 1/2] tools/dma: " Qinxin Xia 2025-08-15 10:03 ` Barry Song 2025-08-18 2:53 ` Qinxin Xia 2025-08-21 3:39 ` Barry Song 2025-08-21 3:55 ` Qinxin Xia 2025-08-22 1:12 ` Barry Song 2025-08-27 12:07 ` Qinxin Xia 2025-08-28 21:22 ` Barry Song 2025-09-02 4:08 ` Qinxin Xia 2025-09-02 4:45 ` Barry Song
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).