Subject: RE: NFS Root failure in 2.4.18 - Traced to 256k COLOUR_ALIGN

From: "TWEDE,ROGER (HP-Boise,ex1)" <[email-masked]>
Date: Fri, 1 Nov 2002 13:28:32 -0800

I traced the NFS root boot failure to a change made in the the function
arch_get_unmapped_area(...).  The system goes from functional to
non-functional with a single function change made in 2.4.18.
linux/arch/mips/kernel/syscall.c :: arch_get_unmapped_area(...),
COLOUR_ALIGN 

The virtual mappings are now aligned on a 256k boundary instead of a page
boundary whenever the mapping is to be shared (as in an executable file
mapping).  The COLOUR_ALIGN macro was added and is used in place of
PAGE_ALIGN as found in the file arch/mips/kernel/syscall.c.

As our system boots from a disk such as ide, all calls to this function pass
in a requested address of 0x0.  The function then chooses a free virtual
address space accordingly.  Upon nfsroot booting, calls to this function
pass in a requested address that is non-zero (such as 0x0fb60000).  This
address is page aligned, so in the old version of
arch_get_unmapped_area(...) the exact requested address was fine and
returned from the get_unmapped_area().  In the new version of the function,
the alignment requirement is 256k, however the nfs requested address is not
aligned on a 256k boundary, and is therefore pushed up to the next 256k
boundary.  The system does not like this and fails. (the function is never
called again, further booting does not take place)

Several questions that arise:
- In the nfs case, should the file structure have its
file->f_op->get_unmapped_area() member assigned, causing a file specific
get_unmapped_area to be called instead of this arch_get_unmapped_area?
- Or should the mapping request pass in a requested address which already
has valid 256k alignment?
- Or should requested addresses that are misaligned be handled well by the
calling code once the translated/aligned address is returned to the calller?

And generally:
- Why does nfsroot booting cause apecific non-zero virtual addresses to be
requested, whereas in the ide disk booting case, addressed are left
unspecified (0x0) (no requested mapping)?

Thanks for any information anyone might lend.

Roger

---

From: Atsushi Nemoto <[email-masked]>
Date: Wed, 06 Nov 2002 17:05:02 +0900 (JST)

>>>>> On Fri, 1 Nov 2002 13:28:32 -0800 , "TWEDE,ROGER (HP-Boise,ex1)" <[email-masked]> said:
roger> I traced the NFS root boot failure to a change made in the the
roger> function arch_get_unmapped_area(...).  The system goes from
roger> functional to non-functional with a single function change made
roger> in 2.4.18.  linux/arch/mips/kernel/syscall.c ::
roger> arch_get_unmapped_area(...), COLOUR_ALIGN

Just for your information, I also met this problem when I switched
back to old redhat-6.0 userland.  More recent userlands (RedHat 7.0,
7.1, Debian) seems free from this trouble.

---
Atsushi Nemoto

---

From: Jun Sun <[email-masked]>
Date: Wed, 6 Nov 2002 14:29:54 -0800

> get_unmapped_area to be called instead of this arch_get_unmapped_area?

Don't really know about this question.

But in general if the pages are going to be shared, you will hit cache 
aliasing problem.  Then you need to implement something like cache 
coloring, which must be an unique one for the whole system, which naturally
means you need to use arch_get_unmapped_area().

> has valid 256k alignment?

Not necessarily, as long as caller is prepared for a possibly different
return value.

> calling code once the translated/aligned address is returned to the calller?

I don't think so.

> unspecified (0x0) (no requested mapping)?

I am curious too.  At least it should move along fine once it is given the
the new aligned address.

Jun