[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <def0fd33-da11-6283-d98f-66eb9a8dd201@redhat.com>
Date: Fri, 26 Mar 2021 14:23:39 -0400
From: Chris von Recklinghausen <crecklin@...hat.com>
To: "Matthew Wilcox (Oracle)" <willy@...radead.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: tools/testing/radix-tree/idr-test gets a failed assertion on single
cpu systems
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@...-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
Powered by blists - more mailing lists