Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)

[Paul Mundt]

On Thu, May 03, 2007 at 11:30:53PM +1000, Greg Ungerer wrote:
> Robin Getz wrote:
> >>Its not an architecture problem. It can effect any board that
> >>has RAM mapped at a large numerical addresses (larger than TASK_SIZE).
> >>So it can effect any non-MMU platform.
> >
> >Depending on how TASK_SIZE is defined - it looks like everyone else forces 
> >it to end of memory, except 68k[nommu].
> >
> >asm-arm/memory.h:#define TASK_SIZE              (CONFIG_DRAM_SIZE)
> >asm-blackfin/processor.h:#define TASK_SIZE      (memory_end)
> >asm-frv/mem-layout.h:#define TASK_SIZE                  __UL(0xFFFFFFFFUL)
> >
> >asm-m68k/processor.h:#define TASK_SIZE  (0xF0000000UL)
> >asm-m68k/processor.h:#define TASK_SIZE  (0x0E000000)
> >asm-m68k/processor.h:#define TASK_SIZE  (0x0E000000UL)
> >asm-m68knommu/processor.h:#define TASK_SIZE     (0xF0000000UL)
> 
> Probably too:
> 
> asm-sh/processor.h:#define TASK_SIZE    0x7c000000UL
> 
> which has some parts with MMU.
> 
> There have been others out of tree that have it like this to.
> 
It would be at 0x80000000UL on SH if it weren't for address space area
limitations. The 0x7c000000 - 0x7fffffff space is used for shadowing P4
registers in the virtual address space (area 7) with the MMU and it's a
reserved area without the MMU, so TASK_SIZE is trimmed right before this.

However, I'm not sure that the patch Greg has in this set is sufficient
for the problem described. do_mmap_pgoff() won't allow a > TASK_SIZE
mapping anyways. In the SH case we certainly have address spaces that
can be given user permissions well above TASK_SIZE, area 7 space is used
as a bit of a hack for some of this in the MMU case..
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/