From: William Lee Irwin III <wli@holomorphy.com>
To: Scott Kaplan <sfkaplan@cs.amherst.edu>
Cc: linux-mm@kvack.org
Subject: Re: Obtaining the kernel's PTEs
Date: Fri, 13 Sep 2002 15:10:32 -0700 [thread overview]
Message-ID: <20020913221032.GM2179@holomorphy.com> (raw)
In-Reply-To: <BDF7B0A2-C75C-11D6-8D39-000393829FA4@cs.amherst.edu>
On Fri, Sep 13, 2002 at 05:06:59PM -0400, Scott Kaplan wrote:
> Yet another question...
> Assume that I'm not concerned with ZONE_HIGHMEM, and I have a struct page*
> . How would I obtain a pointer to the PTE that maps the corresponding
> virtual page in the kernel's address space to this given page?
> In case you're wondering, ``Why does he want that?'': I want to remove
> access permissions for pages, and I want to include the kernel in that
> denial of permission. An example of where this matters is when you have a
> page cache page that was allocated by the VFS for read()/write()
> operations on a regular (non-mmaped) file. Only the kernel has a mapping
> to that page, and I a trap to occur when the kernel tries to use that page.
> Must I get the PGD, PMD, and then PTE? Is there a function that will do
> this nicely for me so that I don't write redundant (and potentially buggy)
> code for this little task?
Well, there are a couple of issues here.
(1) Pagetables are only meaningful to a couple of machines, most notably
i386 and m68k. The rest is pretty much software TLB or inverted.
So there's zero accounting of the direct-mapping within the kernel
for some machines, not sure which since I've not gone about the
task of hunting for the answer to "What does everyone do when
they've taken a TLB miss on kernelspace?" My suspicion is TLB
entries are generated on the fly for what is not bolted.
(2) The kernel is often mapped out using various tidbits of TLB magic not
handled by user PTE manipulation routines. e.g. the G and PS bits
on i386. i386 is even worse, as the PAT bit in a PTE has the same
position as the PS bit in a PMD so a priori knowledge of mapping
size is required. At the moment, hardware pagetable large pages
such as i386's PTE's it keeps in PMD's are not understood by
the core kernel to begin with...
Also, since the kernel translations at least on i386 use the G
bit which is basically "invalidate the TLB entry only when a
specific page is targeted." This is also not a particularly
friendly feature...
There is pain involved here.
Cheers,
Bill
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
next prev parent reply other threads:[~2002-09-13 22:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-13 21:06 Scott Kaplan
2002-09-13 22:10 ` William Lee Irwin III [this message]
2002-09-15 21:02 ` Scott Kaplan
2002-09-15 22:44 ` 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=20020913221032.GM2179@holomorphy.com \
--to=wli@holomorphy.com \
--cc=linux-mm@kvack.org \
--cc=sfkaplan@cs.amherst.edu \
/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