linux-kernel - Re: Device driver memory 'mmap()' function helper cleanup

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]

Date:	Wed, 17 Apr 2013 13:11:56 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	torvalds@...ux-foundation.org
Cc:	tomi.valkeinen@...com, linux-kernel@...r.kernel.org,
	clemens@...isch.de, arnd@...db.de, tiwai@...e.de,
	mchehab@...hat.com, ralf@...ux-mips.org
Subject: Re: Device driver memory 'mmap()' function helper cleanup

From: Linus Torvalds <torvalds@...ux-foundation.org>
Date: Wed, 17 Apr 2013 07:44:33 -0700

> (*) io_remap_pfn_page() is the "extended" version that takes care of
> some special magical details on a couple of odd architectures, notably
> sparc (but also one special case of MIPS PAE that have some magic bit
> tricks). But even for MIPS and Sparc, it ends up devolving to be the
> same as the "regular" remap_pfn_page() for normal memory. I'm adding
> David and Ralf to the cc just to verify that I read it right, but
> everybody else just defines "io_remap_pfn_range" to be
> "remap_pfn_range".

Yeah, the only thing special we do on sparc is interpret the PFN
specially.  We munge it into the real physical address and then
pass it all down to remap_pfn_range() to do the real work.

We used to have a crazy special version of this entire routine
on sparc64 that tried to create huge TLB mappings, but that got
killed quite some time ago:

commit 3e37fd3153ac95088a74f5e7c569f7567e9f993a
Author: David S. Miller <davem@...emloft.net>
Date:   Thu Nov 17 18:17:59 2011 -0800

    sparc: Kill custom io_remap_pfn_range().
    
    To handle the large physical addresses, just make a simple wrapper
    around remap_pfn_range() like MIPS does.
    
    Signed-off-by: David S. Miller <davem@...emloft.net>

--
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/