[LTP] [PATCH] syscalls/mmap17.c: Add new regression test
Jan Stancek
jstancek@redhat.com
Tue Feb 6 22:15:00 CET 2018
----- Original Message -----
>
>
> ----- Original Message -----
> > > The patch you referenced is x86 specific, so we can restrict the test to
> > > x86.
> > > Also please set the minimum kernel version this is expected to fail on.
> > 1) Before commit c64b04f, we couldn't read phys_addr_bits from
> > /proc/cpuinfo in 32-bit kernel on x86.
> > 2) On non-x86 architectures, we couldn't read phys_addr_bits from
> > /proc/cpuinfo as well.
> >
> > According to above reasons, i perfer to check phys_addr_bits in
> > /proc/cpuinfo rather than the minimum
> > kernel version and x86 architecture. We can skip this test if
> > phys_addr_bits isn't available.
>
> I was referring to kernel patch. Does it make sense for this test
> to run on older kernels? Based on description it might crash, so
> presumably yes.
Though you need to be root and write to /dev/mem - which seems
like very rare use-case.
>
> But do we also want to report FAIL on older kernels if mmap succeeds?
> That does not violate any docs.
>
> > addr[0] = 'a';
> If mmap works, this has potential of triggering signal,
> which will lead to TBROK.
older kernels with lot of DEBUG options can survive:
# uname -r
3.10.0-810.el7.x86_64.debug
# ./mmap17
tst_test.c:980: INFO: Timeout per run is 0h 05m 00s
a1
tst_test.c:1020: INFO: If you are running on slow machine, try exporting LTP_TIMEOUT_MUL > 1
tst_test.c:1021: BROK: Test killed! (timeout?)
Summary:
passed 0
failed 0
skipped 0
warnings 0
I'd limit it to 4.14 and later - I'm assuming most people won't care
about this bug and we can ignore all outcomes from older kernels.
What do you think?
Regards,
Jan
More information about the ltp
mailing list