From: Chris von Recklinghausen <crecklin@redhat.com>
To: "Matthew Wilcox (Oracle)" <willy@infradead.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: tools/testing/radix-tree/idr-test gets a failed assertion on single cpu systems
Date: Fri, 26 Mar 2021 14:23:39 -0400 [thread overview]
Message-ID: <def0fd33-da11-6283-d98f-66eb9a8dd201@redhat.com> (raw)
Hi Matthew,
I made the observation that while tools/testing/radix-tree/idr-test runs
and passes just fine on a system with more than one cpu, it gets an
assertion failure when run on a single cpu system. My test system is
Fedora 34 running on an x86_64 system. It can be easily reproduced by
offlining all cpus but cpu0.
[root@hpe-ml110g7-01 linux]# tools/testing/radix-tree/idr-test
vvv Ignore these warnings
assertion failed at idr.c:250
assertion failed at idr.c:206
^^^ Warnings over
idr-test: idr-test.c:320: idr_find_test_1: Assertion `!(entry !=
xa_mk_value(id))' failed.
Aborted (core dumped)
I bisected the change to 5c089fd0c734 ("idr: Fix idr_get_next race with
idr_remove").
Since idr_get_next can return NULL, I stuck a BUG_ON(!entry) just above
the failing assert, and in this case idr_get_next is returning NULL.
Next, I stuck a BUG_ON in the place that idr_get_next_ul returns NULL
and commented out the contents of idr_u32_test1 so we're not knowingly
passing it bad values, and we seem to fail because the list has been
gone through.
void *idr_get_next_ul(struct idr *idr, unsigned long *nextid)
{
struct radix_tree_iter iter;
void __rcu **slot;
void *entry = NULL;
unsigned long base = idr->idr_base;
unsigned long id = *nextid;
id = (id < base) ? 0 : id - base;
radix_tree_for_each_slot(slot, &idr->idr_rt, &iter, id) {
entry = rcu_dereference_raw(*slot);
if (!entry)
continue;
if (!xa_is_internal(entry))
break;
if (slot != &idr->idr_rt.xa_head && !xa_is_retry(entry))
break;
slot = radix_tree_iter_retry(&iter);
}
if (!slot)
return NULL; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
*nextid = iter.index + base;
return entry;
}
EXPORT_SYMBOL(idr_get_next_ul);
I'm not sure if this is a test issue or possibly an issue with user
level RCU when there's only a single cpu in the system, but I figured it
was worth bringing it to your attention. If there's anything I can do to
help to further analyze this or try out a fix, I'm happy to help.
Thanks,
Chris von Recklinghausen
Red Hat
next reply other threads:[~2021-03-26 18:25 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-26 18:23 Chris von Recklinghausen [this message]
2021-03-28 20:03 ` Matthew Wilcox
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=def0fd33-da11-6283-d98f-66eb9a8dd201@redhat.com \
--to=crecklin@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=willy@infradead.org \
/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
all inboxes | Powered by JetHome®