Re: [PATCH 4/6] test: dm: part: Check the GPT layout for large sector sizes

Hello Heinrich,

On Wed, Aug 26, 2026 at 12:36 AM Heinrich Schuchardt
<[email protected]> wrote:
>
> On 7/31/26 14:40, Alexey Charkov wrote:
> > Add a test that runs gpt_fill_header() and gpt_fill_pte() over a range of
> > block sizes and checks that the partition entry array is sized and placed
> > consistently, in particular that the backup array ends exactly where the
> > backup GPT header begins.
> >
> > Neither function performs any block I/O, so the test builds a synthetic
> > struct blk_desc rather than needing a block device with a configurable
> > block size. The expected array size is taken from the GPT header fields
> > rather than from GPT_ENTRY_NUMBERS, so the test still holds for builds
> > with a non-default CONFIG_EFI_PARTITION_ENTRIES_NUMBERS, such as
> > ARCH_SUNXI with 56 entries.
> >
> > Without the preceding fixes this fails on the first block size other than
> > 512:
> >
> >    test/dm/part.c:313, dm_test_part_gpt_blksz():
> >        entry_lba + pte_blks == first_lba: Expected 0x12 (18), got 0x22 (34)
> >
> > Signed-off-by: Alexey Charkov <[email protected]>
>
> Thank you for providing the new test.
>
> test/dm/part.c is never tested in the CI on big-endian systems as it is
> restricted to the sandbox.
>
> The sandbox restriction arises because test/dm/part.c relies on MMC
> drives emulated on the sandbox. We should instead create memory backed
> BLKMAP devices. Then we can run the partition table tests on QEMU and on
> real hardware.
>
> For your new test I would suggest to simply move it to a new file in
> test/lib/ as it does not rely on the presence of block devices.

Thanks for the suggestion - I moved it in v2 and it works fine.

Regarding the other point: memory backed blkmap currently supports
only 512-byte sectors. Therefore, in v2 I added a blkmap-based test in
addition to the sandbox-based one (rather than replacing it), and they
exercise different edge cases. The blkmap-based test runs on malta64
catching endianness bugs and validating host block reads, while the
sandbox-based test exercises an externally generated spec-compliant
GPT image to ensure we aren't just being tautological.

Hope this sounds good.

Best regards,
Alexey