From patchwork Thu Oct 5 20:00:07 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chris Brandt X-Patchwork-Id: 9987897 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 6134D60247 for ; Thu, 5 Oct 2017 20:05:45 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5228A28D0F for ; Thu, 5 Oct 2017 20:05:45 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 46D1628D29; Thu, 5 Oct 2017 20:05:45 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A4CC228D0F for ; Thu, 5 Oct 2017 20:05:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752162AbdJEUFT (ORCPT ); Thu, 5 Oct 2017 16:05:19 -0400 Received: from relmlor1.renesas.com ([210.160.252.171]:5168 "EHLO relmlie4.idc.renesas.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751415AbdJEUFQ (ORCPT ); Thu, 5 Oct 2017 16:05:16 -0400 X-Greylist: delayed 302 seconds by postgrey-1.27 at vger.kernel.org; Thu, 05 Oct 2017 16:05:15 EDT Received: from unknown (HELO relmlir2.idc.renesas.com) ([10.200.68.152]) by relmlie4.idc.renesas.com with ESMTP; 06 Oct 2017 05:00:11 +0900 Received: from relmlii1.idc.renesas.com (relmlii1.idc.renesas.com [10.200.68.65]) by relmlir2.idc.renesas.com (Postfix) with ESMTP id AFB9249511; Fri, 6 Oct 2017 05:00:11 +0900 (JST) X-IronPort-AV: E=Sophos;i="5.42,481,1500908400"; d="scan'208";a="258629684" Received: from mail-hk2apc01lp0208.outbound.protection.outlook.com (HELO APC01-HK2-obe.outbound.protection.outlook.com) ([65.55.88.208]) by relmlii1.idc.renesas.com with ESMTP/TLS/AES256-SHA256; 06 Oct 2017 05:00:10 +0900 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=renesasgroup.onmicrosoft.com; s=selector1-renesas-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9u7vV3IRmActoeG4hExK31F17Nno2vHL6h82wCsKvSU=; b=i82I7A8lcd6i8UQ/oIrOXnV6JlzRPi7VoYPcuyvYTfQcELvIc8Eg8pSxSLf2VAWyiutxN1m7Ybw8g12VmFT+7gA4kdfgjkr8ihWC8dOXFnHJzSufJXUItrjClmqx4PlayAb2+aqs76N/Qj3qJBOC1nhkgq2MPvWaqCTXaYnGTd0= Received: from SG2PR06MB1165.apcprd06.prod.outlook.com (10.169.58.147) by SG2PR06MB1166.apcprd06.prod.outlook.com (10.169.58.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Thu, 5 Oct 2017 20:00:07 +0000 Received: from SG2PR06MB1165.apcprd06.prod.outlook.com ([fe80::20d9:2da6:a48a:6de3]) by SG2PR06MB1165.apcprd06.prod.outlook.com ([fe80::20d9:2da6:a48a:6de3%14]) with mapi id 15.20.0077.018; Thu, 5 Oct 2017 20:00:07 +0000 From: Chris Brandt To: Nicolas Pitre , Christoph Hellwig CC: Richard Weinberger , Alexander Viro , "linux-mm@kvack.org" , linux-fsdevel , "linux-embedded@vger.kernel.org" , LKML Subject: RE: [PATCH v4 4/5] cramfs: add mmap support Thread-Topic: [PATCH v4 4/5] cramfs: add mmap support Thread-Index: AQHTN+jqAWEAAFIUD0y2Yl5HM9WmdKLOr10AgADqRgCAAZbTgIAADWyAgAECLQCAAAlOAIAAAbkAgAAA+ACAAQglgIAA4BIAgAF/9vA= Date: Thu, 5 Oct 2017 20:00:07 +0000 Message-ID: References: <20170927233224.31676-1-nicolas.pitre@linaro.org> <20170927233224.31676-5-nicolas.pitre@linaro.org> <20171001083052.GB17116@infradead.org> <20171003145732.GA8890@infradead.org> <20171003153659.GA31600@infradead.org> <20171004072553.GA24620@infradead.org> In-Reply-To: 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: [4.59.13.106] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SG2PR06MB1166; 20:3Mcuak4bi2hk1DejplddBF70SgTqqeu2qfM42h1Azp5DwWBpq5DOlqCbGPKfapPQk3/yFPvgn48EAN8arHXhW+lqGehVwJ5TNKvYoGqw4wPFu+xii0O09d61NhkvRQIiw650Jxw0M8Ma4envtlu6QHuo4O46XzHDVYSqQRK8caE= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: fbe39b8a-5f2e-439f-8eec-08d50c2badaf x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:SG2PR06MB1166; x-ms-traffictypediagnostic: SG2PR06MB1166: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SG2PR06MB1166; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SG2PR06MB1166; x-forefront-prvs: 04519BA941 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(39860400002)(52314003)(189002)(24454002)(69234005)(199003)(229853002)(7736002)(74316002)(54906003)(93886005)(7696004)(316002)(3846002)(2950100002)(81156014)(14454004)(66066001)(81166006)(39060400002)(102836003)(5660300001)(86362001)(110136005)(6116002)(25786009)(2900100001)(76176999)(6436002)(55016002)(3660700001)(478600001)(72206003)(2906002)(575784001)(6506006)(8676002)(6246003)(106356001)(50986999)(97736004)(33656002)(54356999)(189998001)(3280700002)(4326008)(53936002)(305945005)(5250100002)(9686003)(8936002)(101416001)(99286003)(68736007)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:SG2PR06MB1166; H:SG2PR06MB1165.apcprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: renesas.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: renesas.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2017 20:00:07.8477 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 53d82571-da19-47e4-9cb4-625a166a4a2a X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2PR06MB1166 Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Wednesday, October 04, 2017, Nicolas Pitre wrote: > On Wed, 4 Oct 2017, Christoph Hellwig wrote: > > > As said in my last mail: look at the VM_MIXEDMAP flag and how it is > > used by DAX, and you'll get out of the vma splitting business in the > > fault path. > > Alright, it appears to work. > > The only downside so far is the lack of visibility from user space to > confirm it actually works as intended. With the vma splitting approach > you clearly see what gets directly mapped in /proc/*/maps thanks to > remap_pfn_range() storing the actual physical address in vma->vm_pgoff. > With VM_MIXEDMAP things are no longer visible. Any opinion for the best > way to overcome this? > > Anyway, here's a replacement for patch 4/5 below: > > ----- >8 > Subject: cramfs: add mmap support > > When cramfs_physmem is used then we have the opportunity to map files > directly from ROM, directly into user space, saving on RAM usage. > This gives us Execute-In-Place (XIP) support. Tested on my setup: * Cortex A9 (with MMU) * CONFIG_XIP_KERNEL=y * booted with XIP CRAMFS as my rootfs * all apps and libraries marked as XIP in my cramfs image So far, functionally it seems to work the same as [PATCH v4 4/5]. As Nicolas said, before you could easily see that all my apps and libraries were XIP from Flash: $ 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] b6e69000-b6f42000 r-xp 1b0bc000 00:0c 766540 /lib/libc-2.18-2013.10.so b6f42000-b6f4a000 ---p 1b195000 00:0c 766540 /lib/libc-2.18-2013.10.so b6f4a000-b6f4c000 r--p 000d9000 00:0c 766540 /lib/libc-2.18-2013.10.so b6f4c000-b6f4d000 rw-p 000db000 00:0c 766540 /lib/libc-2.18-2013.10.so b6f4d000-b6f50000 rw-p 00000000 00:00 0 b6f50000-b6f67000 r-xp 1b0a4000 00:0c 670372 /lib/ld-2.18-2013.10.so b6f6a000-b6f6b000 rw-p 00000000 00:00 0 b6f6c000-b6f6e000 rw-p 00000000 00:00 0 b6f6e000-b6f6f000 r--p 00016000 00:0c 670372 /lib/ld-2.18-2013.10.so b6f6f000-b6f70000 rw-p 00017000 00:0c 670372 /lib/ld-2.18-2013.10.so beac0000-beae1000 rw-p 00000000 00:00 0 [stack] bebc9000-bebca000 r-xp 00000000 00:00 0 [sigpage] ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors] But now just busybox looks like it's 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] b6e4d000-b6f26000 r-xp 00000000 00:0c 766540 /lib/libc-2.18-2013.10.so b6f26000-b6f2e000 ---p 000d9000 00:0c 766540 /lib/libc-2.18-2013.10.so b6f2e000-b6f30000 r--p 000d9000 00:0c 766540 /lib/libc-2.18-2013.10.so b6f30000-b6f31000 rw-p 000db000 00:0c 766540 /lib/libc-2.18-2013.10.so b6f31000-b6f34000 rw-p 00000000 00:00 0 b6f34000-b6f4b000 r-xp 00000000 00:0c 670372 /lib/ld-2.18-2013.10.so b6f4e000-b6f4f000 rw-p 00000000 00:00 0 b6f50000-b6f52000 rw-p 00000000 00:00 0 b6f52000-b6f53000 r--p 00016000 00:0c 670372 /lib/ld-2.18-2013.10.so b6f53000-b6f54000 rw-p 00017000 00:0c 670372 /lib/ld-2.18-2013.10.so bec93000-becb4000 rw-p 00000000 00:00 0 [stack] befad000-befae000 r-xp 00000000 00:00 0 [sigpage] ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors] Regardless, from a functional standpoint: Tested-by: Chris Brandt Just FYI, the previous [PATCH v4 4/5] also included this (which was the only real difference between v3 and v4): Chris diff --git a/fs/cramfs/Kconfig b/fs/cramfs/Kconfig index 5b4e0b7e13..306549be25 100644 --- a/fs/cramfs/Kconfig +++ b/fs/cramfs/Kconfig @@ -30,7 +30,7 @@ config CRAMFS_BLOCKDEV config CRAMFS_PHYSMEM bool "Support CramFs image directly mapped in physical memory" - depends on CRAMFS + depends on CRAMFS = y default y if !CRAMFS_BLOCKDEV help This option allows the CramFs driver to load data directly from