NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/54979 (radixtree might misbehave if ENOMEM)
The following reply was made to PR kern/54979; it has been noted by GNATS.
From: Andrew Doran <ad%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc:
Subject: Re: kern/54979 (radixtree might misbehave if ENOMEM)
Date: Sun, 15 Mar 2020 19:56:01 +0000
I see one possible failure path:
Imagine radix_tree_grow() manages to insert >0 nodes to increase the height
of the tree, but fails to allocate at least one node to complete the path,
and returns ENOMEM.
There is an assumption that the operation will be retried and a subsequent
radix_tree_insert_node() will finish it off.
That implies there will be a matching radix_tree_remove_node() later too, to
remove the leaf node and collapse the height of the tree back down to zero.
If the insertion was speculative that might not happen, so the the tree can
be left in limbo.
Now, radix_tree_grow() can't back out what it's done without sabotaging
radix_tree_await_memory(), and a call to uvm_wait() in libkern would suck,
so maybe another solution would be to back out the change and cache the
already allocated nodes with struct radix_tree (with a catchall to free
them in radix_tree_fini_tree()). It's not very elegant though.
Andrew
Home |
Main Index |
Thread Index |
Old Index