[#5153] mmap3/5/6/7/9 test fails for bf537 mpu

Submitted By: Vivi Li

Open Date

2009-05-20 23:45:22 Close Date

2009-08-11 23:23:57

Priority:

Medium Assignee:

Graf Yang

Status:

Closed Fixed In Release:

N/A

Found In Release:

N/A Release:

Category:

Tests Board:

N/A

Processor:

BF537 Silicon Revision:

bf537 0.3

Is this bug repeatable?:

Yes Resolution:

Fixed

Uboot version or rev.:

Toolchain version or rev.:

gcc4.1-09r1_rc6

App binary format:

N/A

Summary: mmap3/5/6/7/9 test fails for bf537 mpu

Details:

mmap5/6/7/9 tests fail for bf537 MPU.

Test script is in directory uclinux-dist/testsuites/mpu.

Linux version 2.6.28.10-ADI-2009R1-pre-svn6363 (test@uclinux74-mpu) (gcc

version 4.1.2 (ADI svn)) #134 Mon May 18 17:41:29 GMT 2009^M

console [early_BFuart0] enabled^M

early printk enabled on early_BFuart0^M

Board Memory: 64MB^M

Kernel Managed Memory: 64MB^M

Memory map:^M

fixedcode = 0x00000400-0x00000490^M

text = 0x00001000-0x001031a0^M

rodata = 0x001031a0-0x001545a8^M

bss = 0x00155000-0x001666a8^M

data = 0x001666a8-0x00178000^M

stack = 0x00176000-0x00178000^M

init = 0x00178000-0x008c4000^M

available = 0x008c4000-0x03eff000^M

DMA Zone = 0x03f00000-0x04000000^M

Hardware Trace Active and Enabled^M

Boot Mode: 0^M

Reset caused by Software reset^M

Compiled for ADSP-BF537 Rev 0.3^M

Blackfin Linux support by http://blackfin.uclinux.org/^M

Processor Speed: 500 MHz core clock and 100 MHz System Clock^M

MPU: setting up cplb tables with memory protection^M

Instruction Cache Enabled for CPU0^M

Data Cache Enabled for CPU0 (write-back)^M

Built 1 zonelists in Zone order, mobility grouping off. Total pages: 16001^M

Kernel command line: root=/dev/mtdblock0 rw earlyprintk=serial,uart0,57600

ip=10.100.4.50:10.100.4.174:192.168.0.1:255.255.255.0:bf537-stamp:eth0:off^M

Configuring Blackfin Priority Driven Interrupts^M

PID hash table entries: 256 (order: 8, 1024 bytes)^M

console handover: boot [early_BFuart0] -> real [ttyBF0]^M

Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)^M

Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)^M

Memory available: 51652k/65536k RAM, (7472k init code, 1032k kernel code, 468k

data, 1024k dma, 3884k reserved)^M

Calibrating delay loop... 997.37 BogoMIPS (lpj=1994752)^M

Security Framework initialized^M

Mount-cache hash table entries: 512^M

Blackfin Scratchpad data SRAM: 4 KB^M

Blackfin L1 Data A SRAM: 16 KB (15 KB free)^M

Blackfin L1 Data B SRAM: 16 KB (16 KB free)^M

Blackfin L1 Instruction SRAM: 48 KB (38 KB free)^M

PDA for CPU0 reserved at 00158000^M

net_namespace: 288 bytes^M

NET: Registered protocol family 16^M

Blackfin DMA Controller^M

stamp_init(): registering device resources^M

NET: Registered protocol family 2^M

IP route cache hash table entries: 1024 (order: 0, 4096 bytes)^M

TCP established hash table entries: 2048 (order: 2, 16384 bytes)^M

TCP bind hash table entries: 2048 (order: 1, 8192 bytes)^M

TCP: Hash tables configured (established 2048 bind 2048)^M

TCP reno registered^M

NET: Registered protocol family 1^M

msgmni has been set to 100^M

io scheduler noop registered^M

io scheduler anticipatory registered (default)^M

io scheduler cfq registered^M

Serial: Blackfin serial driver^M

bfin-uart.1: ttyBF0 at MMIO 0xffc00400 (irq = 18) is a BFIN-UART^M

brd: module loaded^M

bfin_mii_bus: probed^M

bfin_mac: attached PHY driver [SMSC LAN83C185] (mii_bus:phy_addr=0:01, irq=-1,

mdc_clk=2500000Hz(mdc_div=19)@sclk=100MHz)^M

bfin_mac bfin_mac.0: Blackfin on-chip Ethernet MAC driver, Version 1.1^M

bfin-spi bfin-spi.0: Blackfin on-chip SPI Controller Driver, Version 1.0,

regs_base@ffc00500, dma channel@7^M

rtc-bfin rtc-bfin: rtc core: registered rtc-bfin as rtc0^M

bfin-wdt: initialized: timeout=20 sec (nowayout=0)^M

TCP cubic registered^M

NET: Registered protocol family 17^M

rtc-bfin rtc-bfin: setting system clock to 2004-05-31 06:33:36 UTC

(1085985216)^M

IP-Config: Gateway not on directly connected network.^M

dma_alloc_init: dma_page @ 0x03ad7000 - 256 pages at 0x03f00000^M

PHY: 0:01 - Link is Up - 100/Full^M

_____________________________________^M

a8888b. / Welcome to the uClinux distribution \^M

d888888b. / _ _ \^M

8P"YP"Y88 / | | |_| __ __ (TM)

|^M

8|o||o|88 _____/ | | _ ____ _ _ \ \/ / |^M

8' .88 \ | | | | _ \| | | | \ / |^M

8`._.' Y8. \ | |__ | | | | | |_| | / \ |^M

d/ `8b. \ \____||_|_| |_|\____|/_/\_\ |^M

dP . Y8b. \ For embedded processors including |^M

d8:' " `::88b \ the Analog Devices Blackfin /^M

d8" 'Y88b \___________________________________/^M

:8P ' :888^M

8a. : _a88P For further information, check out:^M

._/"Yaa_: .| 88P| - http://blackfin.uclinux.org/^M

\ YP" `| 8P `. - http://docs.blackfin.uclinux.org/^M

/ \.___.d| .' - http://www.uclinux.org/^M

`--..__)8888P`._.' jgs/a:f - http://www.analog.com/blackfin^M

Have a lot of fun...^M

BusyBox v1.13.4 (2009-05-18 17:00:37 GMT) built-in shell (msh)^M

Enter 'help' for a list of built-in commands.^M

root:/>

root:/> echo "nobody:x:1:1:nobody:/:/bin/sh" >>

/etc/passwd^M

root:/> cd /bin

root:/bin> ./mmap05^M

mmap05 1 FAIL : Mapped memory region with NO access is accessible^M

root:/bin> ^M

root:/bin> ./mmap06^M

mmap06 1 FAIL : mmap() returned invalid value, expected: -1^M

root:/bin> ^M

root:/bin> ./mmap07^M

mmap07 1 FAIL : mmap() returned invalid value, expected: -1^M

root:/bin> ^M

root:/bin> ./mmap09^M

mmap09 1 FAIL : ftruncate mmaped file to a smaller size - errnor: 26^M

mmap09 2 PASS : ftruncate mmaped file to a larger size^M

mmap09 3 FAIL : ftruncate mmaped file to 0 size - errnor: 26^M

root:/bin> ^M

Follow-ups

--- Bernd Schmidt 2009-05-28 08:44:43

Are any of these new failures? I just tried one of them on a really old no-mpu

kernel and it failed in the same way.

What are the results on 08r1?

mmap is expected to behave somewhat differently on nommu systems.

--- Sonic Zhang 2009-05-31 00:59:16

All these mmap tests on mpu are new cases for 09R1 release. They have never

passed. And delayed till now for the same reason of XIP in mpu bug.

--- Bernd Schmidt 2009-06-15 05:48:48

If they fail in the same way on nompu, could you close this bug?

--- Sonic Zhang 2009-06-15 06:42:03

This cases are MPU specific.

--- Bernd Schmidt 2009-06-17 05:47:50

What do you mean, MPU specific?

I've run some of these tests on an (older) nompu kernel and they fail in

exactly the same way:

root:/> ./a.out

mmap09 1 FAIL : ftruncate mmaped file to a smaller size - errnor: 26

mmap09 2 PASS : ftruncate mmaped file to a larger size

mmap09 3 FAIL : ftruncate mmaped file to 0 size - errnor: 26

root:/> uname -a

Linux blackfin 2.6.24.4-ADI-2008R2-pre-svn4647 #573 Sat May 17 01:03:15 CEST

2008 blackfin unknown

Which suggests to me that we're simply dealing with limitations of nommu mmap

here rather than any bug related to MPU. It's certainly not a regression.

--- Graf Yang 2009-07-07 05:34:17

Under NOMPU, mmap06/07 shoud pass, mmap05 can't pass.

Under MPU, mmap05/06/07 should pass, now is fixed on branch.

mmap09 should not pass(both NOMPU and MPU), because nommu can't truncate a file

that has been mmaped with VM_SHARED.

--- Graf Yang 2009-07-07 05:39:58

Reading code of trunk kernel.

--- Robin Getz 2009-07-07 11:25:23

So, if mmap09 depends on virtual memory - why is it getting built with for

noMMU?

-Robin

--- Mike Frysinger 2009-07-07 13:54:38

i cant think of a reason why using truncate to shrink a mapping wouldnt work.

the application was already granted the memory in question so freeing some of

the tail end of it should in theory work fine.

i can understand trying to enlarge a mapping failing -- the memory right after

the mapping may not be available.

--- Graf Yang 2009-07-07 23:18:49

We can not free any of the memory on tail, because it is mmap()ed with

MAP_SHARED. There may other processes accessing this area.

Enlarge maybe OK, if there is freeing memory right after the mapping.

--- Mike Frysinger 2009-07-08 01:35:01

my understanding is it shouldnt matter. we can shrink all the mappings at the

same time. if one app does a truncate while another is trying to access it,

that is a bug in the application, not the kernel.

i presume the test passes fine on your desktop.

--- Graf Yang 2009-07-08 02:08:30

Yes, it can passes on my desktop.

The branch kernel seems deny to truncate the file by intention in such cases.

--- Mike Frysinger 2009-07-09 04:10:06

the code in question is fs/ramfs/file-nommu.c:ramfs_nommu_resize()

it explicitly denies all attempts to shrink a mapping if it is made with

MAP_SHARED. but doesnt provide any reason for why it wants to do this.

removing this code allows mmap09 to pass on my system. ive sent an e-mail to

lkml asking for reasoning behind this check. it could simply be a mistake.

btw, this behavior crashes as you'd expect on a mmu -- create a file, map it

with MAP_SHARED, truncate it, and then try to access beyond the truncation -- it

crashes. so while we may not get crashes on a no-mpu system, we should on a mpu

system. this is still buggy userspace code and we shouldnt be protecting

against it.

--- Graf Yang 2009-07-09 05:56:37

Thanks for your message!

Seems vmtruncate() have been ready to handle the truncate work.

--- Vivi Li 2009-07-13 04:42:21

Current status of mmap test has changed: mmap03/05 crashed and mmap02/4/6/7/8

passed.

This happened between following two versions:

kernel: Linux release 2.6.28.10-ADI-2009R1-svn6925, build #16 Mon Jul 6

19:25:53 GMT 2009

toolchain: bfin-uclinux-gcc release gcc version 4.1.2 (ADI svn)

user-dist: release svn-8431, build #246 Mon Jul 6 19:25:14 GMT 2009

kernel: Linux release 2.6.28.10-ADI-2009R1-svn6958, build #4 Fri Jul 10

17:29:16 GMT 2009^M

toolchain: bfin-uclinux-gcc release gcc version 4.1.2 (ADI svn)^M

user-dist: release svn-8476, build #36 Fri Jul 10 17:28:34 GMT 2009^M

root:/> mmap02

mmap02 1 PASS : Functionality of mmap() successful

root:/> mmap04

mmap04 1 PASS : Functionality of mmap() successful

root:/> mmap06

mmap06 1 PASS : mmap() fails, 'fd' doesn't allow desired access,

errno:13

root:/> mmap08

mmap08 1 PASS : mmap() fails, 'fd' is not valid, errno:9

root:/> mmap07

mmap07 1 PASS : mmap() fails, 'fd' doesn't allow desired access,

errno:13

Complete crash log is attached. Bellow is the abbreviated log:

root:/> mmap03

Data access CPLB protection violation

- Attempted read or write to Supervisor resource,

or illegal data memory access.

Deferred Exception context

CURRENT PROCESS:

COMM=mmap03 PID=171

CPU = 0

TEXT = 0x032a0040-0x032ab320 DATA = 0x032ab340-0x032ae080

BSS = 0x032ae080-0x032b3000 USER-STACK = 0x032bbf84

(...)

root:/>

root:/> mmap05

Data access CPLB protection violation

- Attempted read or write to Supervisor resource,

or illegal data memory access.

Deferred Exception context

CURRENT PROCESS:

COMM=mmap05 PID=172

CPU = 0

TEXT = 0x032a0040-0x032ab280 DATA = 0x032ab2a0-0x032adf8c

BSS = 0x032adf8c-0x032b2f00 USER-STACK = 0x032baf84

(...)

--- Graf Yang 2009-07-24 03:52:12

mmap05 have been fixed yesterday.

mmap03: we need add a patch to mmap03.c

Index: testcases/kernel/syscalls/mmap/mmap03.c

===================================================================

--- testcases/kernel/syscalls/mmap/mmap03.c (revision 153)

+++ testcases/kernel/syscalls/mmap/mmap03.c (working copy)

@@ -172,7 +172,7 @@

"Functionality of mmap() successful");

}

-#if defined(__ia64__) || defined(__hppa__)

+#if defined(__ia64__) || defined(__hppa__) || defined(UCLINUX)

if (pass) {

tst_resm(TPASS, "Got SIGSEGV as

expected");

} else {

Then it can pass on MPU,

root:/> ./mmap031

...

... crash info ...

...

mmap03 1 PASS : Got SIGSEGV as expected

Under NOMPU, because we not have mm protection,

root:/> ./mmap031

mmap03 1 PASS : Functionality of mmap() successful

mmap03 2 FAIL : Mapped memory region with NO access is accessible

--- Vivi Li 2009-08-12 04:24:12

OK now. Close it.

Files

Changes

Commits

Dependencies

Duplicates

Associations