linux-kernel - Re: [PATCHv2 1/2] mm/vmalloc: Add IO mapping space reused interface support.

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: <CAL_JsqLncBaJ=uceovX80U1JPU8SW3KWKXW3PiVR8Kbnykcvpg@mail.gmail.com>
Date:	Wed, 14 May 2014 11:06:57 -0500
From:	Rob Herring <robherring2@...il.com>
To:	Richard Lee <superlibj8301@...il.com>
Cc:	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Arnd Bergmann <arnd@...db.de>,
	Laura Abbott <lauraa@...eaurora.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	d.hatayama@...fujitsu.com, zhangyanfei@...fujitsu.com,
	liwanp@...ux.vnet.ibm.com, iamjoonsoo.kim@....com,
	hannes@...xchg.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Nicolas Pitre <nico@...xnic.net>
Subject: Re: [PATCHv2 1/2] mm/vmalloc: Add IO mapping space reused interface support.

Adding Nico...

On Wed, May 14, 2014 at 3:18 AM, Richard Lee <superlibj8301@...il.com> wrote:
> For the IO mapping, the same physical address space maybe
> mapped more than one time, for example, in some SoCs:
>   - 0x20001000 ~ 0x20001400 --> 1KB for Dev1
>   - 0x20001400 ~ 0x20001800 --> 1KB for Dev2
>   and the page size is 4KB.
>
> Then both Dev1 and Dev2 will do ioremap operations, and the IO
> vmalloc area's virtual address will be aligned down to 4KB, and
> the size will be aligned up to 4KB. That's to say, only one
> 4KB size's vmalloc area could contain Dev1 and Dev2 IO mapping area
> at the same time.
>
> For this case, we can ioremap only one time, and the later ioremap
> operation will just return the exist vmalloc area.

We already have similar reuse tracking for the static mappings on ARM.
I'm wondering if either that can be reused for ioremap as well or this
can replace the static mapping tracking. It seems silly to have 2
lists to search for finding an existing mapping.

But there is a fundamental problem with your approach. You do not and
cannot check the memory type of the mapping. If you look at the static
mapping code, it only reuses mappings if the memory type match. While
having aliases with different memory types is bad on ARMv6+, I assume
there are some cases that do that given the static mapping code
handles that case. We would at least want to detect and warn if we
didn't want to allow different attributes rather than just return a
mapping with whatever attributes the first mapping used.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/