From mboxrd@z Thu Jan  1 00:00:00 1970
From: fixed-term.Oleksij.Rempel@de.bosch.com (fixed-term.Oleksij.Rempel)
Date: Thu, 19 May 2016 11:22:43 +0200
Subject: arm64: unhandled level 3 permission fault on ltp mmap16 test
In-Reply-To: <573D83E9.90706@arm.com>
References: <573D5073.1050508@de.bosch.com> <573D83E9.90706@arm.com>
Message-ID: <573D85E3.3090408@de.bosch.com>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org



On 19.05.2016 11:14, Suzuki K Poulose wrote:
> On 19/05/16 06:34, fixed-term.Oleksij.Rempel wrote:
>> Hallo all,
>>
>> if i run latest ltp tests on any of latest kernel version i get
>> fallowing warning:
>>
>> root at rcar1:/opt/ltp# dmesg
>> root at rcar1:/opt/ltp# ./testcases/bin/mmap16
>> mmap16      0  TINFO  :  Found free device '/dev/loop0'
>> mmap16      0  TINFO  :  Formatting /dev/loop0 with ext4 opts='-b 1024'
>> extra opts='10240'
>> mke2fs 1.43-WIP (15-Mar-2016)
>> [  889.736679] EXT4-fs (loop0): mounted filesystem with ordered data
>> mode. Opts: nodelalloc
>> [  889.843995] mmap16[2164]: unhandled level 3 permission fault (7) at
>> 0x7f8397d400, esr 0x9200004f
> 
> IIRC, this is expected. The test performs the access on purpose. It spawns
> a child which does this access and expects SIGBUS to be delivered to it.
> The
> parent makes sure that the SIGBUS is delivered to by wait()-ing for it.
> 
> See :
>                 /*
>                  * If child process was killed by SIGBUS, bug is not
> reproduced.
>                  */
>                 if (!WIFSIGNALED(status) || WTERMSIG(status) != SIGBUS) {
>                         tst_brkm(TBROK | TERRNO, cleanup,
>                                  "child process terminate unexpectedly");
>                 }
> 
>>
>> Can some one please help me to understand this? If i see it correctly,
>> some thing wrong happened by level 3 address translation. But i have no
>> idea how to solve it (if it should be solved)
> 
> On arm64 we print unhandled faults to give enough information to debug the
> problem, which is why you see those messages in dmesg.
> 
> So, you can ignore those messages as long as the faults are generated by
> mmap16 and thetest reports success.

OK, thank you!