Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1723776
| From | Chris Brandt <Chris.Brandt@renesas.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | RE: [PATCH v2 4/5] cramfs: add mmap support |
| Date | 2017-08-31 04:40 +0200 |
| Message-ID | <uknyG-8ei-5@gated-at.bofh.it> (permalink) |
| References | (3 earlier) <ujsqL-6aY-33@gated-at.bofh.it> <ujtd9-6G2-43@gated-at.bofh.it> <ujxJM-13g-13@gated-at.bofh.it> <ujUwG-6Me-27@gated-at.bofh.it> <ujUZI-7cl-13@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Tuesday, August 29, 2017, Chris Brandt wrote: > On Tuesday, August 29, 2017, Nicolas Pitre wrote: > > On Tue, 29 Aug 2017, Chris Brandt wrote: > > > > > On Monday, August 28, 2017, Nicolas Pitre wrote: > > > > OK I moved the lock promotion right at the beginning _before_ > > validating > > > > the split point. Also got a reference on the file to make sure that > > > > hasn't changed too. > > > > > > > > > While we are at it, what happens if you mmap 120Kb, then munmap() > > the > > > > middle > > > > > 40Kb. Leaving two 40Kb VMAs with 40Kb gap between them, that is. > > Will > > > > your > > > > > ->vm_private_data be correct for both? > > > > > > > > It wouldn't, but I now changed it to contain absolute values so now > it > > > > 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 > > > 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 > > > the old patch. > > > > When not a uImage, do you mean by that a XIP kernel? > > Yes, CONFIG_XIP_KERNEL. > > > 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>
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
Re: [PATCH v2 4/5] cramfs: add mmap support Al Viro <viro@ZenIV.linux.org.uk> - 2017-08-28 08:50 +0200
Re: [PATCH v2 4/5] cramfs: add mmap support Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-08-28 15:40 +0200
Re: [PATCH v2 4/5] cramfs: add mmap support Al Viro <viro@ZenIV.linux.org.uk> - 2017-08-28 16:30 +0200
Re: [PATCH v2 4/5] cramfs: add mmap support Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-08-28 21:20 +0200
RE: [PATCH v2 4/5] cramfs: add mmap support Chris Brandt <Chris.Brandt@renesas.com> - 2017-08-29 21:40 +0200
RE: [PATCH v2 4/5] cramfs: add mmap support Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-08-29 22:10 +0200
RE: [PATCH v2 4/5] cramfs: add mmap support Chris Brandt <Chris.Brandt@renesas.com> - 2017-08-29 22:20 +0200
RE: [PATCH v2 4/5] cramfs: add mmap support Chris Brandt <Chris.Brandt@renesas.com> - 2017-08-31 04:40 +0200
csiph-web