[PATCH #4/9] 8xx-2.6 | MM tweaks

Hi

The following patch consists of minor tweaks in order to get
the mm to work.

Regards

Pantelis

On Wed, May 26, 2004 at 03:05:45PM +0300, Pantelis Antoniou wrote:

Hi

The following patch consists of minor tweaks in order to get
the mm to work.

I was wondering.  The fault.c change boils down to:
===== arch/ppc/mm/fault.c 1.26 vs edited =====

--- 1.26/arch/ppc/mm/fault.c	2004-05-25 04:50:34 -07:00
+++ edited/arch/ppc/mm/fault.c	2004-05-27 09:48:17 -07:00

@@ -350,11 +350,14 @@
 	pgd_t *dir;
 	pmd_t *pmd;
 	pte_t *pte;
+	struct mm_struct *mm;

 	if (address < TASK_SIZE)
-		return NULL;
+		mm = current->mm;
+	else
+		mm = &init_mm;

-	dir = pgd_offset(&init_mm, address);
+	dir = pgd_offset(mm, address & PAGE_MASK);
 	if (dir) {
 		pmd = pmd_offset(dir, address & PAGE_MASK);
 		if (pmd && pmd_present(*pmd)) {

Can you explain this a bit more?  Looking back at the history in
BitKeeper, this change came from Paul, in the changeset with the
comments of:
PPC update for the recent changes to the pgd/pmd/pte functions.
This implements ptes-in-highmem for PPC, removes the quicklist
and zero-page stuff.  PTEs in highmem on SMP turned out to need
some significant changes to avoid deadlocks on the hash_table_lock
(now renamed to mmu_hash_lock).  The PMDs now contain the physical
address of the PTE page rather than the virtual address.
Anything that takes the mmu_hash_lock now operates with the DMMU
off to avoid MMU hash-table misses.

And for this file in particular:
Do pte_unmap after get_pteptr; use pte_offset_kernel instead of
pte_offset in a couple of places.

Which you exactly reverted.  Were the changes from Paul incorrect here?
Or is perhaps there something more needed on the 8xx side of things?

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Tom Rini wrote:

Let me tell you, I didn't know any of this stuff :).

My algorithm for the changes was simple.

1. Assume that linuxppc_2.4 is more recent that linuxppc-2.5 on 8xx.
2. Forward port any significant changes to 2.5.
3. Test.

If this didn't work, then I would try to fix anything more
complicated.

Thankfully it wasn't neccesary.

Regards

Pantelis


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

On May 28, 2004, at 2:48 AM, Pantelis Antoniou wrote:

Let me tell you, I didn't know any of this stuff :).

OK....I'll review these a little more closely :-)

Thanks.

	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Tom Rini writes:

Which you exactly reverted.  Were the changes from Paul incorrect here?
Or is perhaps there something more needed on the 8xx side of things?

The problem with the old code (which Pantelis put back) is that PTEs
no longer necessarily have fixed, unique virtual addresses in the
kernel.  Now that we can have PTE pages in highmem, it is necessary to
use pte_offset_map to get the address of a PTE (which does a kmap if
you have HIGHMEM enabled) and pte_unmap when you are finished with
it.  The address you get back from pte_offset_map is only valid until
you do pte_unmap, and you can't sleep between pte_offset_map and
pte_unmap (it uses an atomic kmap).

However, PTE pages for kernel mappings are allocated in lowmem, and
you can get a persistent kernel virtual address for them.

Those changes were in va_to_pte, and the only user of that (that I can
find) is va_to_phys, which isn't called at all AFAICS (and shouldn't
be needed).  Probably the best thing is just to remove them.  In
addition, get_8xx_pte and print_8xx_pte appear to be used only in some
debugging code in softemu8xx.c, and could probably be dispensed with
(another #ifdef gone, yay :).  Certainly users of get_8xx_pte could
use get_pteptr instead.

Paul.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/