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

Document created by Aaronwu Employee on Sep 3, 2013
Version 1Show Document
  • View in full screen mode

[#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

Blackfin support (C) 2004-2009 Analog Devices, Inc.^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

^M

Have a lot of fun...^M

^M

^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

^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

    Tags

 

File Name     File Type     File Size     Posted By

config.mpu    application/octet-stream    32731    Vivi Li

03&05_crash_log    application/octet-stream    9881    Vivi Li

Attachments

Outcomes