On 11/9/26 10:35, Petr Oros wrote:
With CONFIG_DPLL_REFCNT_TRACKER the DPLL core keeps the stack traces of
unreleased device and pin references in debugfs. The entries do not
name their owner, so add library helpers that snapshot the entries
present before a test creates its devices and fail when an entry that
is not in the snapshot still holds references afterwards. An entry in
the snapshot belongs to an object of another driver and is ignored
even when its content changed, since other drivers take and drop
references while the tests run. The teardown of a device releases its
references before the write to live returns, so the entries are
expected to be gone at the first look; the check still polls for a
while before it reports a leak, so that it does not fail on a single
read. Attributing
by name means that a leak of an earlier run goes unnoticed and that an
object reusing the address of a freed one from the snapshot can hide a
leak, which is accepted, the entries carry nothing better to go by. A
second run alongside would have its devices attributed to this one,
which is one more reason for the lock every script takes.
Whether the tracker works is probed with a throwaway device, which has
to show entries while it is live and to drain them once it is deleted,
so that a kernel without the tracker is told apart from a broken
simulator and from a leak. The probe runs as the first test of the
stress script, which gains a final leak check, and of the new
dpll_reftrack.sh, which registers a device, removes it and verifies
that no reference survived. The snapshot file lives next to the lock
file under /run, for the same reason the lock file does not live in
/tmp. The library mounts debugfs when nothing else did, like it does
for configfs, and the selftest config enables the tracker together
with CONFIG_DEBUG_KERNEL, which it depends on, and debugfs.
Acked-by: Jiri Pirko<redacted>
Signed-off-by: Petr Oros<redacted>
---
v3:
- say what the leak check waits for instead of a concurrent dump
holding references, which nothing does (Ivan Vecera)
- follow the move of the selftests to
tools/testing/selftests/drivers/dpll
Reviewed-by: Ivan Vecera <ivecera@redhat.com>