From patchwork Fri Oct 6 02:45:26 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nicolas Pitre X-Patchwork-Id: 115019 Delivered-To: patch@linaro.org Received: by 10.140.22.163 with SMTP id 32csp1270468qgn; Thu, 5 Oct 2017 19:46:14 -0700 (PDT) X-Google-Smtp-Source: AOwi7QBymSvEL8234xFMLRd/ze7DSrSGSye07SlwbdBvaEpZmbsY1AYougOJVTJn5XLjBnjPBYRu X-Received: by 10.99.123.22 with SMTP id w22mr633730pgc.396.1507257974327; Thu, 05 Oct 2017 19:46:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1507257974; cv=none; d=google.com; s=arc-20160816; b=OlPfXEGtTvTcqbKZVvSYpuBwLP6kdXPi6fM/6wCssgRHE3qbP7pKsxBajJNDhXCi6n FRZlAPlmmIAuG/mr2xzi7q6+iEllET5E3s+1XKXc+pVKcZtjiMlZpy7/PLwbhjaEB2qL jxd05eCpcMflmGtnnCgit38ocVSBiCVTbtGPDHv8jQw7iqmvEXAOxplIZqH8qK21sXgB B8x8q8wEKGM/neYzOZvvQiquDL9+fCews0a9MCgUOav7KdUBteu+eD+KBzKxh/4deuF2 Pio4nIVCjuugzeCI0vmsNngzQ/PwPTCzpOqB1N+SSsF6FJQgiq2g93SjW0457G+cEoEp Oq/w== 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=7qasT9xiwagPIpMbyTFyJWnsrdvweOtaf4o1e741wRc=; b=IAVEqPVYb7Qq3/I1Mt/CDaIufih+WASXwsetaa3muVTyIPN+3TuyzqzKv67lJeNDLw 1gyp1wuYQeK9EFEEW/T3GXc2OPfRLqh4Fg/c/yS3jV5NeOlxgCvqRDm3pxh1OJfNBeKN J6h99KKGYAeKA4Pho+CmjWmoTCsLhOlPKA9qOQejs0IW+dVm/miYwTXlhtRrP4oV/Q3p PRRfVoQolph8/6bleKqo4xrH4/7P20gN6z520DZvWXQtdRGqH0bo1nbsaA+PGklVrsQV 52RBAb3w/lcGJaXPS4aEBtGLwEtBXrEAHYlVpnG+8ibZDq6Z9+Wr1HTSlIrzTclLG7S4 QXrw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@pobox.com header.s=sasl header.b=Tx9XltHr; 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 w128si358323pfw.112.2017.10.05.19.46.14; Thu, 05 Oct 2017 19:46:14 -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=Tx9XltHr; 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 S1751776AbdJFCpm (ORCPT + 26 others); Thu, 5 Oct 2017 22:45:42 -0400 Received: from pb-smtp1.pobox.com ([64.147.108.70]:55163 "EHLO sasl.smtp.pobox.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751083AbdJFCpj (ORCPT ); Thu, 5 Oct 2017 22:45:39 -0400 Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 80D0099B0C; Thu, 5 Oct 2017 22:45:38 -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=hMSQJLKtO3g+vFy2Kn/6ImMehCQ =; b=Tx9XltHrymC9HzZzIGyDlm0+n5KrLXwt2zVaaulTCLVyZr8mMw0aVaO+X71 tG6YGTYxEQsLsfQdpCp0os/gKXv5762qH6MCipYmoSoltCTfoj/3pc0m/K1i8Js8 1kryziCVbQanYvCaViEddxd4ZbLv6bJXRacVHFa1CC8xHltc= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 76A4A99B0B; Thu, 5 Oct 2017 22:45:38 -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-smtp1.pobox.com (Postfix) with ESMTPSA id 04F1299B08; Thu, 5 Oct 2017 22:45:38 -0400 (EDT) Received: from xanadu.home (xanadu.home [192.168.2.2]) by yoda.home (Postfix) with ESMTP id 3100F2DA01F8; Thu, 5 Oct 2017 22:45:37 -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 v5 0/5] cramfs refresh for embedded usage Date: Thu, 5 Oct 2017 22:45:26 -0400 Message-Id: <20171006024531.8885-1-nicolas.pitre@linaro.org> X-Mailer: git-send-email 2.9.5 X-Pobox-Relay-ID: 6F521294-AA40-11E7-9BB4-8EF31968708C-78420484!pb-smtp1.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.13 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. Why not accessing ROM via MTD? The MTD layer is nice and flexible. It also represents a huge overhead considering its core with no other enabled options weights 19KB. That's many times the size of the cramfs code for something that essentially boils down to a glorified argument parser and a call to memremap() in this case. And if someone still wants to use cramfs via MTD then it is already possible with mtdblock. 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 v4: - Remove fault handler with vma splitting in favor of VM_MIXEDMAP at mmap time for much simpler code. Thanks to Christoph Hellwig for review and suggestion. - 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 | 38 +- fs/cramfs/README | 31 +- fs/cramfs/inode.c | 554 +++++++++++++++++++++++++---- include/uapi/linux/cramfs_fs.h | 26 +- init/do_mounts.c | 8 + 7 files changed, 625 insertions(+), 78 deletions(-)