From: Paul Mackerras <paulus@samba.org>
To: Andrew Morton <akpm@zip.com.au>, torvalds@transmeta.com
Cc: linux-kernel@vger.kernel.org
Subject: page table page->index
Date: Mon, 29 Jul 2002 15:00:55 +1000 (EST) [thread overview]
Message-ID: <15684.52231.710183.242098@argo.ozlabs.ibm.com> (raw)
I found a situation where page->index for a pagetable page can be set
to 0 instead of the correct value. This means that ptep_to_address
will return the wrong answer. The problem occurs when remap_pmd_range
calls pte_alloc_map and pte_alloc_map needs to allocate a new pte
page, because remap_pmd_range has masked off the top bits of the
address (to avoid overflow in the computation of `end'), and it passes
the masked address to pte_alloc_map.
Now we presumably don't need to get from the physical pages mapped by
remap_page_range back to the ptes mapping them. But we could easily
map some normal pages using ptes in that pagetable page subsequently,
and when we call ptep_to_address on their ptes it will give the wrong
answer.
The patch below fixes the problem.
There is a more general question this brings up - some of the
procedures which iterate over ranges of ptes will do the wrong thing
if the end of the address range is too close to ~0UL, while others are
OK. Is this a problem in practice? On i386, ppc, and the 64-bit
architectures it isn't since user addresses can't go anywhere near
~0UL, but what about arm or m68k for instance?
And BTW, being able to go from a pte pointer to the mm and virtual
address that that pte maps is an extremely useful thing on ppc, since
it will enable me to do MMU hash-table management at set_pte (and
ptep_*) time and thus avoid the extra traversal of the pagetables that
I am currently doing in flush_tlb_*. So if you do decide to back out
rmap, please leave in the hooks for setting page->mapping and
page->index on pagetable pages.
Paul.
diff -urN linux-2.5/mm/memory.c pmac-2.5/mm/memory.c
--- linux-2.5/mm/memory.c Thu Jul 18 05:27:58 2002
+++ pmac-2.5/mm/memory.c Sat Jul 27 15:42:18 2002
@@ -863,18 +863,19 @@
static inline int remap_pmd_range(struct mm_struct *mm, pmd_t * pmd, unsigned long address, unsigned long size,
unsigned long phys_addr, pgprot_t prot)
{
- unsigned long end;
+ unsigned long base, end;
+ base = address & PGDIR_MASK;
address &= ~PGDIR_MASK;
end = address + size;
if (end > PGDIR_SIZE)
end = PGDIR_SIZE;
phys_addr -= address;
do {
- pte_t * pte = pte_alloc_map(mm, pmd, address);
+ pte_t * pte = pte_alloc_map(mm, pmd, base + address);
if (!pte)
return -ENOMEM;
- remap_pte_range(pte, address, end - address, address + phys_addr, prot);
+ remap_pte_range(pte, base + address, end - address, address + phys_addr, prot);
pte_unmap(pte);
address = (address + PMD_SIZE) & PMD_MASK;
pmd++;
next reply other threads:[~2002-07-29 5:00 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-29 5:00 Paul Mackerras [this message]
2002-07-30 12:11 ` Russell King
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=15684.52231.710183.242098@argo.ozlabs.ibm.com \
--to=paulus@samba.org \
--cc=akpm@zip.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.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
all inboxes | Powered by JetHome®