tools/testing/radix-tree/idr-test gets a failed assertion on single cpu systems

[Chris von Recklinghausen]

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