From: Pluto Yang Date: Wed, 1 Jul 2026 12:57:14 +0000 (+0800) Subject: test: fix incorrect hole count reporting on loongarch64 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=22af22edb8a45754bbb77784c347afb78d615d48;p=thirdparty%2Flibarchive.git test: fix incorrect hole count reporting on loongarch64 On LoongArch64 with 16KB pages, Linux tmpfs often uses Transparent Huge Pages (THP) sized at 32MiB. When a test writes data followed by a 32MiB hole, the kernel may allocate a single huge page folio to back the entire range in RAM. Because the range is physically backed by memory, SEEK_HOLE correctly (from the kernel's perspective) identifies the range as DATA, failing the test's assertion. Increasing MIN_HOLE to 64MiB ensures the hole exceeds the huge page size on loongarch64, preserving the sparse nature of the file for the test. Signed-off-by: Pluto Yang --- diff --git a/libarchive/test/test_sparse_basic.c b/libarchive/test/test_sparse_basic.c index 3914c3e30..135bcefeb 100644 --- a/libarchive/test/test_sparse_basic.c +++ b/libarchive/test/test_sparse_basic.c @@ -73,10 +73,16 @@ static void create_sparse_file(const char *, const struct sparse *); /* A few data points: * = ZFS on FreeBSD needs this to be at least 200kB * = macOS APFS needs this to be at least 4096x4097 bytes + * = Linux tmpfs on 16KB-page architectures (like LoongArch64) uses + * 32MiB Transparent Huge Pages (THP). If a hole is exactly the + * size of a THP, the data blocks on either side can end up in + * adjacent physical folios, causing SEEK_HOLE to report the range + * as contiguous data. * - * 32MiB here is bigger than either of the above. + * 64MiB here is enough to ensure a hole exists between THP folios on all + * common architectures. */ -#define MIN_HOLE (32 * 1024UL * 1024UL) +#define MIN_HOLE (64 * 1024UL * 1024UL) #if defined(_WIN32) && !defined(__CYGWIN__) #include