assoc_array: don't chain a new shortcut onto an existing one

When a full node's leaves and the new key all share the node's segment,
assoc_array_insert_into_terminal_node() replaces the node with a
shortcut to a pair of new nodes.  If the node is itself the target of a
shortcut, the new shortcut is installed as that shortcut's next node,
and a shortcut leading to a shortcut is something nothing expects:
assoc_array_walk() indexes the second one as a node, and
assoc_array_apply_edit() hits the BUG_ON() in the loop that adjusts
nr_leaves_on_branch, on that same insertion.

Deletion gets a node there.  When the subtree below a shortcut shrinks
enough, assoc_array_delete() collapses it into one node below the
shortcut, and the leaves it collects can all share that node's segment.
The next key that shares it too takes this path.  Eighteen insertions
and a deletion are enough: sixteen keys that agree on bits 0-11, one
that leaves them at bit 8 and is deleted again, and one more that agrees
with the sixteen.

Have the new shortcut replace the one in front of the node as well.
assoc_array_insert_shortcut() gives it that shortcut's back pointer and
parent slot, so the caller installs it where that one was, and excises
the old shortcut along with the node, which takes a second entry in
excised_meta[].  The new shortcut's index key comes from the new key up
to the new skip level, so it covers what the old one did.

Found by a userspace test doing random insertions and deletions on keys
that share long prefixes; a targeted case builds a shortcut, deletes
down to the collapse and inserts one more key.

Fixes: 3cb989501c26 ("Add a generic associative array implementation.")
Reported-by: Ollrogge <nils-ollrogge@outlook.de>
Assisted-by: LLM
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

0 files changed, 0 insertions, 0 deletions