lkml.org 
[lkml]   [2007]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)
    Date
    On Thu 3 May 2007 09:30, Greg Ungerer pondered:
    > Robin Getz wrote:
    > > On Thu 3 May 2007 07:03, Greg Ungerer pondered:
    > >> Robin Getz wrote:
    > >>> On Wed 2 May 2007 07:32, Greg Ungerer pondered:
    > >>>> Robin Getz wrote:
    > >>>>> I was trying to understand why we don't want to do the same checking
    > >>>>> on noMMU?
    > >>>>
    > >>>> The problem is on systems that have RAM mapped at high physical
    > >>>> addresses. TASK_SIZE may well be a numerically smaller number
    > >>>> than the address range that RAM sits in. So this test fails when
    > >>>> it shouldn't.

    Put the patch back, since I added some new cc'

    > diff -Naur linux-2.6.21/fs/namei.c linux-2.6.21-uc0/fs/namei.c
    > --- linux-2.6.21/fs/namei.c 2007-05-01 17:12:53.000000000 +1000
    > +++ linux-2.6.21-uc0/fs/namei.c 2007-05-01 17:16:18.000000000 +1000
    > @@ -120,12 +120,14 @@
    > int retval;
    > unsigned long len = PATH_MAX;
    >
    > +#ifdef CONFIG_MMU
    > if (!segment_eq(get_fs(), KERNEL_DS)) {
    > if ((unsigned long) filename >= TASK_SIZE)
    > return -EFAULT;
    > if (TASK_SIZE - (unsigned long) filename < PATH_MAX)
    > len = TASK_SIZE - (unsigned long) filename;
    > }
    > +#endif
    >
    > retval = strncpy_from_user(page, filename, len);
    > if (retval > 0) {


    > >>>
    > >>> So, then this is a problem only on one or two architectures, not all
    > >>> noMMU platforms?
    > >>
    > >> 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.
    >
    > > I'm happy to learn we are doing something wrong, but I think that we just
    > > copied the arm/frv setup.
    >
    > That is one way to handle it. Have you followed all the other
    > uses of TASK_SIZE and verified it is not a problem?

    No, I assumed that Russell/David were smarter than we were, and that doing so
    would not be a problem :)

    Not looking at ./arch or ./include TASK_SIZE looks like it is only used in

    fs/hugetlbfs/inode.c
    fs/binfmt_elf.c
    fs/namespace.c
    fs/binfmt_aout.c
    fs/namei.c
    kernel/kexec.c
    mm/mremap.c
    mm/mempolicy.c
    mm/memory.c
    mm/nommu.c
    mm/mmap.c

    I poked through some, and from first glance, it mostly looked OK with setting
    TASK_SIZE to CONFIG_DRAM_SIZE or memory_end.

    -Robin
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-05-04 18:13    [W:0.030 / U:0.296 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site