Linux Shared Memory Issue

Linux Shared Memory Issue

[Maurice Turcotte]

Greetings:

I am having a problem with Linux Kernel 2.4.5 on a mips.

I have two processes using share memory for IPC. This same
code works fine with Kernel 2.4.7 on a x86. The problem is 
that the second process reads old data out of the shared
memory.

The executive summary->

Process #1 writes "A" to shared memory at 0x2aac7210
Process #2 reads 0 from shared memory at address 0x2aaca210
Process #1 writes "B" to shared memory at 0x2aac7210
Process #2 read "A" from shared memory at address 0x2aaca210
Process #1 writes "C" to shared memory at 0x2aac7210
Process #2 read "B" from shared memory at address 0x2aaca210

It is interesting that the processes get different addresses
associated with the same shmId. I assume this is because of 
some user-space mapping that is going on.

I left out the semaphore diddling, but I believe that part of
the code is correct because it works flawlessly on the 2.4.7 x86.

Any tips on debugging this would be greatly appreciated. If this
is not the proper forum for questions like this, please point me
in the right direction.

Thanks,

mturc

Re: Linux Shared Memory Issue

[Jun Sun]

[-- Attachment #1: Type: text/plain, Size: 1338 bytes --]


Looks like the infamous cache aliasing problem.  Steve Longerbeam had a patch 
which may help.  Please try it and let me know the results.

Thanks.

Jun


Maurice Turcotte wrote:

> Greetings:
> 
> I am having a problem with Linux Kernel 2.4.5 on a mips.
> 
> I have two processes using share memory for IPC. This same
> code works fine with Kernel 2.4.7 on a x86. The problem is 
> that the second process reads old data out of the shared
> memory.
> 
> The executive summary->
> 
> Process #1 writes "A" to shared memory at 0x2aac7210
> Process #2 reads 0 from shared memory at address 0x2aaca210
> Process #1 writes "B" to shared memory at 0x2aac7210
> Process #2 read "A" from shared memory at address 0x2aaca210
> Process #1 writes "C" to shared memory at 0x2aac7210
> Process #2 read "B" from shared memory at address 0x2aaca210
> 
> It is interesting that the processes get different addresses
> associated with the same shmId. I assume this is because of 
> some user-space mapping that is going on.
> 
> I left out the semaphore diddling, but I believe that part of
> the code is correct because it works flawlessly on the 2.4.7 x86.
> 
> Any tips on debugging this would be greatly appreciated. If this
> is not the proper forum for questions like this, please point me
> in the right direction.
> 
> Thanks,
> 
> mturc
> 
> 


[-- Attachment #2: cache-alias.patch --]
[-- Type: text/plain, Size: 2155 bytes --]

diff -Nuar -X /home/stevel/dontdiff linux-2.4.17.orig/arch/mips/kernel/syscall.c linux-2.4.17/arch/mips/kernel/syscall.c
--- linux-2.4.17.orig/arch/mips/kernel/syscall.c	Sun Sep 16 16:29:10 2001
+++ linux-2.4.17/arch/mips/kernel/syscall.c	Thu Jan 24 15:02:18 2002
@@ -24,6 +24,7 @@
 #include <linux/slab.h>
 #include <linux/utsname.h>
 #include <linux/unistd.h>
+#include <linux/shm.h>
 #include <asm/branch.h>
 #include <asm/offset.h>
 #include <asm/ptrace.h>
@@ -53,6 +54,50 @@
 out:
 	return res;
 }
+
+/*
+ * To avoid cache aliases, we map the shard page with same color.
+ */
+#define COLOUR_ALIGN(addr)    (((addr)+SHMLBA-1)&~(SHMLBA-1))
+
+unsigned long arch_get_unmapped_area(struct file *filp, unsigned long addr,
+				     unsigned long len, unsigned long pgoff,
+				     unsigned long flags)
+{
+	struct vm_area_struct *vma;
+
+	if (flags & MAP_FIXED) {
+		/*
+		 * We do not accept a shared mapping if it would violate
+		 * cache aliasing constraints.
+		 */
+		if ((flags & MAP_SHARED) && (addr & (SHMLBA - 1)))
+			return -EINVAL;
+		return addr;
+	}
+
+	if (len > TASK_SIZE)
+		return -ENOMEM;
+	if (!addr)
+		addr = TASK_UNMAPPED_BASE;
+
+	if (flags & MAP_SHARED)
+		addr = COLOUR_ALIGN(addr);
+	else
+		addr = PAGE_ALIGN(addr);
+
+	for (vma = find_vma(current->mm, addr); ; vma = vma->vm_next) {
+		/* At this point:  (!vma || addr < vma->vm_end). */
+		if (TASK_SIZE - len < addr)
+			return -ENOMEM;
+		if (!vma || addr + len <= vma->vm_start)
+			return addr;
+		addr = vma->vm_end;
+		if (flags & MAP_SHARED)
+			addr = COLOUR_ALIGN(addr);
+	}
+}
+
 
 /* common code for old and new mmaps */
 static inline long
diff -Nuar -X /home/stevel/dontdiff linux-2.4.17.orig/include/asm-mips/pgtable.h linux-2.4.17/include/asm-mips/pgtable.h
--- linux-2.4.17.orig/include/asm-mips/pgtable.h	Thu Jan 24 14:35:06 2002
+++ linux-2.4.17/include/asm-mips/pgtable.h	Thu Jan 24 14:56:52 2002
@@ -64,6 +64,9 @@
 #define flush_icache_all()		do { } while(0)
 #endif
 
+/* We provide our own get_unmapped_area to avoid cache aliasing */
+#define HAVE_ARCH_UNMAPPED_AREA
+
 /*
  * - add_wired_entry() add a fixed TLB entry, and move wired register
  */

Re: Linux Shared Memory Issue

[Atsushi Nemoto]

>>>>> On Wed, 24 Apr 2002 15:03:15 -0700, Jun Sun <jsun@mvista.com> said:
jsun> Looks like the infamous cache aliasing problem.  Steve
jsun> Longerbeam had a patch which may help.  Please try it and let me
jsun> know the results.

jsun> +#define COLOUR_ALIGN(addr)    (((addr)+SHMLBA-1)&~(SHMLBA-1))

Recent sparc64's COLOUR_ALIGN macro have pgoff argument like this.
We should do it same way for MIPS?

#define COLOUR_ALIGN(addr,pgoff)		\
	((((addr)+SHMLBA-1)&~(SHMLBA-1)) +	\
	 (((pgoff)<<PAGE_SHIFT) & (SHMLBA-1)))

Thank you.
---
Atsushi Nemoto

Re: Linux Shared Memory Issue

[Jun Sun]

Atsushi Nemoto wrote:

>>>>>>On Wed, 24 Apr 2002 15:03:15 -0700, Jun Sun <jsun@mvista.com> said:
>>>>>>
> jsun> Looks like the infamous cache aliasing problem.  Steve
> jsun> Longerbeam had a patch which may help.  Please try it and let me
> jsun> know the results.
> 
> jsun> +#define COLOUR_ALIGN(addr)    (((addr)+SHMLBA-1)&~(SHMLBA-1))
> 
> Recent sparc64's COLOUR_ALIGN macro have pgoff argument like this.
> We should do it same way for MIPS?
> 
> #define COLOUR_ALIGN(addr,pgoff)		\
> 	((((addr)+SHMLBA-1)&~(SHMLBA-1)) +	\
> 	 (((pgoff)<<PAGE_SHIFT) & (SHMLBA-1)))
> 


What is the purpose of adding the pgoff part?  To avoid mapping all shared 
regions into the beginning of cache?

Jun

Re: Linux Shared Memory Issue

[Atsushi Nemoto]

>>>>> On Thu, 25 Apr 2002 11:46:04 -0700, Jun Sun <jsun@mvista.com> said:
>> #define COLOUR_ALIGN(addr,pgoff) \ ((((addr)+SHMLBA-1)&~(SHMLBA-1))
>> + \ (((pgoff)<<PAGE_SHIFT) & (SHMLBA-1)))

jsun> What is the purpose of adding the pgoff part?  To avoid mapping
jsun> all shared regions into the beginning of cache?

I suppose so.  For example, mmapping offset 0x1000 of /dev/kmem will
return 0xXXXX0000 address if we ignore pgoff.  This can cause aliasing
problem with KSEG0 address (0x80001000).  Adding pgoff, mmap will
return 0xXXXX1000.

In case of IPC shm, pgoff is always 0 so this change does not effect.

---
Atsushi Nemoto

XSHM/shared-pixmap fix Was: Linux Shared Memory Issue

[Florian Lohoff]

[-- Attachment #1.1: Type: text/plain, Size: 1506 bytes --]

Hi Ralf, *,

On Wed, Apr 24, 2002 at 03:03:15PM -0700, Jun Sun wrote:
> Looks like the infamous cache aliasing problem.  Steve Longerbeam had a 
> patch which may help.  Please try it and let me know the results.

> Maurice Turcotte wrote:
> >I am having a problem with Linux Kernel 2.4.5 on a mips.
> >
> >I have two processes using share memory for IPC. This same
> >code works fine with Kernel 2.4.7 on a x86. The problem is 
> >that the second process reads old data out of the shared
> >memory.
> >
> >The executive summary->
> >
> >Process #1 writes "A" to shared memory at 0x2aac7210
> >Process #2 reads 0 from shared memory at address 0x2aaca210
> >Process #1 writes "B" to shared memory at 0x2aac7210
> >Process #2 read "A" from shared memory at address 0x2aaca210
> >Process #1 writes "C" to shared memory at 0x2aac7210
> >Process #2 read "B" from shared memory at address 0x2aaca210
> >

I today tried the patch in conjunction with XFree86 and XSHM on
an Indy R5000/150. Usually all gtk shared-pixmaps get destroyed
and written lines in it. With this patch all these garbage disappears.
As long as there a no serious issues against this patch i would
vote for inclused. It applies against todays cvs with only little
offsets and gave me no problems. It definitly solves some serious
issues with shm.

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
Nine nineth on september the 9th              Welcome to the new billenium

[-- Attachment #1.2: cache-alias.patch --]
[-- Type: text/plain, Size: 2230 bytes --]

diff -Nuar -X /home/stevel/dontdiff linux-2.4.17.orig/arch/mips/kernel/syscall.c linux-2.4.17/arch/mips/kernel/syscall.c
--- linux-2.4.17.orig/arch/mips/kernel/syscall.c	Sun Sep 16 16:29:10 2001
+++ linux-2.4.17/arch/mips/kernel/syscall.c	Thu Jan 24 15:02:18 2002
@@ -24,6 +24,7 @@
 #include <linux/slab.h>
 #include <linux/utsname.h>
 #include <linux/unistd.h>
+#include <linux/shm.h>
 #include <asm/branch.h>
 #include <asm/offset.h>
 #include <asm/ptrace.h>
@@ -53,6 +54,50 @@
 out:
 	return res;
 }
+
+/*
+ * To avoid cache aliases, we map the shard page with same color.
+ */
+#define COLOUR_ALIGN(addr)    (((addr)+SHMLBA-1)&~(SHMLBA-1))
+
+unsigned long arch_get_unmapped_area(struct file *filp, unsigned long addr,
+				     unsigned long len, unsigned long pgoff,
+				     unsigned long flags)
+{
+	struct vm_area_struct *vma;
+
+	if (flags & MAP_FIXED) {
+		/*
+		 * We do not accept a shared mapping if it would violate
+		 * cache aliasing constraints.
+		 */
+		if ((flags & MAP_SHARED) && (addr & (SHMLBA - 1)))
+			return -EINVAL;
+		return addr;
+	}
+
+	if (len > TASK_SIZE)
+		return -ENOMEM;
+	if (!addr)
+		addr = TASK_UNMAPPED_BASE;
+
+	if (flags & MAP_SHARED)
+		addr = COLOUR_ALIGN(addr);
+	else
+		addr = PAGE_ALIGN(addr);
+
+	for (vma = find_vma(current->mm, addr); ; vma = vma->vm_next) {
+		/* At this point:  (!vma || addr < vma->vm_end). */
+		if (TASK_SIZE - len < addr)
+			return -ENOMEM;
+		if (!vma || addr + len <= vma->vm_start)
+			return addr;
+		addr = vma->vm_end;
+		if (flags & MAP_SHARED)
+			addr = COLOUR_ALIGN(addr);
+	}
+}
+
 
 /* common code for old and new mmaps */
 static inline long
diff -Nuar -X /home/stevel/dontdiff linux-2.4.17.orig/include/asm-mips/pgtable.h linux-2.4.17/include/asm-mips/pgtable.h
--- linux-2.4.17.orig/include/asm-mips/pgtable.h	Thu Jan 24 14:35:06 2002
+++ linux-2.4.17/include/asm-mips/pgtable.h	Thu Jan 24 14:56:52 2002
@@ -64,6 +64,9 @@
 #define flush_icache_all()		do { } while(0)
 #endif
 
+/* We provide our own get_unmapped_area to avoid cache aliasing */
+#define HAVE_ARCH_UNMAPPED_AREA
+
 /*
  * - add_wired_entry() add a fixed TLB entry, and move wired register
  */

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: XSHM/shared-pixmap fix Was: Linux Shared Memory Issue

[Maciej W. Rozycki]

On Sat, 27 Apr 2002, Florian Lohoff wrote:

  [NON-Text Body part not included]

 Check it doesn't break static executables -- there were a few
arch_get_unmapped_area() updates in mm/mmap.c that you don't include in
the patch it would seem. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: Linux Shared Memory Issue

[Florian Lohoff]

[-- Attachment #1: Type: text/plain, Size: 635 bytes --]

On Wed, Apr 24, 2002 at 05:27:12PM -0400, Maurice Turcotte wrote:
> Greetings:
> 
> I am having a problem with Linux Kernel 2.4.5 on a mips.
> 
> I have two processes using share memory for IPC. This same
> code works fine with Kernel 2.4.7 on a x86. The problem is 
> that the second process reads old data out of the shared
> memory.

This also shows with x-windows on mips with shared pixmaps.

We see this for a long time and did not come to a solution.

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
Nine nineth on september the 9th              Welcome to the new billenium

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

SysV IPC shared memory and virtual alising

[Atsushi Nemoto]

[-- Attachment #1: Type: Text/Plain, Size: 297 bytes --]

Here is an patch to fix virtual aliasing problem with SysV IPC shared
memory.  I tested this patch on a r4k cpu with 32Kb D-cache.

If D-cache is smaller than PAGE_SIZE this patch is not needed at all,
but I think it is not so bad unconditionally forcing alignment to
SHMLBA.

---
Atsushi Nemoto


[-- Attachment #2: unmapped_area.patch --]
[-- Type: Text/Plain, Size: 2204 bytes --]

diff -ur linux.sgi/arch/mips/kernel/syscall.c linux/arch/mips/kernel/syscall.c
--- linux.sgi/arch/mips/kernel/syscall.c	Thu Apr  5 13:56:09 2001
+++ linux/arch/mips/kernel/syscall.c	Mon Aug  6 16:16:36 2001
@@ -30,6 +30,7 @@
 #include <asm/signal.h>
 #include <asm/stackframe.h>
 #include <asm/uaccess.h>
+#include <asm/shmparam.h>
 
 extern asmlinkage void syscall_trace(void);
 typedef asmlinkage int (*syscall_t)(void *a0,...);
@@ -91,6 +92,47 @@
 {
 	return do_mmap2(addr, len, prot, flags, fd, pgoff);
 }
+
+#ifdef HAVE_ARCH_UNMAPPED_AREA
+/* solve cache aliasing problem (see Documentation/cache.txt and
+   arch/sparc64/kernel/sys_sparc.c */
+#define COLOUR_ALIGN(addr)	(((addr)+SHMLBA-1)&~(SHMLBA-1))
+
+unsigned long arch_get_unmapped_area(struct file *filp, unsigned long addr, unsigned long len, unsigned long pgoff, unsigned long flags)
+{
+	struct vm_area_struct * vmm;
+
+	if (flags & MAP_FIXED) {
+		/* We do not accept a shared mapping if it would violate
+		 * cache aliasing constraints.
+		 */
+		if ((flags & MAP_SHARED) && (addr & (SHMLBA - 1)))
+			return -EINVAL;
+		return addr;
+	}
+
+	if (len > TASK_SIZE)
+		return -ENOMEM;
+	if (!addr)
+		addr = TASK_UNMAPPED_BASE;
+
+	if (flags & MAP_SHARED)
+		addr = COLOUR_ALIGN(addr);
+	else
+		addr = PAGE_ALIGN(addr);
+
+	for (vmm = find_vma(current->mm, addr); ; vmm = vmm->vm_next) {
+		/* At this point:  (!vmm || addr < vmm->vm_end). */
+		if (TASK_SIZE - len < addr)
+			return -ENOMEM;
+		if (!vmm || addr + len <= vmm->vm_start)
+			return addr;
+		addr = vmm->vm_end;
+		if (flags & MAP_SHARED)
+			addr = COLOUR_ALIGN(addr);
+	}
+}
+#endif /* HAVE_ARCH_UNMAPPED_AREA */
 
 save_static_function(sys_fork);
 static_unused int _sys_fork(struct pt_regs regs)
diff -ur linux.sgi/include/asm-mips/pgtable.h linux/include/asm-mips/pgtable.h
--- linux.sgi/include/asm-mips/pgtable.h	Sun Aug  5 23:41:28 2001
+++ linux/include/asm-mips/pgtable.h	Mon Aug  6 16:17:11 2001
@@ -740,6 +740,9 @@
 
 #include <asm-generic/pgtable.h>
 
+/* We provide our own get_unmapped_area to cope with VA holes for userland */
+#define HAVE_ARCH_UNMAPPED_AREA
+
 #endif /* !defined (_LANGUAGE_ASSEMBLY) */
 
 #define io_remap_page_range remap_page_range

Re: SysV IPC shared memory and virtual alising

[Dominic Sweetman]

Atsushi Nemoto (nemoto@toshiba-tops.co.jp) writes:

> Here is an patch to fix virtual aliasing problem with SysV IPC
> shared memory.  I tested this patch on a r4k cpu with 32Kb D-cache.
> 
> If D-cache is smaller than PAGE_SIZE this patch is not needed at
> all...

More precisely, if the size of a D-cache "set" is smaller than
PAGE_SIZE.  So a CPU with a 16Kbyte 4-way set-associative cache and
4Kbyte PAGE_SIZE is safe.

Dominic Sweetman
Algorithmics Ltd

Re: SysV IPC shared memory and virtual alising

[Ralf Baechle]

On Mon, Aug 06, 2001 at 09:50:14AM +0100, Dominic Sweetman wrote:

> > Here is an patch to fix virtual aliasing problem with SysV IPC
> > shared memory.  I tested this patch on a r4k cpu with 32Kb D-cache.
> > 
> > If D-cache is smaller than PAGE_SIZE this patch is not needed at
> > all...
> 
> More precisely, if the size of a D-cache "set" is smaller than
> PAGE_SIZE.  So a CPU with a 16Kbyte 4-way set-associative cache and
> 4Kbyte PAGE_SIZE is safe.

Or is physically indexed and physically tagged or magically deals with
aliasing such as R4000 / R4400 SC and MC versions or R10000, R12000 or
R14000.

  Ralf

Re: SysV IPC shared memory and virtual alising

[Ralf Baechle]

On Mon, Aug 06, 2001 at 04:44:52PM +0900, Atsushi Nemoto wrote:

> Here is an patch to fix virtual aliasing problem with SysV IPC shared
> memory.  I tested this patch on a r4k cpu with 32Kb D-cache.
> 
> If D-cache is smaller than PAGE_SIZE this patch is not needed at all,
> but I think it is not so bad unconditionally forcing alignment to
> SHMLBA.

It's wasting huge amounts of address space.  That can be prohibitive if
you want to run something such as electric fence.  Technically the worst
case of any CPU that's required is 32kb on R4000 / R4400 SC and MC
versions, so I don't want to go beyond that.

What does this patch have to do with SysV shared mem?  Shmat(2) does
proper alignment checking and aligning and doesn't call
arch_get_unmapped_area.

We do have an alignment problem with mmap(2); somebody already has a
correct patch for this already pending to be merged by Alan and Linus
as it affects all architectures.  I assume your patch was actually
intended to fix this problem; it' doesn't correctly properly deal with
anonymous mappings which have no extra alignment constraints nor
correctly factor in the file offset so with just two mmap calls I can
still create aliases.

  Ralf

Re: SysV IPC shared memory and virtual alising

[Atsushi Nemoto]

>>>>> On Tue, 14 Aug 2001 10:49:41 +0200, Ralf Baechle <ralf@oss.sgi.com> said:
ralf> It's wasting huge amounts of address space.  That can be
ralf> prohibitive if you want to run something such as electric fence.
ralf> Technically the worst case of any CPU that's required is 32kb on
ralf> R4000 / R4400 SC and MC versions, so I don't want to go beyond
ralf> that.

Yes.  My patch is wasting address space.  I did not know reasonable
size for alignment, so I used SHMLBA value.  It may be better to
calculate proper alignment size on run-time or compile-time.

ralf> What does this patch have to do with SysV shared mem?  Shmat(2)
ralf> does proper alignment checking and aligning and doesn't call
ralf> arch_get_unmapped_area.

I tried with this code (Xshm extention in Xserver use shm like this) :

	shmid = shmget(IPC_PRIVATE, 0x1000, IPC_CREAT | 0777);
	data = shmat(shmid, 0, 0);
	data2 = shmat(shmid, 0, 0);

In this case, get_unmapped_area() is called with a file structure does
not have 'get_unmapped_area' operation ('shmem_file_operations') so
arch_get_unmapped_area() is called.

---
Atsushi Nemoto

Re: XSHM/shared-pixmap fix Was: Linux Shared Memory Issue

[Atsushi Nemoto]

>>>>> On Mon, 6 May 2002 13:04:58 +0200 (MET DST), "Maciej W. Rozycki" <macro@ds2.pg.gda.pl> said:
macro>  Check it doesn't break static executables -- there were a few
macro> arch_get_unmapped_area() updates in mm/mmap.c that you don't
macro> include in the patch it would seem.

I have yet another arch_get_unmapped_area which includes it.

My arch_get_unmapped_area is a hybrid of one in mm/mmap.c and one in
arch/sparc64/sys_sparc64.c.  Also, I am using MY_SHMLBA to avoid
wasting address space.  I got following comments from Ralf when I
posted my previous patch.

>>>>> On Tue, 14 Aug 2001 10:49:41 +0200, Ralf Baechle <ralf@oss.sgi.com> said:
ralf> It's wasting huge amounts of address space.  That can be
ralf> prohibitive if you want to run something such as electric fence.
ralf> Technically the worst case of any CPU that's required is 32kb on
ralf> R4000 / R4400 SC and MC versions, so I don't want to go beyond
ralf> that.


Here is my arch_get_unmapped_area.

#ifdef HAVE_ARCH_UNMAPPED_AREA
/* solve cache aliasing problem (see Documentation/cachetlb.txt and
   arch/sparc64/kernel/sys_sparc.c */
#if SHMLBA > 0x10000
/* avoid overkill... */
#define MY_SHMLBA	0x10000
#else
#define MY_SHMLBA	SHMLBA
#endif
#define COLOUR_ALIGN(addr,pgoff)		\
	((((addr)+MY_SHMLBA-1)&~(MY_SHMLBA-1)) +	\
	 (((pgoff)<<PAGE_SHIFT) & (MY_SHMLBA-1)))

unsigned long arch_get_unmapped_area(struct file *filp, unsigned long addr, unsigned long len, unsigned long pgoff, unsigned long flags)
{
	struct vm_area_struct * vmm;
	int do_color_align;

	if (flags & MAP_FIXED) {
		/* We do not accept a shared mapping if it would violate
		 * cache aliasing constraints.
		 */
		if ((flags & MAP_SHARED) && (addr & (MY_SHMLBA - 1)))
			return -EINVAL;
		return addr;
	}

	if (len > TASK_SIZE)
		return -ENOMEM;
	do_color_align = 0;
	if (filp || (flags & MAP_SHARED))
		do_color_align = 1;
	if (addr) {
		if (do_color_align)
			addr = COLOUR_ALIGN(addr, pgoff);
		else
			addr = PAGE_ALIGN(addr);
		vmm = find_vma(current->mm, addr);
		if (TASK_SIZE - len >= addr &&
		    (!vmm || addr + len <= vmm->vm_start))
			return addr;
	}
	addr = TASK_UNMAPPED_BASE;
	if (do_color_align)
		addr = COLOUR_ALIGN(addr, pgoff);
	else
		addr = PAGE_ALIGN(addr);

	for (vmm = find_vma(current->mm, addr); ; vmm = vmm->vm_next) {
		/* At this point:  (!vmm || addr < vmm->vm_end). */
		if (TASK_SIZE - len < addr)
			return -ENOMEM;
		if (!vmm || addr + len <= vmm->vm_start)
			return addr;
		addr = vmm->vm_end;
		if (do_color_align)
			addr = COLOUR_ALIGN(addr, pgoff);
	}
}
#endif /* HAVE_ARCH_UNMAPPED_AREA */

---
Atsushi Nemoto