[LTP] LTP release preparations

[Li Wang]

Hi Cyril,

On Tue, May 9, 2023 at 5:34 PM Cyril Hrubis <chrubis@suse.cz> wrote:

> Hi!
> > > More widely LTP pre-release test will be deployed base on RHEL products
> > > as well.
> > >
> >
> > I have completed the LTP pre-release test against RHEL 8 and 9,
> > all looks good except one test warning as below, but I suppose
> > it's a tiny problem caused by the ppc64le configuration.
> >
> > This only observed on ppc64le arch:
> >
> > 3 cmdline="hugemmap32"
> >
> >      4        contacts=""
> >      5        analysis=exit
> >      6        <<<test_output>>>
> >      7        tst_test.c:1558: TINFO: Timeout per run is 0h 01m 00s
> >      8        hugemmap32.c:34: TWARN: Failed to close FILE
> > '/sys/kernel/mm/hugepages/hugepages-16777216kB/nr_hugepages'
> >      9        hugemmap32.c:35: TCONF: Can't update the gigantic
> hugepages.
> >
> > 10 hugemmap32.c:69: TWARN: Failed to close FILE
> > '/sys/kernel/mm/hugepages/hugepages-16777216kB/nr_hugepages': EINVAL (22)
>
> Looking at the file_printf() the test uses it does produce a warning
> when we fail to write to the file.
>
> Also we seems to be using FILE_PRINTF() exactly in these tests:
>
> testcases/kernel/device-drivers/cpufreq/cpufreq_boost.c
> testcases/kernel/mem/hugetlb/hugemmap/hugemmap32.c
> testcases/kernel/mem/hugetlb/hugeshmget/hugeshmget03.c
> testcases/kernel/syscalls/fcntl/fcntl33.c
> testcases/kernel/syscalls/readahead/readahead02.c
>
> In three cases we use the FILE_PRINTF() in the test cleanup, which does
> not matter, since we do not break test on TBROK when we run in the test
> cleanup.
>
> That leaves us just hugemmap32 and readahead02 in both cases I think
> that generating TWARN in just plain wrong.
>
> So what about:
>
> * changing FILE_PRINTF() to SAFE_FILE_PRINTF() in test cleanup
> * changing TWARN to TINFO in FILE_PRINTF()
>
> I guess that we should have been using TINFO in the file_fprintf() from
> the start.
>

Yes, sure. I think this will be better for the FILE_PRINTF macro use.
Should we change that in a separate patch after the release?

But, I suppose that we still need to check the available memory in
hugemmap32, because that might be the reason, is unable to
write to the '.../nr_hugepages' file even with zero.

# cat /sys/kernel/mm/hugepages/hugepages-16777216kB/nr_hugepages
0

# echo 0 >/sys/kernel/mm/hugepages/hugepages-16777216kB/nr_hugepages
-bash: echo: write error: Invalid argument

-- 
Regards,
Li Wang