On Tuesday, August 29, 2017, Chris Brandt wrote:

On Tuesday, August 29, 2017, Nicolas Pitre wrote:

quoted

On Tue, 29 Aug 2017, Chris Brandt wrote:

quoted

On Monday, August 28, 2017, Nicolas Pitre wrote:

quoted

OK I moved the lock promotion right at the beginning _before_

validating

quoted

quoted

the split point. Also got a reference on the file to make sure that
hasn't changed too.

quoted

While we are at it, what happens if you mmap 120Kb, then munmap()

the

quoted

quoted

middle

quoted

40Kb.  Leaving two 40Kb VMAs with 40Kb gap between them, that is.

Will

quoted

quoted

your

quoted

->vm_private_data be correct for both?

It wouldn't, but I now changed it to contain absolute values so now

it

quoted

quoted

quoted

will. And if the split point lands in the hole then the code just
readjusts the pgoff at the beginning of the remaining part.

Here's the revised patch:

For whatever it's worth, as soon as I moved to 4.13-rc7,
CONFIG_CRAMFS_PHYSMEM=y crashes my XIP_KERNEL system before it can

even

quoted

quoted

get to any console output.

(both the old patch and the new patch)

If CONFIG_CRAMFS_PHYSMEM is not set, my XIP system boots fine.

However, if I boot -rc7 as a uImage, the new patch works just as good

as

quoted

quoted

the old patch.

When not a uImage, do you mean by that a XIP kernel?

Yes, CONFIG_XIP_KERNEL.

quoted

If so you should
know by now from that other thread on LAK that the XIP linker script is
broken and probably just worked by luck till now. Still, if you could
bisect between -rc4 and -rc7 and pinpoint the change that makes it not
work that would be better than speculations.

Note that everything else seem OK when CONFIG_XIP_KERNEL=y. It's just
when CONFIG_XIP_KERNEL=y CONFIG_CRAMFS_PHYSMEM=y which is odd. So
hopefully
that means it will be easy to track down.

Update:

My issue was caused by the XIP linker script (vmlinux-xip.lds.S).

Therefore, by applying the following patch series from the 
linux-arm-kernel mailing list, my system could boot normally.

 [PATCH v2 0/5] make XIP kernel .data compressed in ROM
 [PATCH v2 1/5] ARM: head-common.S: speed up startup code
 [PATCH v2 2/5] ARM: vmlinux*.lds.S: some decruftification
 [PATCH v2 3/5] ARM: vmlinux.lds.S: replace open coded .data sections with generic macros
 [PATCH v2 4/5] ARM: vmlinux-xip.lds.S: fix multiple issues
 [PATCH v2 5/5] ARM: XIP kernel: store .data compressed in ROM


Now that I could boot again, this cramfs series of patches operates as 
designed.

Notice that busybox, libc and ld have physical addresses in Flash (ie, XIP)

$ cat /proc/self/maps
00008000-000a1000 r-xp 1b005000 00:0c 18192      /bin/busybox
000a9000-000aa000 rw-p 00099000 00:0c 18192      /bin/busybox
000aa000-000ac000 rw-p 00000000 00:00 0          [heap]
b6eed000-b6fc6000 r-xp 1b0bc000 00:0c 766540     /lib/libc-2.18-2013.10.so
b6fc6000-b6fce000 ---p 1b195000 00:0c 766540     /lib/libc-2.18-2013.10.so
b6fce000-b6fd0000 r--p 000d9000 00:0c 766540     /lib/libc-2.18-2013.10.so
b6fd0000-b6fd1000 rw-p 000db000 00:0c 766540     /lib/libc-2.18-2013.10.so
b6fd1000-b6fd4000 rw-p 00000000 00:00 0
b6fd4000-b6feb000 r-xp 1b0a4000 00:0c 670372     /lib/ld-2.18-2013.10.so
b6fee000-b6fef000 rw-p 00000000 00:00 0
b6ff0000-b6ff2000 rw-p 00000000 00:00 0
b6ff2000-b6ff3000 r--p 00016000 00:0c 670372     /lib/ld-2.18-2013.10.so
b6ff3000-b6ff4000 rw-p 00017000 00:0c 670372     /lib/ld-2.18-2013.10.so
bee27000-bee48000 rw-p 00000000 00:00 0          [stack]
beea4000-beea5000 r-xp 00000000 00:00 0          [sigpage]
ffff0000-ffff1000 r-xp 00000000 00:00 0          [vectors]



Tested-by: Chris Brandt <chris.brandt@renesas.com>