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: <20130417.131156.13653463501819067.davem@davemloft.net>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ