linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Schlichter <schlicht@uni-mannheim.de>
To: Martin Schlemmer <azarah@gentoo.org>,
	William Lee Irwin III <wli@holomorphy.com>
Cc: Andrew Morton <akpm@osdl.org>,
	smiler@lanil.mine.nu, KML <linux-kernel@vger.kernel.org>,
	linux-mm@kvack.org, Christian Zander <zander@mail.minion.de>
Subject: Re: 2.5.74-mm2 + nvidia (and others)
Date: Mon, 14 Jul 2003 18:51:54 +0200	[thread overview]
Message-ID: <200307141851.55775.schlicht@uni-mannheim.de> (raw)
In-Reply-To: <1058184576.799.341.camel@workshop.saharacpt.lan>

Hi,

can anyone tell me WHY the NV_PMD_OFFSET() should not work the way it is with 
the new NVIDIA patch? For our memories here it is again:

#define NV_PMD_OFFSET(address, pgd, pmd) \
    { \
        pmd_t *pmd__ = pmd_offset_map(pgd, address); \
        pmd = *pmd__; \
        pmd_unmap(pmd__); \
    }

1.) For a 2 level pagetable it simply results in a:
	pmd = *((pmd_t *) pgd);

So here the correct entry from the first page directory is copied into a 
variable on the stack. No big deal, as the location of this entry is not 
interesting for the further tablewalk, only its contents.

2.) So let's see what happens for a 3 level pagetable.
We get following code after expanding (most of) the macros:

a.) pmd_t *pmd__ = ((pmd_t *)kmap_atomic(pgd_page(*(pgd)), KM_PMD0) + 
pmd_index(addr));
b.) pmd = *pmd__;
c.) kunmap_atomic(pmd__, KM_PMD0);

The most interesting part is the first line of it...
a.) Here the page number is extracted from the pgd entry and converted to a 
pointer to a page_struct (pgd_page). Now the page is mapped (from the high 
memory) into the lower memory (kmap_atomic). The index where the interesting 
pmd entry is located in this page is extracted from the virtual address via 
the pmd_index macro. With this the pointer to the pmd entry is calculated and 
assigned to pmd__.

b.) Now this entry is simply copied into a variable located at the stack. 
(Again not an issue, as the location of the variable is not of interest for 
the rest of the tablewalk anymore.)

c.) At least the page that contains the pmd entry, too, is unmapped, but our 
local copy on the stack stays...


So after both pieces of code the pmd entry is stored in a variable on the 
stack and the further processing does not need to know where it came from, it 
just needs its contents...

So please tell me where this is wrong...! I just can't see it...

Thank you all for all the work!

Best regards
   Thomas Schlichter
--
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/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

  reply	other threads:[~2003-07-14 16:51 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-07 15:08 Christian Axelsson
2003-07-07 15:33 ` Thomas Schlichter
2003-07-07 17:09   ` Christian Axelsson
2003-07-07 19:30   ` Andrew Morton
2003-07-08  7:03     ` Martin Schlemmer
2003-07-08  7:26       ` William Lee Irwin III
2003-07-08  8:51         ` Thomas Schlichter
2003-07-08  8:55           ` William Lee Irwin III
2003-07-08  9:37             ` Peter C. Ndikuwera
2003-07-08 11:01               ` Petr Vandrovec
2003-07-08 11:23                 ` Flameeyes
2003-07-08 11:26                   ` William Lee Irwin III
2003-07-08 11:35                   ` Christian Axelsson
2003-07-08 11:40       ` Christian Axelsson
2003-07-12  1:21       ` William Lee Irwin III
2003-07-14 12:09         ` Martin Schlemmer
2003-07-14 16:51           ` Thomas Schlichter [this message]
2003-07-07 23:08 ` William Lee Irwin III
2003-07-08 12:37 Petr Vandrovec
2003-07-08 12:57 ` Flameeyes
2003-07-08 13:02 ` Christian Axelsson
2003-07-08 13:07   ` Petr Vandrovec

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=200307141851.55775.schlicht@uni-mannheim.de \
    --to=schlicht@uni-mannheim.de \
    --cc=akpm@osdl.org \
    --cc=azarah@gentoo.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=smiler@lanil.mine.nu \
    --cc=wli@holomorphy.com \
    --cc=zander@mail.minion.de \
    /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