On 12.12.2023 10:32, Marco Elver wrote: > On Tue, 12 Dec 2023 at 10:19, Paul Heidekrüger <paul.heidekrueger@xxxxxx> wrote: > > > > On 12.12.2023 00:37, Andrey Konovalov wrote: > > > On Tue, Dec 12, 2023 at 12:35 AM Paul Heidekrüger > > > <paul.heidekrueger@xxxxxx> wrote: > > > > > > > > Using CONFIG_FTRACE=y instead of CONFIG_TRACEPOINTS=y produces the same error > > > > for me. > > > > > > > > So > > > > > > > > CONFIG_KUNIT=y > > > > CONFIG_KUNIT_ALL_TESTS=n > > > > CONFIG_FTRACE=y > > > > CONFIG_KASAN=y > > > > CONFIG_KASAN_GENERIC=y > > > > CONFIG_KASAN_KUNIT_TEST=y > > > > > > > > produces > > > > > > > > ➜ ./tools/testing/kunit/kunit.py run --kunitconfig=mm/kasan/.kunitconfig --arch=arm64 > > > > Configuring KUnit Kernel ... > > > > Regenerating .config ... > > > > Populating config with: > > > > $ make ARCH=arm64 O=.kunit olddefconfig CC=clang > > > > ERROR:root:Not all Kconfig options selected in kunitconfig were in the generated .config. > > > > This is probably due to unsatisfied dependencies. > > > > Missing: CONFIG_KASAN_KUNIT_TEST=y > > > > > > > > By that error message, CONFIG_FTRACE appears to be present in the generated > > > > config, but CONFIG_KASAN_KUNIT_TEST still isn't. Presumably, > > > > CONFIG_KASAN_KUNIT_TEST is missing because of an unsatisfied dependency, which > > > > must be CONFIG_TRACEPOINTS, unless I'm missing something ... > > > > > > > > If I just generate an arm64 defconfig and select CONFIG_FTRACE=y, > > > > CONFIG_TRACEPOINTS=y shows up in my .config. So, maybe this is kunit.py-related > > > > then? > > > > > > > > Andrey, you said that the tests have been working for you; are you running them > > > > with kunit.py? > > > > > > No, I just run the kernel built with a config file that I put together > > > based on defconfig. > > > > Ah. I believe I've figured it out. > > > > When I add CONFIG_STACK_TRACER=y in addition to CONFIG_FTRACE=y, it works. > > CONFIG_FTRACE should be enough - maybe also check x86 vs. arm64 to debug more. See below. > > CONFIG_STACK_TRACER selects CONFIG_FUNCTION_TRACER, CONFIG_FUNCTION_TRACER > > selects CONFIG_GENERIC_TRACER, CONFIG_GENERIC_TRACER selects CONFIG_TRACING, and > > CONFIG_TRACING selects CONFIG_TRACEPOINTS. > > > > CONFIG_BLK_DEV_IO_TRACE=y also works instead of CONFIG_STACK_TRACER=y, as it > > directly selects CONFIG_TRACEPOINTS. > > > > CONFIG_FTRACE=y on its own does not appear suffice for kunit.py on arm64. > > When you build manually with just CONFIG_FTRACE, is CONFIG_TRACEPOINTS enabled? When I add CONFIG_FTRACE and enter-key my way through the FTRACE prompts - I believe because CONFIG_FTRACE is a menuconfig? - at the beginning of a build, CONFIG_TRACEPOINTS does get set on arm64, yes. On X86, the defconfig already includes CONIFG_TRACEPOINTS. I also had a closer look at how kunit.py builds its configs. I believe it does something along the following lines: cp <path_to_kunitconfig> .kunit/.config make ARCH=arm64 O=.kunit olddefconfig On arm64, that isn't enough to set CONFIG_TRACEPOINTS; same behaviour when run outside of kunit.py. For CONFIG_TRACEPOINTS, `make ARCH=arm64 menuconfig` shows: Symbol: TRACEPOINTS [=n] Type : bool Defined at init/Kconfig:1920 Selected by [n]: - TRACING [=n] - BLK_DEV_IO_TRACE [=n] && FTRACE [=y] && SYSFS [=y] && BLOCK [=y] So, CONFIG_TRACING or CONFIG_BLK_DEV_IO_TRACE are the two options that prevent CONFIG_TRACEPOINTS from being set on arm64. For CONFIG_TRACING we have: Symbol: TRACING [=n] Type : bool Defined at kernel/trace/Kconfig:157 Selects: RING_BUFFER [=n] && STACKTRACE [=y] && TRACEPOINTS [=n] && NOP_TRACER [=n] && BINARY_PRINTF [=n] && EVENT_TRACING [=n] && TRACE_CLOCK [=y] && TASKS_RCU [=n] Selected by [n]: - DRM_I915_TRACE_GEM [=n] && HAS_IOMEM [=y] && DRM_I915 [=n] && EXPERT [=n] && DRM_I915_DEBUG_GEM [=n] - DRM_I915_TRACE_GTT [=n] && HAS_IOMEM [=y] && DRM_I915 [=n] && EXPERT [=n] && DRM_I915_DEBUG_GEM [=n] - PREEMPTIRQ_TRACEPOINTS [=n] && (TRACE_PREEMPT_TOGGLE [=n] || TRACE_IRQFLAGS [=n]) - GENERIC_TRACER [=n] - ENABLE_DEFAULT_TRACERS [=n] && FTRACE [=y] && !GENERIC_TRACER [=n] - FPROBE_EVENTS [=n] && FTRACE [=y] && FPROBE [=n] && HAVE_REGS_AND_STACK_ACCESS_API [=y] - KPROBE_EVENTS [=n] && FTRACE [=y] && KPROBES [=n] && HAVE_REGS_AND_STACK_ACCESS_API [=y] - UPROBE_EVENTS [=n] && FTRACE [=y] && ARCH_SUPPORTS_UPROBES [=y] && MMU [=y] && PERF_EVENTS [=n] - SYNTH_EVENTS [=n] && FTRACE [=y] - USER_EVENTS [=n] && FTRACE [=y] - HIST_TRIGGERS [=n] && FTRACE [=y] && ARCH_HAVE_NMI_SAFE_CMPXCHG [=y] > > I believe the reason my .kunitconfig as well as the existing > > mm/kfence/.kunitconfig work on X86 is because CONFIG_TRACEPOINTS=y is present in > > an X86 defconfig. > > > > Does this make sense? > > > > Would you welcome a patch addressing this for the existing > > mm/kfence/.kunitconfig? > > > > I would also like to submit a patch for an mm/kasan/.kunitconfig. Do you think > > that would be helpful too? > > > > FWICT, kernel/kcsan/.kunitconfig might also be affected since > > CONFIG_KCSAN_KUNIT_TEST also depends on CONFIG_TRACEPOITNS, but I would have to > > test that. That could be a third patch. > > I'd support figuring out the minimal config (CONFIG_FTRACE or > something else?) that satisfies the TRACEPOINTS dependency. I always > thought CONFIG_FTRACE ought to be the one config option, but maybe > something changed. If we want a minimal config, setting CONFIG_BLK_DEV_IO_TRACE, CONFIG_SYNTH_EVENTS or CONFIG_USER_EVENTS seem like viable options, for instance. But AFAICT, setting them in the context of KASan doesn't really make sense, and I might be missing an obvious choice here too. What do you think? > Also maybe one of the tracing maintainers can help untangle what's > going on here. > > Thanks, > -- Marco Many thanks, Paul
