Re: [PATCH 1/2] memblock tests: model the low allocation limit within dummy memory

[Tianyi Chen]

Hi Mike,

Thank you for reviewing both patches. I have addressed the attribution
and wording in v2:
https://lore.kernel.org/r/178874362959.1415955.18132997964995947947.memblock-v2-0@xxxxxxxxx

> Shouldn't this be PHYS_MEM_SIZE?

MEM_SIZE is intentional here. setup_memblock() registers only MEM_SIZE
(32 KiB), although malloc() allocates a PHYS_MEM_SIZE (16 MiB) backing
buffer. Splitting the registered range leaves usable memory on both sides
of the limit. PHYS_MEM_SIZE / 2 would put the limit above all registered
memory. The comment, README and commit message now explain this.

On the alignment question in patch 2: the registered base is the malloc()
result, which is not guaranteed to have SMP_CACHE_BYTES alignment
(32 bytes in this simulator). ALIGN() also matches the allocator's
round_up(this_start, align) in __memblock_find_range_bottom_up(); it is
harmless when the base is already aligned.

By "exclusive limit" I meant the first address an allocation must not
use. region_end() is base + size, so equality with the limit is valid.
I have replaced that wording with the allocation's last byte being
immediately below the limit.

You are also right about the reserved-memory comment: reserving low
memory succeeds; the subsequent low-memory allocation must fail. I have
corrected that description. Both patches now use Assisted-by: Codex:GPT-6.

The five configuration combinations described in the cover letter passed
with ASan/UBSan, movable-node mode enabled and disabled, and both allocation
directions. The cover also records the separate, pre-existing BUILD=32
basic_api assertion failure.

Thanks,
Tianyi