linux-kernel - RE: [PATCH v5 0/5] cramfs refresh for embedded usage

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <nycvar.YSQ.7.76.1710061215550.6291@knanqh.ubzr>
Date:   Fri, 6 Oct 2017 12:30:08 -0400 (EDT)
From:   Nicolas Pitre <nicolas.pitre@...aro.org>
To:     Chris Brandt <Chris.Brandt@...esas.com>
cc:     Christoph Hellwig <hch@...radead.org>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-embedded@...r.kernel.org" <linux-embedded@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v5 0/5] cramfs refresh for embedded usage

On Fri, 6 Oct 2017, Chris Brandt wrote:

> On Friday, October 06, 2017, Christoph Hellwig wrote:
> > This is still missing a proper API for accessing the file system,
> > as said before specifying a physical address in the mount command
> > line is a an absolute non-no.
> > 
> > Either work with the mtd folks to get the mtd core down to an absolute
> > minimum suitable for you, or figure out a way to specify fs nodes
> > through DT or similar.
> 
> On my system, the QSPI Flash is memory mapped and set up by the boot 
> loader. In order to test the upstream kernel, I use a squashfs image and 
> mtd-rom.
> 
> So, 0x18000000 is the physical address of flash as it is seen by the 
> CPU.
> 
> Is there any benefit to doing something similar to this?
> 
> 	/* File System */
> 	/* Requires CONFIG_MTD_ROM=y */
> 	qspi@...00000 {
> 		compatible = "mtd-rom";
> 		probe-type = "map_rom";
> 		reg = <0x18000000 0x4000000>;	/* 64 MB*/
> 		bank-width = <4>;
> 		device-width = <1>;
> 
> 		#address-cells = <1>;
> 		#size-cells = <1>;
> 
> 		partition@...000 {
> 			label ="user";
> 			reg = <0x0800000 0x800000>; /* 8MB @ 0x18800000 */
> 			read-only;
> 		};
> 	};
> 
> 
> Of course this basically ioremaps the entire space on probe, but I think
> what you really want to do is just ioremap pages at a time (maybe..I 
> might not be following your code correctly)

No need for ioremaping pages individually. This creates unneeded 
overhead, both in terms of code execution and TLB trashing. With a 
single map, the ARM code at least is smart enough to fit large MMU 
descriptors when possible with a single TLB for a large region. And if 
you're interested in XIP cramfs then you do have huge vmalloc space to 
spare anyway.

As to the requirement for a different interface than a raw physical 
address: I'm investigating factoring out the MTD partition parsing code 
so it could be used with or without the rest of MTD. Incidentally, the 
person who wrote the very first incarnation of MTD partitioning 17 years 
ago was actually me, so with luck I might be able to figure out 
something sensible.


Nicolas