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]

Message-ID: <CA+55aFwt82h7hk1YiCeoG2-GGpgLvyW8t_hZRHxyhDQw=_Luzw@mail.gmail.com>
Date:	Wed, 17 Apr 2013 07:44:33 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Tomi Valkeinen <tomi.valkeinen@...com>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Clemens Ladisch <clemens@...isch.de>,
	Arnd Bergmann <arnd@...db.de>, Takashi Iwai <tiwai@...e.de>,
	Mauro Carvalho Chehab <mchehab@...hat.com>,
	David Miller <davem@...emloft.net>,
	Ralf Baechle <ralf@...ux-mips.org>
Subject: Re: Device driver memory 'mmap()' function helper cleanup

On Wed, Apr 17, 2013 at 4:34 AM, Tomi Valkeinen <tomi.valkeinen@...com> wrote:
>
> Should there be a similar helper that uses remap_pfn_range() instead of
> io_remap_pfn_range()?

The two are practically identical (*). I went back-and-forth over
which one to use, and ended up using io_remap_pfn_range() because that
ends up being the fancier one in a few special cases.

And it's actually about 50/50 whether people use that function on RAM
or on MMIO memory. Some people use it for DMA buffers, some people use
it for memory-mapped PCI memory, so the whole confusion about naming
ends up being double. We probably should get rid of
"io_remap_pfn_range()" entirely, since the real issue ends up being
what page protection bits to use, and drivers do that outside of this
function.

So you can use the new helper function to convert things that use
remap_pfn_range() too. The differences end up mattering only for
either highmem RAM pages (which get used for /dev/mem, but not for the
normal drivers) or for actual memory-mapped IO, in which case the
io_remap_pfn_range() function does a bit more.

                    Linus

(*) 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".
--
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/