From: William Lee Irwin III <wli@holomorphy.com>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org
Subject: [vm 0/6] convert remap_page_range() to remap_pfn_range() in a patch series shorter than 76 patches
Date: Sat, 25 Sep 2004 00:44:45 -0700 [thread overview]
Message-ID: <20040925074445.GD9106@holomorphy.com> (raw)
Resolve physical address overflow issue in the remap_page_range() API
by replacing it with remap_pfn_range(), which accepts its physical
address argument as a pfn, hence allowing the use of a single-precision
physical address argument without the risk of overflow at the API
boundary. The above issue has hobbled support for various 32-bit
architectures, including some embedded systems (ppc440 IIRC), caused
persistent portability issues for sound drivers for legacy systems
(sparc32; unfortunately this patch alone does not fully resolve those),
and according to John Fusco's reports, made drivers for some PCI-X
hardware infeasible to port to recent ia32 PAE enterprise systems. With
this patch series applied, physical address overflows on 32-bit systems
caused directly by remap_page_range() are gone forever, and ca. 100LOC
of cut-and-waste driver code are swept out of existence alongside them.
-- wli
P.S.: The existing solution to the sparc32 issue was to pass a double
precision representation of the physical address as 2 single-
precision arguments in an API (io_remap_page_range()) whose
argument corresponding to those two was a single single-
precision argument on most/all other architectures. The
sparc32-specific issue requires more work beyond these patches
to rectify. The most apparent consequence of the API skew is
that drivers don't compile on sparc32 when they use
io_remap_page_range() due to passing insufficient arguments,
or vice-versa for drivers originally written for sparc32.
next reply other threads:[~2004-09-25 7:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-25 7:44 William Lee Irwin III [this message]
2004-09-25 7:47 ` [vm 1/6] introduce remap_pfn_range() to replace remap_page_range() William Lee Irwin III
2004-09-25 7:49 ` [vm 2/6] convert references to remap_page_range() under arch/ and Documentation/ to remap_pfn_range() William Lee Irwin III
2004-09-25 7:51 ` [vm 3/6] convert users of remap_page_range() under drivers/ and net/ to use remap_pfn_range() William Lee Irwin III
2004-09-25 7:53 ` [vm 4/6] convert users of remap_page_range() under include/asm-*/ " William Lee Irwin III
2004-09-25 7:55 ` [vm 5/6] convert users of remap_page_range() under sound/ " William Lee Irwin III
2004-09-25 7:58 ` [vm 6/6] for -mm only: remove remap_page_range() completely William Lee Irwin III
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040925074445.GD9106@holomorphy.com \
--to=wli@holomorphy.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.