Re: [PARISC] Handle wrapping in expand_upwards()

[Andrew Morton <akpm@linux-foundation.org>]

> On Thu, 21 Jun 2007 05:11:04 -0400 Kyle McMartin <kyle@parisc-linux.org> wrote:
> From: Helge Deller <deller@gmx.de>
> 
> Function expand_upwards() did not guarded against wrapping
> around to address 0. This fixes the adjtimex02 testcase from
> the Linux Test Project on a 32bit PARISC kernel.
> 
> [expand_upwards is only used on parisc and ia64; it looks like it does
>  the right thing on both. --kyle]
> 
> Signed-off-by: Helge Deller <deller@gmx.de>
> Cc: Tony Luck <tony.luck@intel.com>
> Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
> ---
> 
> Index: linux-2.6/mm/mmap.c
> ===================================================================
> --- linux-2.6.orig/mm/mmap.c	2007-05-19 13:30:10.000000000 -0400
> +++ linux-2.6/mm/mmap.c	2007-06-21 05:18:46.000000000 -0400
> @@ -1536,9 +1536,14 @@
>  	 * vma->vm_start/vm_end cannot change under us because the caller
>  	 * is required to hold the mmap_sem in read mode.  We need the
>  	 * anon_vma lock to serialize against concurrent expand_stacks.
> +	 * Also guard against wrapping around to address 0.
>  	 */
> -	address += 4 + PAGE_SIZE - 1;
> -	address &= PAGE_MASK;
> +	if (address < PAGE_ALIGN(address+4))
> +		address = PAGE_ALIGN(address+4);
> +	else {
> +		anon_vma_unlock(vma);
> +		return -ENOMEM;
> +	}
>  	error = 0;
>  

You did't really provide enough information for us to be able to decide
whether this change is needed in 2.6.22, let alone 2.6.21.

I will magically infer from your To: line that you consider it 2.6.22
material, but if so I think that we'll need suitable reviewing, testing and
acking from Tony, please.  If he's offline (ols, perhaps?) then we might
have a problem.  Perhaps find a suitable ia64-enabled alternate?


As for 2.6.21: I'll assume it's needed there as well.  Please advise if
otherwise.