Many thanks for the testing.
On Mon, 21 Mar 2005, David S. Miller wrote:
>
> This adjustment of addr relative to floor is very
> strange, it can advance "addr" (and thus "start")
> past the end of the VMA we are unmapping.
Not strange, it's just trying to skip a pointless iteration.
> In fact, it is miraculious that this free_pud_range()
> calling loop terminates properly! Actually, it is
> no mystery, since the next PGD address is the same
> for both the original and adjusted value of "addr".
> So the loop terminates after the first iteration.
Miraculous indeed, I hadn't realized those do {} while () loops
were as robust as that. But it's certainly wrong to have been
calling them once in this case, even if they did recover.
> Anyways, there's the full analysis, what do you make
> of this Hugh? :-)
Much better than I deserve. Silly me. This patch should fix it.
[PATCH 6/5] freepgt: fix addr,end check
Fix placing of free_p?d_range's check for addr against end.
Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]>
--- freepgt5/mm/memory.c 2005-03-22 04:28:40.000000000 +0000
+++ freepgt6/mm/memory.c 2005-03-22 05:11:05.000000000 +0000
@@ -127,11 +127,6 @@ static inline void free_pmd_range(struct
unsigned long next;
unsigned long start;
- if (end - 1 > ceiling - 1)
- end -= PMD_SIZE;
- if (addr > end - 1)
- return;
-
start = addr;
pmd = pmd_offset(pud, addr);
do {
@@ -202,7 +197,9 @@ void free_pgd_range(struct mmu_gather **
return;
}
ceiling &= PMD_MASK;
- if (addr > ceiling - 1)
+ if (end - 1 > ceiling - 1)
+ end -= PMD_SIZE;
+ if (addr > end - 1)
return;
start = addr;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
