From: Chris Brandt <Chris.Brandt@renesas.com>
To: Nicolas Pitre <nicolas.pitre@linaro.org>
CC: Al Viro <viro@ZenIV.linux.org.uk>,
        "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
        "linux-embedded@vger.kernel.org" <linux-embedded@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v2 4/5] cramfs: add mmap support
Thread-Topic: [PATCH v2 4/5] cramfs: add mmap support
Thread-Index: AQHTFrYiY6R51FFvb0KRm0l9W82V16KZZVmAgABwtgCAAA7ZAIAAUjoAgAGRyCCAAAyTAIAAAhmggAH4XxA=
Date: Thu, 31 Aug 2017 02:29:50 +0000
Message-ID: <SG2PR06MB1165F81B8D8CFEB21A3D0B288A9D0@SG2PR06MB1165.apcprd06.prod.outlook.com>
References: <20170816173536.1879-1-nicolas.pitre@linaro.org>
 <20170816173536.1879-5-nicolas.pitre@linaro.org>
 <20170828064632.GA26136@ZenIV.linux.org.uk>
 <nycvar.YSQ.7.76.1708280914260.2606@knanqh.ubzr>
 <20170828142306.GJ5426@ZenIV.linux.org.uk>
 <nycvar.YSQ.7.76.1708281058590.2606@knanqh.ubzr>
 <SG2PR06MB1165FE414425AFD1C64E7CD78A9F0@SG2PR06MB1165.apcprd06.prod.outlook.com>
 <nycvar.YSQ.7.76.1708291552240.2606@knanqh.ubzr> 
Accept-Language: en-US
Content-Language: en-US
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2017 02:29:50.6253
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 53d82571-da19-47e4-9cb4-625a166a4a2a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2PR06MB0933
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nfs id v7V2U44k023610
Content-Length: 3750
Lines: 97

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>