All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Gregory Price" <gourry@gourry.net>
Cc: linux-cxl@vger.kernel.org, nvdimm@lists.linux.dev
Subject: Re: [PATCH v5 9/9] selftests/dax: add dax/kmem hotplug sysfs regression test
Date: Wed, 24 Jun 2026 15:12:50 +0000	[thread overview]
Message-ID: <20260624151251.5B3961F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260624145744.3532049-10-gourry@gourry.net>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Cascading test failures due to unhandled baseline restoration failure.
- [Medium] Device state restoration is clobbered before the destructive test, leaving the device altered if the test is skipped.
--

commit 86db030de2c10bd6941657c29afc9ffc162f74b5
Author: Gregory Price <gourry@gourry.net>

selftests/dax: add dax/kmem hotplug sysfs regression test

This commit adds a kselftest for the dax/kmem whole-device "state" sysfs
attribute to validate transitions between unplugged, online, and
online_movable.

> diff --git a/tools/testing/selftests/dax/dax-kmem-hotplug.sh b/tools/testing/selftests/dax/dax-kmem-hotplug.sh
> new file mode 100755
> index 0000000000000..803bbd5a64098
> --- /dev/null
> +++ b/tools/testing/selftests/dax/dax-kmem-hotplug.sh

[ ... ]

> +set_state unplugged; rc=$?
> +mt=$(memtotal_kb)
> +if [ "$rc" != 0 ]; then
> +	ktap_test_skip "unplug from movable not accepted (memory in use?) rc=$rc"
> +elif [ "$(get_state)" = unplugged ] && [ "$mt" -lt "$mt_movable" ]; then
> +	ktap_test_pass "unplug from online_movable removed memory: $mt_movable -> $mt kB"
> +else
> +	ktap_test_fail "unplug from movable reported success but memory remained: state=$(get_state) MemTotal $mt_movable -> $mt"
> +fi
> +
> +set_state online_kernel; rc=$?

[Severity: Medium]
If the unplug command fails and we emit the ktap_test_skip message, the script
continues execution to the online_kernel test.

Since that test expects an unplugged baseline, does this lead to cascading
spurious test failures if the memory couldn't be offlined?

[ ... ]

> +[ -n "$ORIG" ] && set_state "$ORIG"
> +
> +# DESTRUCTIVE: unbinding the driver while memory is online causes the resources
> +# to leak - but the unbind should not deadlock.  Instead the driver leaks it
> +# with a single "suck online" warning. This leaves the memory online and the
> +# device unbound until reboot, so it runs last.
> +set_state unplugged; set_state online
> +if [ "$(get_state)" = online ] && [ -w "$DRV/unbind" ]; then

[Severity: Medium]
We restore the original state of the device here, but then unconditionally
overwrite it by running "set_state unplugged; set_state online" before checking
if the destructive test can actually run.

If $DRV/unbind is not writable, the test is skipped and the script exits.

Does this leave the device permanently altered (left "online") instead of in
its original state?

> +	mt_on=$(memtotal_kb)
> +	dmesg -C 2>/dev/null
> +	echo "$DAX" > "$DRV/unbind" 2>/dev/null
> +	mt_after=$(memtotal_kb)

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260624145744.3532049-1-gourry@gourry.net?part=9

  reply	other threads:[~2026-06-24 15:12 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-24 14:57 [PATCH v5 0/9] dax/kmem: atomic whole-device hotplug via sysfs Gregory Price
2026-06-24 14:57 ` [PATCH v5 1/9] mm/memory: add memory_block_aligned_range() helper Gregory Price
2026-06-24 15:08   ` sashiko-bot
2026-06-24 14:57 ` [PATCH v5 2/9] mm/memory_hotplug: pass online_type to online_memory_block() via arg Gregory Price
2026-06-24 16:28   ` Gupta, Pankaj
2026-06-24 14:57 ` [PATCH v5 3/9] mm/memory_hotplug: export mhp_get_default_online_type Gregory Price
2026-06-24 14:57 ` [PATCH v5 4/9] mm/memory_hotplug: add __add_memory_driver_managed() with online_type arg Gregory Price
2026-06-24 16:41   ` Gupta, Pankaj
2026-06-24 14:57 ` [PATCH v5 5/9] mm/memory_hotplug: offline_and_remove_memory_ranges() Gregory Price
2026-06-24 15:11   ` sashiko-bot
2026-06-24 14:57 ` [PATCH v5 6/9] dax: plumb hotplug online_type through dax Gregory Price
2026-06-24 15:12   ` sashiko-bot
2026-06-24 14:57 ` [PATCH v5 7/9] dax/kmem: extract hotplug/hotremove helper functions Gregory Price
2026-06-24 15:09   ` sashiko-bot
2026-06-24 14:57 ` [PATCH v5 8/9] dax/kmem: add sysfs interface for atomic whole-device hotplug Gregory Price
2026-06-24 15:11   ` sashiko-bot
2026-06-24 14:57 ` [PATCH v5 9/9] selftests/dax: add dax/kmem hotplug sysfs regression test Gregory Price
2026-06-24 15:12   ` sashiko-bot [this message]
2026-06-24 18:59 ` [PATCH v5 0/9] dax/kmem: atomic whole-device hotplug via sysfs Gregory Price

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260624151251.5B3961F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=gourry@gourry.net \
    --cc=linux-cxl@vger.kernel.org \
    --cc=nvdimm@lists.linux.dev \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.