From: "Amir Hermelin" <amir@montilio.com>
To: "'William Lee Irwin III'" <wli@holomorphy.com>
Cc: <linux-kernel@vger.kernel.org>
Subject: RE: Creating a page struct for HIGHMEM pages
Date: Sun, 7 Dec 2003 19:56:17 +0200 [thread overview]
Message-ID: <00ac01c3bceb$757b30d0$1d01a8c0@CARTMAN> (raw)
In-Reply-To: <20031207162203.GQ19856@holomorphy.com>
Thanks William.
I may be missing something a little more basic: I have a contiguous physical
memory area (IO memory), and I want to manage it with struct pages. If I'm
to write to the page I need to kmap it, therefore (as I understand it) I
need to zero the ->virtual field. What I don't understand is how, given
the struct page I've allocated and filled out, is the page correlated with
the correct physical memory. Where do I put the information that struct
page X points to physical address Y, so that when I kmap(X) I get a virtual
address pointing to Y?
Thanks,
Amir.
-----Original Message-----
From: William Lee Irwin III [mailto:wli@holomorphy.com]
Sent: Sunday, December 07, 2003 6:22 PM
To: Amir Hermelin
Cc: linux-kernel@vger.kernel.org
Subject: Re: Creating a page struct for HIGHMEM pages
On Sun, Dec 07, 2003 at 06:02:46PM +0200, Amir Hermelin wrote:
> Suppose I want to create a page struct pointing to high memory (e.g.
> IO mapped memory), that is, allocate the memory for the page struct
> myself and fill in the values, what are the necessary flags/values
> (other than the 'virtual' field) I must be sure to set? Does the
> page* need to be located anywhere specific? Does the pte field need
> to be set in anyway? The question is relevant to kernel versions
> 2.4.20 and up.
I'm not entirely sure this is safe (I don't know of anything doing it off
the top of my head or any guarantee it should work), but PG_reserved is an
absolute requirement at the very least. ->virtual is likely irrelevant.
Also, COW userspace mappings of such beasts are illegal since the physical
address can't be calculated for do_wp_page() to do its copy. Codepaths
assuming it's in a zone and so on must also be avoided. You'll need to set
VM_RESERVED on the vma, since the page structure can't be looked up via
pte_page(). If you want faults handled on it, you'll also have to define
your own ->nopage() method.
I generally prefer setting VM_RESERVED and prefaulting in ->f_op->mmap(),
though that may not be feasible in some scenarios. Handling this would be
much easier if drivers could override fault handling methods and the like.
-- wli
next prev parent reply other threads:[~2003-12-07 17:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-07 16:02 Creating a page struct for HIGHMEM pages Amir Hermelin
2003-12-07 16:22 ` William Lee Irwin III
2003-12-07 17:56 ` Amir Hermelin [this message]
2003-12-07 17:59 ` William Lee Irwin III
2003-12-07 18:05 ` Amir Hermelin
2003-12-07 18:08 ` 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='00ac01c3bceb$757b30d0$1d01a8c0@CARTMAN' \
--to=amir@montilio.com \
--cc=linux-kernel@vger.kernel.org \
--cc=wli@holomorphy.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox