Allocation of last block requires blist cursor reset

[dougm]

Summary

If the cursor is left sitting at the end of managed memory after an allocation, then the next allocation request will lead it to march into unmanaged memory, with dire consequences.

Test Plan

I think this change is supposed to fix issue like kostik1026.

[pho]

Ran the test scenario which triggered the "panic: Swapdev not found" for 5 hours without issues.

[alc]

I have run numerous tests since r322459 was committed that have wrapped around the swap area without crashing, so there must be another prerequisite to a crash: Your swap area is a fully allocated tree, i.e., the number of blocks equals the radix. Can we also solve this problem by placing a sentinel entry at the end of a fully allocated tree?

[dougm]

A sentinel is not sufficient. While cursor sits at the end of managed memory, we start with scan = bl_root, and compute blk == cursor, so child == 0, so we loop over the 16 subchildren of root and if we find a free block at p, we report a free block at p+radix. Nothing gets us to actually look at the new sentinel, unless we make the tree one level higher, with the 2nd child of the root consisting of the sentinel only.

[dougm]

Also worth considering - a change that adds no new lines and only rewrites line 253 as
bl->bl_cursor = blk;

[alc]

In D12106#251258, @dougm_rice.edu wrote:

A sentinel is not sufficient. While cursor sits at the end of managed memory, we start with scan = bl_root, and compute blk == cursor, so child == 0, so we loop over the 16 subchildren of root and if we find a free block at p, we report a free block at p+radix. Nothing gets us to actually look at the new sentinel, unless we make the tree one level higher, with the 2nd child of the root consisting of the sentinel only.

Ok. After considering the trade-offs among the three possible fixes, I'm going to commit the original one.