From mboxrd@z Thu Jan  1 00:00:00 1970
From: Xiao Yang <yangx.jy@cn.fujitsu.com>
Date: Wed, 7 Feb 2018 20:05:30 +0800
Subject: [LTP] [PATCH] syscalls/mmap17.c: Add new regression test
In-Reply-To: <1808841957.523089.1517951700941.JavaMail.zimbra@redhat.com>
References: <1517565794-1769-1-git-send-email-yangx.jy@cn.fujitsu.com>
 <1069626938.5781132.1517566821086.JavaMail.zimbra@redhat.com>
 <5A7835B2.9030406@cn.fujitsu.com>
 <940714833.169417.1517830921395.JavaMail.zimbra@redhat.com>
 <5A794E19.3000201@cn.fujitsu.com>
 <195340110.511328.1517946794955.JavaMail.zimbra@redhat.com>
 <1808841957.523089.1517951700941.JavaMail.zimbra@redhat.com>
Message-ID: <5A7AEB8A.90509@cn.fujitsu.com>
List-Id: <ltp.lists.linux.it>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: ltp@lists.linux.it

On 2018/02/07 5:15, Jan Stancek wrote:
>
> ----- 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?
Hi Jan,

Thanks for your comment.  :-)

With 3.10.0-830.el7.x86_64 and 2.6.32-696.el6.x86_64, this case can trigger a crash easily,
so i want to run it on older kernels.  But, we can ignore all outcomes from older kernels
as you said.

If an invalid physical address was refused by mmap() or didn't trigger a crash, can we think
the bug didn't exist due to some protection mechanisms?

Please see the following code:
--------------------------------------------------------------------
static void verify_mmap(void)
{
         char *addr;

         addr = mmap(NULL, 1, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 1ULL<<phys_addr_bits);
         if (addr == MAP_FAILED)
                 exit(0);

         addr[0] = 'a';
         SAFE_MUNMAP(addr, 1);
         exit(1);
}

static void do_mmap(void)
{
         pid_t pid;
         int status;

         pid = SAFE_FORK();
         if (!pid)
                 verify_mmap();

         SAFE_WAITPID(pid,&status, 0);
         if (WIFEXITED(status)&&  !WEXITSTATUS(status))
                 tst_res(TPASS, "Refused to map invalid physical address");
         else
                 tst_res(TPASS, "Mapped invalid physical address didn't trigger a crash");
}
--------------------------------------------------------------------

Thanks,
Xiao Yang

> Regards,
> Jan
>
>
>