Hi,
This follows the discussion here:
https://lore.kernel.org/linux-kselftest/20230324123157.bbwvfq4gsxnlnfwb@houat/
This shows a couple of inconsistencies with regard to how device-managed
resources are cleaned up. Basically, devm resources will only be cleaned up
if the device is attached to a bus and bound to a driver. Failing any of
these cases, a call to device_unregister will not end up in the devm
resources being released.
We had to work around it in DRM to provide helpers to create a device for
kunit tests, but the current discussion around creating similar, generic,
helpers for kunit resumed interest in fixing this.
This can be tested using the command:
./tools/testing/kunit/kunit.py run --kunitconfig=drivers/base/test/
Let me know what you think,
Maxime
Signed-off-by: Maxime Ripard <[email protected]>
---
Maxime Ripard (2):
drivers: base: Add basic devm tests for root devices
drivers: base: Add basic devm tests for platform devices
drivers/base/test/.kunitconfig | 2 +
drivers/base/test/Kconfig | 4 +
drivers/base/test/Makefile | 3 +
drivers/base/test/platform-device-test.c | 278 +++++++++++++++++++++++++++++++
drivers/base/test/root-device-test.c | 120 +++++++++++++
5 files changed, 407 insertions(+)
---
base-commit: a6faf7ea9fcb7267d06116d4188947f26e00e57e
change-id: 20230329-kunit-devm-inconsistencies-test-5e5a7d01e60d
Best regards,
--
Maxime Ripard <[email protected]>
The root devices show some odd behaviours compared to regular "bus" devices
that have been probed through the usual mechanism, so let's create kunit
tests to exercise those paths and odd cases.
Signed-off-by: Maxime Ripard <[email protected]>
---
drivers/base/test/.kunitconfig | 2 +
drivers/base/test/Kconfig | 4 ++
drivers/base/test/Makefile | 2 +
drivers/base/test/root-device-test.c | 120 +++++++++++++++++++++++++++++++++++
4 files changed, 128 insertions(+)
diff --git a/drivers/base/test/.kunitconfig b/drivers/base/test/.kunitconfig
new file mode 100644
index 000000000000..473923f0998b
--- /dev/null
+++ b/drivers/base/test/.kunitconfig
@@ -0,0 +1,2 @@
+CONFIG_KUNIT=y
+CONFIG_DM_KUNIT_TEST=y
diff --git a/drivers/base/test/Kconfig b/drivers/base/test/Kconfig
index 610a1ba7a467..9d42051f8f8e 100644
--- a/drivers/base/test/Kconfig
+++ b/drivers/base/test/Kconfig
@@ -9,6 +9,10 @@ config TEST_ASYNC_DRIVER_PROBE
If unsure say N.
+config DM_KUNIT_TEST
+ tristate "KUnit Tests for the device model" if !KUNIT_ALL_TESTS
+ depends on KUNIT
+
config DRIVER_PE_KUNIT_TEST
bool "KUnit Tests for property entry API" if !KUNIT_ALL_TESTS
depends on KUNIT=y
diff --git a/drivers/base/test/Makefile b/drivers/base/test/Makefile
index 7f76fee6f989..d589ca3fa8fc 100644
--- a/drivers/base/test/Makefile
+++ b/drivers/base/test/Makefile
@@ -1,5 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_TEST_ASYNC_DRIVER_PROBE) += test_async_driver_probe.o
+obj-$(CONFIG_DM_KUNIT_TEST) += root-device-test.o
+
obj-$(CONFIG_DRIVER_PE_KUNIT_TEST) += property-entry-test.o
CFLAGS_property-entry-test.o += $(DISABLE_STRUCTLEAK_PLUGIN)
diff --git a/drivers/base/test/root-device-test.c b/drivers/base/test/root-device-test.c
new file mode 100644
index 000000000000..fcb55d8882aa
--- /dev/null
+++ b/drivers/base/test/root-device-test.c
@@ -0,0 +1,120 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright 2023 Maxime Ripard <[email protected]>
+
+#include <kunit/resource.h>
+
+#include <linux/device.h>
+
+#define DEVICE_NAME "test"
+
+struct test_priv {
+ bool probe_done;
+ bool release_done;
+ wait_queue_head_t release_wq;
+ struct device *dev;
+};
+
+static void devm_device_action(void *ptr)
+{
+ struct test_priv *priv = ptr;
+
+ priv->release_done = true;
+ wake_up_interruptible(&priv->release_wq);
+}
+
+static void devm_put_device_action(void *ptr)
+{
+ struct test_priv *priv = ptr;
+
+ put_device(priv->dev);
+ priv->release_done = true;
+ wake_up_interruptible(&priv->release_wq);
+}
+
+#define RELEASE_TIMEOUT_MS 500
+
+static void root_device_devm_register_unregister_test(struct kunit *test)
+{
+ struct test_priv *priv;
+ int ret;
+
+ priv = kunit_kzalloc(test, sizeof(*priv), GFP_KERNEL);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, priv);
+ init_waitqueue_head(&priv->release_wq);
+
+ priv->dev = root_device_register(DEVICE_NAME);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, priv->dev);
+
+ ret = devm_add_action_or_reset(priv->dev, devm_device_action, priv);
+ KUNIT_ASSERT_EQ(test, ret, 0);
+
+ root_device_unregister(priv->dev);
+
+ ret = wait_event_interruptible_timeout(priv->release_wq, priv->release_done,
+ msecs_to_jiffies(RELEASE_TIMEOUT_MS));
+ KUNIT_EXPECT_GT(test, ret, 0);
+}
+
+static void root_device_devm_register_get_put_unregister_test(struct kunit *test)
+{
+ struct test_priv *priv;
+ int ret;
+
+ priv = kunit_kzalloc(test, sizeof(*priv), GFP_KERNEL);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, priv);
+ init_waitqueue_head(&priv->release_wq);
+
+ priv->dev = root_device_register(DEVICE_NAME);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, priv->dev);
+
+ get_device(priv->dev);
+
+ ret = devm_add_action_or_reset(priv->dev, devm_device_action, priv);
+ KUNIT_ASSERT_EQ(test, ret, 0);
+
+ put_device(priv->dev);
+
+ root_device_unregister(priv->dev);
+
+ ret = wait_event_interruptible_timeout(priv->release_wq, priv->release_done,
+ msecs_to_jiffies(RELEASE_TIMEOUT_MS));
+ KUNIT_EXPECT_GT(test, ret, 0);
+}
+
+static void root_device_devm_register_get_unregister_with_devm_test(struct kunit *test)
+{
+ struct test_priv *priv;
+ int ret;
+
+ priv = kunit_kzalloc(test, sizeof(*priv), GFP_KERNEL);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, priv);
+ init_waitqueue_head(&priv->release_wq);
+
+ priv->dev = root_device_register(DEVICE_NAME);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, priv->dev);
+
+ get_device(priv->dev);
+
+ ret = devm_add_action_or_reset(priv->dev, devm_put_device_action, priv);
+ KUNIT_ASSERT_EQ(test, ret, 0);
+
+ root_device_unregister(priv->dev);
+
+ ret = wait_event_interruptible_timeout(priv->release_wq, priv->release_done,
+ msecs_to_jiffies(RELEASE_TIMEOUT_MS));
+ KUNIT_EXPECT_GT(test, ret, 0);
+}
+
+static struct kunit_case root_device_devm_tests[] = {
+ KUNIT_CASE(root_device_devm_register_unregister_test),
+ KUNIT_CASE(root_device_devm_register_get_put_unregister_test),
+ KUNIT_CASE(root_device_devm_register_get_unregister_with_devm_test),
+ {}
+};
+
+static struct kunit_suite root_device_devm_test_suite = {
+ .name = "root-device-devm",
+ .test_cases = root_device_devm_tests,
+};
+
+kunit_test_suite(root_device_devm_test_suite);
--
2.40.0
Hi Maxime,
I love your patch! Perhaps something to improve:
[auto build test WARNING on a6faf7ea9fcb7267d06116d4188947f26e00e57e]
url: https://github.com/intel-lab-lkp/linux/commits/Maxime-Ripard/drivers-base-Add-basic-devm-tests-for-root-devices/20230330-034149
base: a6faf7ea9fcb7267d06116d4188947f26e00e57e
patch link: https://lore.kernel.org/r/20230329-kunit-devm-inconsistencies-test-v1-1-c33127048375%40cerno.tech
patch subject: [PATCH 1/2] drivers: base: Add basic devm tests for root devices
config: arc-randconfig-r043-20230329 (https://download.01.org/0day-ci/archive/20230330/[email protected]/config)
compiler: arc-elf-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/intel-lab-lkp/linux/commit/a6c0627f4059cf0565eec2bb99fc7453e20b5c51
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review Maxime-Ripard/drivers-base-Add-basic-devm-tests-for-root-devices/20230330-034149
git checkout a6c0627f4059cf0565eec2bb99fc7453e20b5c51
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=arc olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=arc SHELL=/bin/bash
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <[email protected]>
| Link: https://lore.kernel.org/oe-kbuild-all/[email protected]/
All warnings (new ones prefixed by >>):
>> drivers/base/test/.kunitconfig: warning: ignored by one of the .gitignore files
drivers/clk/.kunitconfig: warning: ignored by one of the .gitignore files
drivers/gpu/drm/tests/.kunitconfig: warning: ignored by one of the .gitignore files
drivers/gpu/drm/vc4/tests/.kunitconfig: warning: ignored by one of the .gitignore files
drivers/hid/.kunitconfig: warning: ignored by one of the .gitignore files
fs/ext4/.kunitconfig: warning: ignored by one of the .gitignore files
fs/fat/.kunitconfig: warning: ignored by one of the .gitignore files
kernel/kcsan/.kunitconfig: warning: ignored by one of the .gitignore files
lib/kunit/.kunitconfig: warning: ignored by one of the .gitignore files
mm/kfence/.kunitconfig: warning: ignored by one of the .gitignore files
net/sunrpc/.kunitconfig: warning: ignored by one of the .gitignore files
tools/testing/selftests/arm64/tags/.gitignore: warning: ignored by one of the .gitignore files
tools/testing/selftests/arm64/tags/Makefile: warning: ignored by one of the .gitignore files
tools/testing/selftests/arm64/tags/run_tags_test.sh: warning: ignored by one of the .gitignore files
tools/testing/selftests/arm64/tags/tags_test.c: warning: ignored by one of the .gitignore files
tools/testing/selftests/kvm/.gitignore: warning: ignored by one of the .gitignore files
tools/testing/selftests/kvm/Makefile: warning: ignored by one of the .gitignore files
tools/testing/selftests/kvm/config: warning: ignored by one of the .gitignore files
tools/testing/selftests/kvm/settings: warning: ignored by one of the .gitignore files
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
Hi,
On Wed, Mar 29, 2023 at 08:38:30PM +0100, Maxime Ripard wrote:
> Hi,
>
> This follows the discussion here:
> https://lore.kernel.org/linux-kselftest/20230324123157.bbwvfq4gsxnlnfwb@houat/
>
> This shows a couple of inconsistencies with regard to how device-managed
> resources are cleaned up. Basically, devm resources will only be cleaned up
> if the device is attached to a bus and bound to a driver. Failing any of
> these cases, a call to device_unregister will not end up in the devm
> resources being released.
>
> We had to work around it in DRM to provide helpers to create a device for
> kunit tests, but the current discussion around creating similar, generic,
> helpers for kunit resumed interest in fixing this.
>
> This can be tested using the command:
> ./tools/testing/kunit/kunit.py run --kunitconfig=drivers/base/test/
>
> Let me know what you think,
> Maxime
>
> Signed-off-by: Maxime Ripard <[email protected]>
Is there any news on this?
Maxime
On Wed, Mar 29, 2023 at 08:38:30PM +0100, Maxime Ripard wrote:
> Hi,
>
> This follows the discussion here:
> https://lore.kernel.org/linux-kselftest/20230324123157.bbwvfq4gsxnlnfwb@houat/
>
> This shows a couple of inconsistencies with regard to how device-managed
> resources are cleaned up. Basically, devm resources will only be cleaned up
> if the device is attached to a bus and bound to a driver. Failing any of
> these cases, a call to device_unregister will not end up in the devm
> resources being released.
>
> We had to work around it in DRM to provide helpers to create a device for
> kunit tests, but the current discussion around creating similar, generic,
> helpers for kunit resumed interest in fixing this.
>
> This can be tested using the command:
> ./tools/testing/kunit/kunit.py run --kunitconfig=drivers/base/test/
>
> Let me know what you think,
> Maxime
>
> Signed-off-by: Maxime Ripard <[email protected]>
Ping?
How can we move this forward?
Maxime
On Mon, Apr 17, 2023 at 06:12:26PM +0200, Maxime Ripard wrote:
> Hi,
>
> On Wed, Mar 29, 2023 at 08:38:30PM +0100, Maxime Ripard wrote:
> > Hi,
> >
> > This follows the discussion here:
> > https://lore.kernel.org/linux-kselftest/20230324123157.bbwvfq4gsxnlnfwb@houat/
> >
> > This shows a couple of inconsistencies with regard to how device-managed
> > resources are cleaned up. Basically, devm resources will only be cleaned up
> > if the device is attached to a bus and bound to a driver. Failing any of
> > these cases, a call to device_unregister will not end up in the devm
> > resources being released.
> >
> > We had to work around it in DRM to provide helpers to create a device for
> > kunit tests, but the current discussion around creating similar, generic,
> > helpers for kunit resumed interest in fixing this.
> >
> > This can be tested using the command:
> > ./tools/testing/kunit/kunit.py run --kunitconfig=drivers/base/test/
> >
> > Let me know what you think,
> > Maxime
> >
> > Signed-off-by: Maxime Ripard <[email protected]>
>
> Is there any news on this?
Can you resend, last I saw the kernel test robot had a problem, which
causes any patch series like that to be ignored by me.
thanks,
greg k-h
On Wed, May 31, 2023 at 08:20:13PM +0100, Greg Kroah-Hartman wrote:
> On Mon, Apr 17, 2023 at 06:12:26PM +0200, Maxime Ripard wrote:
> > Hi,
> >
> > On Wed, Mar 29, 2023 at 08:38:30PM +0100, Maxime Ripard wrote:
> > > Hi,
> > >
> > > This follows the discussion here:
> > > https://lore.kernel.org/linux-kselftest/20230324123157.bbwvfq4gsxnlnfwb@houat/
> > >
> > > This shows a couple of inconsistencies with regard to how device-managed
> > > resources are cleaned up. Basically, devm resources will only be cleaned up
> > > if the device is attached to a bus and bound to a driver. Failing any of
> > > these cases, a call to device_unregister will not end up in the devm
> > > resources being released.
> > >
> > > We had to work around it in DRM to provide helpers to create a device for
> > > kunit tests, but the current discussion around creating similar, generic,
> > > helpers for kunit resumed interest in fixing this.
> > >
> > > This can be tested using the command:
> > > ./tools/testing/kunit/kunit.py run --kunitconfig=drivers/base/test/
> > >
> > > Let me know what you think,
> > > Maxime
> > >
> > > Signed-off-by: Maxime Ripard <[email protected]>
> >
> > Is there any news on this?
>
> Can you resend, last I saw the kernel test robot had a problem, which
> causes any patch series like that to be ignored by me.
Yeah, this was due to .kunitconfig being ignored by .gitignore, which
triggers a warning for the bot.
It's now fixed (at least in next), and I just resent the patches
Thanks!
Maxime
On Fri, Jun 02, 2023 at 05:27:05PM +0200, Maxime Ripard wrote:
> On Wed, May 31, 2023 at 08:20:13PM +0100, Greg Kroah-Hartman wrote:
> > On Mon, Apr 17, 2023 at 06:12:26PM +0200, Maxime Ripard wrote:
> > > Hi,
> > >
> > > On Wed, Mar 29, 2023 at 08:38:30PM +0100, Maxime Ripard wrote:
> > > > Hi,
> > > >
> > > > This follows the discussion here:
> > > > https://lore.kernel.org/linux-kselftest/20230324123157.bbwvfq4gsxnlnfwb@houat/
> > > >
> > > > This shows a couple of inconsistencies with regard to how device-managed
> > > > resources are cleaned up. Basically, devm resources will only be cleaned up
> > > > if the device is attached to a bus and bound to a driver. Failing any of
> > > > these cases, a call to device_unregister will not end up in the devm
> > > > resources being released.
> > > >
> > > > We had to work around it in DRM to provide helpers to create a device for
> > > > kunit tests, but the current discussion around creating similar, generic,
> > > > helpers for kunit resumed interest in fixing this.
> > > >
> > > > This can be tested using the command:
> > > > ./tools/testing/kunit/kunit.py run --kunitconfig=drivers/base/test/
> > > >
> > > > Let me know what you think,
> > > > Maxime
> > > >
> > > > Signed-off-by: Maxime Ripard <[email protected]>
> > >
> > > Is there any news on this?
> >
> > Can you resend, last I saw the kernel test robot had a problem, which
> > causes any patch series like that to be ignored by me.
>
> Yeah, this was due to .kunitconfig being ignored by .gitignore, which
> triggers a warning for the bot.
>
> It's now fixed (at least in next), and I just resent the patches
Still triggered the bot :(