Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751399AbdHaC37 (ORCPT ); Wed, 30 Aug 2017 22:29:59 -0400 Received: from relmlor2.renesas.com ([210.160.252.172]:63003 "EHLO relmlie1.idc.renesas.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750822AbdHaC3z (ORCPT ); Wed, 30 Aug 2017 22:29:55 -0400 X-IronPort-AV: E=Sophos;i="5.41,451,1498489200"; d="scan'208";a="255336970" From: Chris Brandt To: Nicolas Pitre CC: Al Viro , "linux-fsdevel@vger.kernel.org" , "linux-embedded@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: References: <20170816173536.1879-1-nicolas.pitre@linaro.org> <20170816173536.1879-5-nicolas.pitre@linaro.org> <20170828064632.GA26136@ZenIV.linux.org.uk> <20170828142306.GJ5426@ZenIV.linux.org.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Chris.Brandt@renesas.com; x-originating-ip: [75.60.247.61] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;SG2PR06MB0933;20:0+a9rDFuj64FMI+y5nwBvmKh2dcVUDyRE9z0lej3U13K6f2uM4j2dqlkbivXDDjzPmnXHXqH7GG5Jkmfug3+BNyJT4aC6n0kz749Cjf+sS0VGwTj1k8wzO3T5oSI64b22wOwAg3ZEqet09Y2v0tdYklkm8m35eMGhXJPejQfZSM= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ce57dc11-117c-4b62-5966-08d4f01827fd x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);SRVR:SG2PR06MB0933; x-ms-traffictypediagnostic: SG2PR06MB0933: x-exchange-antispam-report-test: UriScan:(788757137089); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:SG2PR06MB0933;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:SG2PR06MB0933; x-forefront-prvs: 04163EF38A x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(39860400002)(199003)(189002)(24454002)(229853002)(33656002)(4326008)(5250100002)(575784001)(25786009)(105586002)(106356001)(5660300001)(66066001)(86362001)(97736004)(2906002)(54906002)(8936002)(74316002)(6246003)(9686003)(50986999)(110136004)(93886005)(6916009)(3280700002)(54356999)(81166006)(99286003)(81156014)(76176999)(101416001)(72206003)(7736002)(53936002)(14454004)(305945005)(102836003)(478600001)(189998001)(55016002)(8676002)(6116002)(6506006)(3846002)(7696004)(6436002)(3660700001)(68736007)(2900100001);DIR:OUT;SFP:1102;SCL:1;SRVR:SG2PR06MB0933;H:SG2PR06MB1165.apcprd06.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-OriginatorOrg: renesas.com 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: 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