[PATCH v2 0/2] memblock tests: cover low-address allocations

Tianyi Chen posted 2 patches 2 weeks, 4 days ago
There is a newer version of this series
tools/testing/memblock/Makefile              |   3 +-
tools/testing/memblock/README                |  14 +-
tools/testing/memblock/TODO                  |   5 -
tools/testing/memblock/asm/dma.h             |   6 +
tools/testing/memblock/main.c                |   2 +
tools/testing/memblock/tests/alloc_low_api.c | 148 +++++++++++++++++++
tools/testing/memblock/tests/alloc_low_api.h |   9 ++
tools/testing/memblock/tests/common.c        |   6 +
8 files changed, 180 insertions(+), 13 deletions(-)
delete mode 100644 tools/testing/memblock/TODO
create mode 100644 tools/testing/memblock/tests/alloc_low_api.c
create mode 100644 tools/testing/memblock/tests/alloc_low_api.h
[PATCH v2 0/2] memblock tests: cover low-address allocations
Posted by Tianyi Chen 2 weeks, 4 days ago
Model a low allocation limit within the dummy memory registered with
memblock, then exercise memblock_alloc_low() in both allocation directions.

Changes in v2, following Mike Rapoport's review:
- Clarify why the limit splits MEM_SIZE, the region registered by
  setup_memblock(), rather than the larger PHYS_MEM_SIZE malloc buffer.
- Explain why the malloc-backed base still needs alignment.
- Describe the boundary in terms of the last usable byte and clarify
  that reserving low memory succeeds; the following allocation fails.
- Update Assisted-by tags to the required tool:model format.

No allocator or test behavior changes from v1.

Validation with the existing Makefile and ASan/UBSan enabled:
- Default, NUMA=1, 32BIT_PHYS_ADDR_T=1, 32BIT_PHYS_ADDR_T=1 with NUMA=1,
  and MEMBLOCK_DEBUG=1 with NUMA=1 builds passed.
- Each configuration passed both ./main -v and ./main -v -m.
- A separate BUILD=32 run still hits the pre-existing
  memblock_free_near_max_check assertion in basic_api.c, also seen on
  the baseline. This is distinct from the passing 32-bit physical-address
  configuration above.

v1: https://lore.kernel.org/r/20260906144011.848898-1-hi@tychen.cc
Review: https://lore.kernel.org/r/ap3LTQlKTpDbAEJZ@kernel.org
Review: https://lore.kernel.org/r/ap3NJsaG10rLDVpd@kernel.org

Tianyi Chen (2):
  memblock tests: model the low allocation limit within dummy memory
  memblock tests: cover allocations below the low address limit

 tools/testing/memblock/Makefile              |   3 +-
 tools/testing/memblock/README                |  14 +-
 tools/testing/memblock/TODO                  |   5 -
 tools/testing/memblock/asm/dma.h             |   6 +
 tools/testing/memblock/main.c                |   2 +
 tools/testing/memblock/tests/alloc_low_api.c | 148 +++++++++++++++++++
 tools/testing/memblock/tests/alloc_low_api.h |   9 ++
 tools/testing/memblock/tests/common.c        |   6 +
 8 files changed, 180 insertions(+), 13 deletions(-)
 delete mode 100644 tools/testing/memblock/TODO
 create mode 100644 tools/testing/memblock/tests/alloc_low_api.c
 create mode 100644 tools/testing/memblock/tests/alloc_low_api.h

-- 
2.55.0
Re: [PATCH v2 0/2] memblock tests: cover low-address allocations
Posted by Mike Rapoport 2 weeks, 2 days ago
Hi,

For the future postings, please don't send vN+1 as a reply to vN.

On Mon, Sep 07, 2026 at 09:20:31AM +0800, Tianyi Chen wrote:
> Model a low allocation limit within the dummy memory registered with
> memblock, then exercise memblock_alloc_low() in both allocation directions.
> 
> Changes in v2, following Mike Rapoport's review:
> - Clarify why the limit splits MEM_SIZE, the region registered by
>   setup_memblock(), rather than the larger PHYS_MEM_SIZE malloc buffer.
> - Explain why the malloc-backed base still needs alignment.
> - Describe the boundary in terms of the last usable byte and clarify
>   that reserving low memory succeeds; the following allocation fails.
> - Update Assisted-by tags to the required tool:model format.
> 
> No allocator or test behavior changes from v1.
> 
> Validation with the existing Makefile and ASan/UBSan enabled:
> - Default, NUMA=1, 32BIT_PHYS_ADDR_T=1, 32BIT_PHYS_ADDR_T=1 with NUMA=1,
>   and MEMBLOCK_DEBUG=1 with NUMA=1 builds passed.
> - Each configuration passed both ./main -v and ./main -v -m.
> - A separate BUILD=32 run still hits the pre-existing
>   memblock_free_near_max_check assertion in basic_api.c, also seen on
>   the baseline. This is distinct from the passing 32-bit physical-address
>   configuration above.
> 
> v1: https://lore.kernel.org/r/20260906144011.848898-1-hi@tychen.cc
> Review: https://lore.kernel.org/r/ap3LTQlKTpDbAEJZ@kernel.org
> Review: https://lore.kernel.org/r/ap3NJsaG10rLDVpd@kernel.org
> 
> Tianyi Chen (2):
>   memblock tests: model the low allocation limit within dummy memory
>   memblock tests: cover allocations below the low address limit
> 
>  tools/testing/memblock/Makefile              |   3 +-
>  tools/testing/memblock/README                |  14 +-
>  tools/testing/memblock/TODO                  |   5 -
>  tools/testing/memblock/asm/dma.h             |   6 +
>  tools/testing/memblock/main.c                |   2 +
>  tools/testing/memblock/tests/alloc_low_api.c | 148 +++++++++++++++++++
>  tools/testing/memblock/tests/alloc_low_api.h |   9 ++
>  tools/testing/memblock/tests/common.c        |   6 +
>  8 files changed, 180 insertions(+), 13 deletions(-)
>  delete mode 100644 tools/testing/memblock/TODO
>  create mode 100644 tools/testing/memblock/tests/alloc_low_api.c
>  create mode 100644 tools/testing/memblock/tests/alloc_low_api.h
> 
> -- 
> 2.55.0
> 
> 

-- 
Sincerely yours,
Mike.
Re: [PATCH v2 0/2] memblock tests: cover low-address allocations
Posted by Tianyi Chen 2 weeks, 2 days ago
Hi Mike,

Sorry for sending v2 as a reply to v1. I have posted v3 as a separate
thread:
https://lore.kernel.org/r/cover.1788997523.git.hi@tychen.cc

I shortened the comments and README to describe the low limit and
simulated RAM alignment directly. Both patches now use Assisted-by: LLM.

I also checked the pointer casts with BUILD=32, where pointers are 32-bit
and phys_addr_t is 64-bit. The tested compiler sign-extends a direct cast
to phys_addr_t, while conversion through uintptr_t zero-extends it.
Direct casts also introduce warnings, so I retained uintptr_t to preserve
the existing conversion behavior. There are no executable code changes
from v2.

Thanks for the review,
Tianyi