linux-kernel - Re: [PATCH v8 8/8] clk: Add KUnit tests for clks registered with struct clk_parent

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <cb1e0119-6e3e-4fd2-92ea-3fec18f5843d@roeck-us.net>
Date: Thu, 3 Oct 2024 21:52:09 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Stephen Boyd <sboyd@...nel.org>, Shuah Khan <skhan@...uxfoundation.org>
Cc: Michael Turquette <mturquette@...libre.com>,
 linux-kernel@...r.kernel.org, linux-clk@...r.kernel.org,
 patches@...ts.linux.dev, kunit-dev@...glegroups.com,
 linux-kselftest@...r.kernel.org, devicetree@...r.kernel.org,
 Brendan Higgins <brendan.higgins@...ux.dev>, David Gow
 <davidgow@...gle.com>, Rae Moar <rmoar@...gle.com>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 "Rafael J.Wysocki" <rafael@...nel.org>, Rob Herring <robh@...nel.org>,
 Saravana Kannan <saravanak@...gle.com>, Daniel Latypov
 <dlatypov@...gle.com>, Christian Marangi <ansuelsmth@...il.com>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>, Maxime Ripard <maxime@...no.tech>,
 Geert Uytterhoeven <geert+renesas@...der.be>
Subject: Re: [PATCH v8 8/8] clk: Add KUnit tests for clks registered with
 struct clk_parent_data

On 10/3/24 17:42, Stephen Boyd wrote:
> Quoting Guenter Roeck (2024-10-03 17:25:37)
>> On 10/3/24 16:46, Stephen Boyd wrote:
>> [ ... ]
>>> That DT test has been there for a few releases. Is this the first time
>>> those tests have been run on arm64+acpi? I didn't try after sending the
>>> patches and forgot that the patch was dropped.
>>>
>>
>> Previously I had the affected tests disabled and never tracked down the problem.
>> Since the problem is now spreading to additional tests, I finally tracked it down,
>> that is all.
> 
> Ok great. Good to know this isn't a new problem. Thanks for tracking it
> down.
> 
>>
>>> How are you running kunit tests? I installed the qemu-efi-aarch64 debian
>>> package to get QEMU_EFI.fd but passing that to the kunit.py run command
>>> with --qemu_args="-bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd" didn't
>>> get me beyond the point that the EFI stub boots linux. I think the
>>> serial console must not be working and thus the kunit wrapper waits for
>>> something to show up but nothing ever does. I haven't dug any further
>>> though, so maybe you have a working command.
>>>
>>
>> I run all tests during boot, not from the command line. I also use the -bios
>> command but don't recall any issues with the console. I specify the
>> console on the qemu command line; depending on the qemu machine it is either
>> ttyS0 or ttyAMA0. The init script then finds and selects the active console.
> 
> Can you please describe how you run the kunit test? And provide the qemu
> command you run to boot arm64 with acpi?
> 

Example command line:

qemu-system-aarch64 -M virt -m 512 \
      -kernel arch/arm64/boot/Image -no-reboot -nographic \
      -snapshot \
      -bios /opt/buildbot/rootfs/arm64/../firmware/QEMU_EFI-aarch64.fd \
      -device virtio-blk-device,drive=d0 \
      -drive file=rootfs.ext2,if=none,id=d0,format=raw \
      -cpu cortex-a57 -serial stdio -monitor none -no-reboot \
      --append "kunit.stats_enabled=2 kunit.filter=speed>slow root=/dev/vda rootwait earlycon=pl011,0x9000000 console=ttyAMA0"

That works fine for me. Configuration is arm64 defconfig plus various
debug and kunit options. I built the efi image myself from sources.
The root file system is from buildroot with modified init script.
kunit tests are all built into the kernel and run during boot.

>>
>> I'll just keep the affected tests disabled on arm64 for the time being.
> 
> We should skip the tests on arm64+acpi, which is similar to disabling
> but not exactly the same. There will likely be more DT overlay usage in
> kunit and so that will lead to more test disabling. Skipping properly is
> the better solution.

Sure, but having those tests fail all the time doesn't help either.
I'll re-enable the tests if / when they are skipped.

Thanks,
Guenter