From patchwork Thu Oct 12 06:16:09 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nicolas Pitre X-Patchwork-Id: 115581 Delivered-To: patch@linaro.org Received: by 10.140.22.163 with SMTP id 32csp1575585qgn; Wed, 11 Oct 2017 23:17:35 -0700 (PDT) X-Google-Smtp-Source: AOwi7QBsPB3FxkVqDqYWKfZ7eCvMyQ1h9RqEKYo+uTlEnlu2lQzLBk/6kyFAPFjS1BCt4qQZkLyV X-Received: by 10.101.88.70 with SMTP id s6mr1266014pgr.216.1507789054971; Wed, 11 Oct 2017 23:17:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1507789054; cv=none; d=google.com; s=arc-20160816; b=gVUzY+pYPTqCKS8epcEiL1R9IjhkKa80x+m4tRMX2Oz73/YMKgcVVnM3umOxELzr/D E7P3WYq1PZDNoUyyzFAPkgDL5uZQIl4PlrNvaWGzPZQzromJC/wD4UaSwgheIlBJ7mBc gLe3wfeGTgq2BtsPZUWHTUTo7Eqi+rixiY6R/lyxH1bULvFKXShFnkmiIw8d106ss/gd IKwCe8GEfhG3zhQs67O2oqdulMskw2m4X72Tc79D2s8eZTDukRF2SPFKyR9JaGovHV2a 0f8+enqfNk4WHjA5CVnArf/ndaCbU8Hwu5V/VJyebDT7GbsAlsh2V+D1kbSmFgAPtX0e CswA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=ZYuCF5pyX52RjhI0RS1Hz7+5ZyTQrFxoQ3mZsCSfET8=; b=o6CpMbqvtHX/DTT6a8f2CiZZvXGsZKjdWXUt71g896TdqMzUCGjAIysOYB7r8FehsO 3rpLkRqGmYQV4MvJdYLwEqDuKXXQw1DeDTzMn3aw2siuRTjDNiGBqeHyvk3Ofh1QbAkt hD/4Swh405OJS/dJjUGSHY4UduvhjxEIk7QaCeNtJLSU5gxyHEbHLsKj+IG5lPRprwdU JuP6fNpAp7+hSRPQ2An13/JqYLEh612iBy2d+VzX9Adu67jnRz0tL6b7UxRPn+AX/A7q tBM037lVg/0kOYMaWWnOKalFShAZkf0ZGGcrVnzzPfW/u+2BifZlA3DrgqufCoIXyzpn vFgw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@pobox.com header.s=sasl header.b=mdYqeu4G; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u2si11069414pgc.323.2017.10.11.23.17.34; Wed, 11 Oct 2017 23:17:34 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@pobox.com header.s=sasl header.b=mdYqeu4G; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752311AbdJLGQr (ORCPT + 27 others); Thu, 12 Oct 2017 02:16:47 -0400 Received: from pb-smtp2.pobox.com ([64.147.108.71]:58641 "EHLO sasl.smtp.pobox.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750774AbdJLGQo (ORCPT ); Thu, 12 Oct 2017 02:16:44 -0400 Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id E75C99C40E; Thu, 12 Oct 2017 02:16:43 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:date:message-id; s=sasl; bh=AW/pfBgyZ+alTTujNYQqPWK7G+s =; b=mdYqeu4GDK7Mzj3tFoK+S006QRAwD5uCXSavK4HNJIAQJgAsUcqAG+uVQQm Si5COpR0w6NWwdQf9+sAzeW9vGCz7m1qWf72JWhqh04cPeW42OwDKaNu3E96LYeF FEXZLGFUGlAfCeLIwjG3/1QiwXNO85w9VhItFi9awcZ4qwA8= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id DFA799C40D; Thu, 12 Oct 2017 02:16:43 -0400 (EDT) Received: from yoda.home (unknown [137.175.234.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 6D7DA9C40B; Thu, 12 Oct 2017 02:16:43 -0400 (EDT) Received: from xanadu.home (xanadu.home [192.168.2.2]) by yoda.home (Postfix) with ESMTP id 644382DA0631; Thu, 12 Oct 2017 02:16:42 -0400 (EDT) From: Nicolas Pitre To: Alexander Viro , Christoph Hellwig Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-embedded@vger.kernel.org, linux-kernel@vger.kernel.org, Chris Brandt Subject: [PATCH v6 0/4] cramfs refresh for embedded usage Date: Thu, 12 Oct 2017 02:16:09 -0400 Message-Id: <20171012061613.28705-1-nicolas.pitre@linaro.org> X-Mailer: git-send-email 2.9.5 X-Pobox-Relay-ID: EAFC2C4E-AF14-11E7-93DF-575F0C78B957-78420484!pb-smtp2.pobox.com Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This series brings a nice refresh to the cramfs filesystem, adding the following capabilities: - Direct memory access, bypassing the block and/or MTD layers entirely. - Ability to store individual data blocks uncompressed. - Ability to locate individual data blocks anywhere in the filesystem. The end result is a very tight filesystem that can be accessed directly from ROM without any other subsystem underneath. This also allows for user space XIP which is a very important feature for tiny embedded systems. This series is also available based on v4.14-rc3 via git here: http://git.linaro.org/people/nicolas.pitre/linux xipcramfs Why cramfs? Because cramfs is very simple and small. With CONFIG_CRAMFS_BLOCK=n and CONFIG_CRAMFS_PHYSMEM=y the cramfs driver may use as little as 3704 bytes of code. That's many times smaller than squashfs. And the runtime memory usage is also much less with cramfs than squashfs. It packs very tightly already compared to romfs which has no compression support. And the cramfs format was simple to extend, allowing for both compressed and uncompressed blocks within the same file. Does it use MTD or not? The MTD layer is used to get at the actual physical/virtual address for the filesystem image. The underlying MTD device (or a partition based on it) specified as mount argument must use a driver that implements the mtd->_point method. Once mtd_point() is successful, all accesses are performed directly in memory and the MTD layer is no longer involved. Patches adding point support to a few more MTD drivers can be found here: http://git.linaro.org/people/nicolas.pitre/linux mtd_point Why not using DAX? DAX stands for "Direct Access" and is a generic kernel layer helping with the necessary tasks involved with XIP. It is tailored for large writable filesystems and relies on the presence of an MMU. It also has the following shortcoming: "The DAX code does not work correctly on architectures which have virtually mapped caches such as ARM, MIPS and SPARC." That makes it unsuitable for a large portion of the intended targets for this series. And due to the read-only nature of cramfs, it is possible to achieve the intended result with a much simpler approach making DAX somewhat overkill in this context. The maximum size of a cramfs image can't exceed 272MB. In practice it is likely to be much much less. Given this series is concerned with small memory systems, even in the MMU case there is always plenty of vmalloc space left to map it all and even a 272MB memremap() wouldn't be a problem. If it is then maybe your system is big enough with large resources to manage already and you're pretty unlikely to be using cramfs in the first place. Of course, while this cramfs remains backward compatible with existing filesystem images, a newer mkcramfs version is necessary to take advantage of the extended data layout. I created a version of mkcramfs that detects ELF files and marks text+rodata segments for XIP and compresses the rest of those ELF files automatically. So here it is. I'm also willing to step up as cramfs maintainer given that no sign of any maintenance activities appeared for years. Changes from v5: - Switch to MTD for obtaining the cramfs image memory address rather than accepting a physical address directly as a mount argument. - Drop the patch for making root mount possible as the MTD mount case is already supported and that covers our usage. - There is no longer a separate filesystem type. It is "cramfs" for both blockdev based and MTD/memory based accesses. - Fix NULL deref in cramfs_statfs() when using direct memory access. Changes from v4: - Remove fault handler with vma splitting code in favor of VM_MIXEDMAP for much simpler code. Thanks to Christoph Hellwig for review and suggestions. - Additional code cleanups, mostly from Christoph's suggestions. Changes from v3: - Rebased on v4.13. - Made direct access depend on cramfs not being modular due to unexported vma handling functions. - Solicit comments from mm people explicitly. Changes from v2: - Plugged a few races in cramfs_vmasplit_fault(). Thanks to Al Viro for highlighting them. - Fixed some checkpatch warnings Changes from v1: - Improved mmap() support by adding the ability to partially populate a mapping and lazily split the non directly mapable pages to a separate vma at fault time (thanks to Chris Brandt for testing). - Clarified the documentation some more. diffstat: Documentation/filesystems/cramfs.txt | 42 +++ MAINTAINERS | 4 +- fs/cramfs/Kconfig | 39 ++- fs/cramfs/README | 31 +- fs/cramfs/inode.c | 514 +++++++++++++++++++++++++---- include/uapi/linux/cramfs_fs.h | 26 +- 6 files changed, 587 insertions(+), 69 deletions(-)