linux-kernel - Re: [PATCH 0/2] clk: kunit: Fix the lockdep warnings

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <088cc246369820d5a426bc8823c85c8e.sboyd@kernel.org>
Date:   Wed, 09 Aug 2023 16:21:50 -0700
From:   Stephen Boyd <sboyd@...nel.org>
To:     Maxime Ripard <mripard@...nel.org>,
        Michael Turquette <mturquette@...libre.com>
Cc:     linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org,
        Maxime Ripard <mripard@...nel.org>,
        Guenter Roeck <linux@...ck-us.net>,
        kernel test robot <yujie.liu@...el.com>,
        kunit-dev@...glegroups.com
Subject: Re: [PATCH 0/2] clk: kunit: Fix the lockdep warnings

+kunit-dev

Quoting Maxime Ripard (2023-07-21 00:09:31)
> Hi,
> 
> Here's a small series to address the lockdep warning we have when
> running the clk kunit tests with lockdep enabled.
> 
> For the record, it can be tested with:
> 
> $ ./tools/testing/kunit/kunit.py run \
>     --kunitconfig=drivers/clk \
>     --cross_compile aarch64-linux-gnu- --arch arm64 \
>     --kconfig_add CONFIG_DEBUG_KERNEL=y \
>     --kconfig_add CONFIG_PROVE_LOCKING=y
> 
> Let me know what you think,

Thanks for doing this. I want to roll these helpers into the clk_kunit.c
file that I had created for some other clk tests[1]. That's mostly
because clk.c is already super long and adding kunit code there makes
that problem worse. I'll try to take that patch out of the rest of the
series and then add this series on top and resend.

I don't know what to do about the case where CONFIG_KUNIT=m though. We
have to export clk_prepare_lock/unlock()? I really don't want to do that
even if kunit is enabled (see EXPORT_SYMBOL_IF_KUNIT). Maybe if there
was a GPL version of that, so proprietary modules can't get at kernel
internals on kunit enabled kernels.

But I also like the approach taken here of adding a small stub around
the call to make sure a test is running. Maybe I'll make a kunit
namespaced exported gpl symbol that bails if a test isn't running and
calls the clk_prepare_lock/unlock functions inside clk.c and then move
the rest of the code to clk_kunit.c to get something more strict.

[1] https://lore.kernel.org/all/20230327222159.3509818-9-sboyd@kernel.org/