[LTP] [PATCH v2] Migrating the libhugetlbfs/testcases/truncate_above_4GB.c test

[Geetika M]

Hello Richard,

On 30/11/23 2:33 pm, Richard Palethorpe wrote:
> Hello,
>
> Geetika<geetika@linux.ibm.com>  writes:
>
....
>> +/*\
>> + *[Descripiton]
>> + *
>> + * At one stage, a misconversion of hugetlb_vmtruncate_list to a
>> + * prio_tree meant that on 32-bit machines, truncates at or above 4GB
>> + * could truncate lower pages, resulting in BUG_ON()s.
>> + *
>> + * WARNING: The offsets and addresses used within are specifically
>> + * calculated to trigger the bug as it existed.  Don't mess with them
>> + * unless you *really* know what you're doing.
>> + *
>> + */
>> +
>> +#define _GNU_SOURCE
>> +#define _LARGEFILE64_SOURCE
>> +#define FOURGIG ((off64_t)0x100000000ULL)
>> +#define MNTPOINT "hugetlbfs/"
>> +
>> +#include <signal.h>
>> +#include <setjmp.h>
>> +#include "hugetlb.h"
>> +
>> +static int page_size;
>> +static long hpage_size;
>> +static int fd = -1;
>> +static volatile int test_pass;
>> +static int err;
>> +static int sigbus_count;
>> +static sigjmp_buf sig_escape;
>> +
>> +static void sigbus_handler_fail(int signum, siginfo_t *si, void *uc)
>> +{
>> +	siglongjmp(sig_escape, 17);
>> +}
>> +
>> +static void sigbus_handler_pass(int signum, siginfo_t *si, void *uc)
>> +{
>> +	test_pass = 1;
>> +	siglongjmp(sig_escape, 17);
>> +}
>> +
>> +static void run_test(void)
>> +{
>> +	long long buggy_offset, truncate_point;
>> +	void *p, *q;
>> +	volatile unsigned int *pi, *qi;
>> +
>> +	struct sigaction sa_pass = {
>> +		.sa_sigaction = sigbus_handler_pass,
>> +		.sa_flags = SA_SIGINFO,
>> +	};
>> +
>> +	struct sigaction sa_fail = {
>> +		.sa_sigaction = sigbus_handler_pass,
>> +		.sa_flags = SA_SIGINFO,
>> +	};
>> +
>> +	sigbus_count = 0;
>> +	test_pass = 0;
>> +
>> +	buggy_offset = truncate_point / (hpage_size / page_size);
>> +	buggy_offset = PALIGN(buggy_offset, hpage_size);
>> +
>> +	/* First get arena of three hpages size, at file offset 4GB */
>> +	q = mmap64(NULL, 3*hpage_size, PROT_READ|PROT_WRITE,
>> +		 MAP_PRIVATE, fd, truncate_point);
>> +	if (q == MAP_FAILED)
>> +		tst_brk(TBROK, "mmap() offset 4GB: %s", strerror(errno));
> In musl mmap64 is just defined as mmap or not at all if _GNU_SOURCE is
> absent. So do we really need it? It seems likely to cause compilation
> failures.
>
> Instead we could just use SAFE_MMAP.
>
> Same goes for truncate64 etc.
>
> There are a lot of warnings when compiling this, we don't want to
> introduce more warnings.
>
The "mmap64" function is used instead of "mmap" in this test because it 
allows for mapping memory from files that are larger than 2 gigabytes 
into the process memory.

In a 64-bit system, "mmap" and "mmap64" might behave the same way. 
However, the key difference lies in the offset parameter. The "mmap" 
function uses "off_t" type for the offset parameter, which is a 32-bit 
type on some systems, limiting the file size to 2GB. On the other hand, 
"mmap64" uses "off64_t" for the offset parameter, which is a 64-bit 
type, allowing for larger file sizes.

This test case is for 32bit systems. On a 32-bit system, mmap and mmap64 
serve similar purposes, but mmap64 is specifically designed to handle 
files larger than 2GB.  In test program we are mapping at file offset 
4GB  so we should use mmap64 with _LARGEFILE64_SOURCE macro. 
_LARGEFILE64_SOURCE is already defined in the test program so on 32bit 
systems it will take mmap64 path not mmap path.

Hence we cannot use SAFE_MMAP here.

I can work on fixing warnings related to unused parameters.

Are there any other warnings that you see with this code?

Thanks & Regards,
Geetika