From: Adrian Johnston <adrian3@gmail.com>
To: Donald Zickus <dzickus@redhat.com>
Cc: kernelci@lists.linux.dev
Subject: Re: ref_tracker
Date: Mon, 7 Apr 2025 12:07:28 -0700 [thread overview]
Message-ID: <CAMtebm+onFgWnwDjotybQOr5aWZFFZ+3=jhhA_RLgMDWst3rXw@mail.gmail.com> (raw)
In-Reply-To: <CAK18DXbHK5BOjEcLSAnMSZ4SejXtwiQ_EhrnzsN9U2stg8XGBQ@mail.gmail.com>
There was a LWN article that descrives it:
https://lwn.net/Articles/877603/ That article claims that "A simple
call to ref_tracker_dir_print() will cause the stack traces associated
with any leaked references to be printed to the system log."
From looking at the code:
https://codebrowser.dev/linux/linux/lib/ref_tracker.c.html It seems
that a double free will cause a printk(KERN_ERR...). If you have that
as part of your debug build the it should just be a matter of checking
the logs. This probably the most important class of bugs.
Eric Dumazet <eric.dumazet@gmail.com> was the original author. The
main questions I have about this tool is whether more changes would be
required to capture ref-counts all across the kernel. I'm happy to
follow up with him if you want me to get him involved.
On Mon, Apr 7, 2025 at 6:27 AM Donald Zickus <dzickus@redhat.com> wrote:
>
> Hi Adrian,
>
> On Fri, Apr 4, 2025 at 5:53 PM Adrian Johnston <adrian3@gmail.com> wrote:
>>
>> Hello kernelci,
>>
>> I have exciting news. We have a reoccurring class of dangerous bugs in
>> the kernel that could be identified during a CI run.
>>
>> The kernel comes with a reference count debugger called ref_tracker.
>> And yet, every minor release of the kernel seems to fix another
>> reference counting bug. Often kernel releases fix 3 or more.
>> Meanwhile, the folks over on linux-debuggers aren't even sure anyone
>> is using this reference counting debugger that often.
>>
>> Is anyone willing to flip the switch on this debugger on your staging
>> machine? This seems like the kind of thing Linus should know about 20
>> minutes after merging a patch.
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/ref_tracker.h
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4e66934eaadc83b27ada8d42b60894018f3bfabf
>
>
> It appears the Fedora / Red Hat kernels have it enabled in their debug kernels. We don't explicitly set it, it appears to be auto enabled by setting the 'DEBUG' config. Not sure if that is expected.
>
> How can a CI system take advantage of this? Is there a stack trace that shows up? Do we have to cat the output of a /sys or /proc file?
>
> Cheers,
> Don
>
>>
>>
>> Thanks!
>>
prev parent reply other threads:[~2025-04-07 19:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-04 21:44 ref_tracker Adrian Johnston
2025-04-07 13:10 ` ref_tracker Gustavo Padovan
[not found] ` <CAK18DXbHK5BOjEcLSAnMSZ4SejXtwiQ_EhrnzsN9U2stg8XGBQ@mail.gmail.com>
2025-04-07 19:07 ` Adrian Johnston [this message]
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='CAMtebm+onFgWnwDjotybQOr5aWZFFZ+3=jhhA_RLgMDWst3rXw@mail.gmail.com' \
--to=adrian3@gmail.com \
--cc=dzickus@redhat.com \
--cc=kernelci@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).