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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
