From: "David S. Miller" <davem@davemloft.net>
To: Hugh Dickins <hugh@veritas.com>
Cc: akpm@osdl.org, nickpiggin@yahoo.com.au, tony.luck@intel.com,
benh@kernel.crashing.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/5] freepgt: free_pgtables use vma list
Date: Tue, 22 Mar 2005 14:41:51 -0800 [thread overview]
Message-ID: <20050322144151.5b08b047.davem@davemloft.net> (raw)
In-Reply-To: <Pine.LNX.4.61.0503222142280.9761@goblin.wat.veritas.com>
On Tue, 22 Mar 2005 21:51:39 +0000 (GMT)
Hugh Dickins <hugh@veritas.com> wrote:
> I still can't see what's wrong with the code that's already
> there. My brain is seizing up, I'm taking a break.
Ok, meanwhile I'll do a brain dump of what I think this
code should be doing.
Let's take an example free_pgd_range() call. Say the
address parameters are:
addr 0x10000
end 0xa4000
floor 0x00000
ceiling 0xb2000
(This example comes from my exit_mmap() VMA dump earlier
in this thread. If you disable the VMA skipping optimization
the first call to free_pgd_range() has these parameters.)
What ought this free_pgd_range() call do? This range of
addresses, from floor to ceiling, is smaller than a PMD_SIZE
(which on sparc64 is 1 << 23). Therefore it should clear
no PGD or PUD entries.
Yet, it does clear them, specifically:
free_pgd_range():
1) mask addr (0x10000) to PMD_MASK, addr is now 0
2) addr < floor (0x00000) test does not pass
3) mask ceiling (0xb2000) to PMD_MASK, ceiling is now 0 too
4) end - 1 > ceiling - 1 test does not pass
5) addr > end - 1 test does not pass either
6) We now loop one PGDIR_SIZE at a time from
addr (0x00000) to end (0xa4000), calling
down into...
free_pud_range():
1) addr=0, end=0xa4000, floor=0, ceiling=0
2) We loop one PUD_SIZE at a time from
addr (0x00000) to end (0xa4000), calling
down into...
free_pmd_range():
1) addr=0, end=0xa4000, floor=0, ceiling=0
2) We loop one PMD_SIZE at a time from
addr (0x00000) to end (0xa4000), calling
down into...
free_pte_range():
And later when we finish the loops in free_pmd_range()
and free_pud_range() we do pud_clear() and pgd_clear()
respectively, both wrong.
The source of the problems seems to be how ceiling began
at the top of the call chain as 0xb2000, but when we
masked it with PMD_MASK that set it to zero, which means
"top of address space" in these functions. That's not
what we want.
I added a quick hack to the simulator I posted, where
we mask ceiling in free_pgd_range(), I do it like this:
if (ceiling) {
ceiling &= PMD_MASK;
if (!ceiling)
return;
}
and things seem to behave. I'll try to analyze things
further and test this out on a real kernel, but all of
these adjustments at the top of free_pgd_range() really
start to look like pure spaghetti. :-)
next prev parent reply other threads:[~2005-03-22 22:45 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-21 20:52 [PATCH 1/5] freepgt: free_pgtables use vma list Hugh Dickins
2005-03-21 20:55 ` [PATCH 2/5] freepgt: remove MM_VM_SIZE(mm) Hugh Dickins
2005-03-21 20:56 ` [PATCH 3/5] freepgt: hugetlb_free_pgd_range Hugh Dickins
2005-03-21 20:57 ` [PATCH 4/5] freepgt: remove arch pgd_addr_end Hugh Dickins
2005-03-21 20:58 ` [PATCH 5/5] freepgt: mpnt to vma cleanup Hugh Dickins
2005-03-21 22:26 ` [PATCH 1/5] freepgt: free_pgtables use vma list David S. Miller
2005-03-22 5:47 ` Hugh Dickins
2005-03-22 17:41 ` David S. Miller
2005-03-22 11:40 ` Andrew Morton
2005-03-22 12:17 ` Nick Piggin
2005-03-22 16:37 ` Hugh Dickins
2005-03-22 18:34 ` David S. Miller
2005-03-22 19:01 ` David S. Miller
2005-03-22 19:21 ` David S. Miller
2005-03-22 19:23 ` David S. Miller
2005-03-22 19:36 ` Hugh Dickins
2005-03-22 20:21 ` David S. Miller
2005-03-22 23:45 ` Benjamin Herrenschmidt
2005-03-22 20:33 ` David S. Miller
2005-03-22 21:51 ` Hugh Dickins
2005-03-22 22:41 ` David S. Miller [this message]
2005-03-23 0:51 ` Hugh Dickins
2005-03-23 2:09 ` David S. Miller
2005-03-22 23:32 ` Nick Piggin
2005-03-22 23:44 ` David S. Miller
2005-03-23 0:19 ` Nick Piggin
2005-03-23 0:20 ` David S. Miller
2005-03-23 0:00 ` David S. Miller
2005-03-23 0:03 ` David S. Miller
2005-03-22 21:28 ` David S. Miller
2005-03-22 23:30 ` Benjamin Herrenschmidt
2005-03-23 13:28 ` Hugh Dickins
2005-03-23 23:07 ` Benjamin Herrenschmidt
-- strict thread matches above, loose matches on Subject: below --
2005-03-21 22:31 Luck, Tony
2005-03-21 23:02 ` David S. Miller
2005-03-22 4:14 ` Nick Piggin
2005-03-22 5:29 ` David S. Miller
2005-03-22 6:08 ` Hugh Dickins
2005-03-22 6:33 ` Nick Piggin
2005-03-22 17:52 ` David S. Miller
2005-03-22 17:55 ` David S. Miller
2005-03-22 5:42 ` Hugh Dickins
2005-03-22 18:06 Luck, Tony
2005-03-22 18:48 ` Hugh Dickins
2005-03-22 22:40 Luck, Tony
2005-03-22 23:30 ` David S. Miller
2005-03-23 0:40 ` Hugh Dickins
2005-03-22 23:53 Luck, Tony
2005-03-22 23:56 ` David S. Miller
2005-03-23 0:56 ` Hugh Dickins
2005-03-23 1:10 ` Andrew Morton
2005-03-23 2:00 ` David S. Miller
2005-03-23 2:10 ` Nick Piggin
2005-03-23 2:15 ` David S. Miller
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=20050322144151.5b08b047.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=akpm@osdl.org \
--cc=benh@kernel.crashing.org \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
--cc=tony.luck@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.