Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)
Russell King wrote: On Fri, May 04, 2007 at 12:12:03PM -0400, Robin Getz wrote: 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) 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 :) Don't look at me - the above came from Hyok, and I just assumed that it was correct without really understanding it. I've noticed though that Hyok's gone rather quiet, so I'm not sure whether we'll ever get ARM uclinux integration complete. We can do this without Hyok. The patches I sent to arm-linux-kernel last week fill all the gaps that I see. I'll be reworking that over the coming weeks to try and get something that is acceptable to all, so we can get this done. Regards Greg Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] SnapGear -- a Secure Computing Company PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com - 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/
Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)
Russell King wrote: On Fri, May 04, 2007 at 12:12:03PM -0400, Robin Getz wrote: 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) 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 :) Don't look at me - the above came from Hyok, and I just assumed that it was correct without really understanding it. I've noticed though that Hyok's gone rather quiet, so I'm not sure whether we'll ever get ARM uclinux integration complete. We can do this without Hyok. The patches I sent to arm-linux-kernel last week fill all the gaps that I see. I'll be reworking that over the coming weeks to try and get something that is acceptable to all, so we can get this done. Regards Greg Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] SnapGear -- a Secure Computing Company PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com - 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/
Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)
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(0xUL) > > > >asm-m68k/processor.h:#define TASK_SIZE (0xF000UL) > >asm-m68k/processor.h:#define TASK_SIZE (0x0E00) > >asm-m68k/processor.h:#define TASK_SIZE (0x0E00UL) > >asm-m68knommu/processor.h:#define TASK_SIZE (0xF000UL) > > Probably too: > > asm-sh/processor.h:#define TASK_SIZE0x7c00UL > > which has some parts with MMU. > > There have been others out of tree that have it like this to. > It would be at 0x8000UL on SH if it weren't for address space area limitations. The 0x7c00 - 0x7fff 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/
Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)
On Fri, May 04, 2007 at 12:12:03PM -0400, Robin Getz wrote: > > > 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) > > > > 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 :) Don't look at me - the above came from Hyok, and I just assumed that it was correct without really understanding it. I've noticed though that Hyok's gone rather quiet, so I'm not sure whether we'll ever get ARM uclinux integration complete. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - 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/
Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)
On Fri, May 04, 2007 at 12:12:03PM -0400, Robin Getz wrote: 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) 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 :) Don't look at me - the above came from Hyok, and I just assumed that it was correct without really understanding it. I've noticed though that Hyok's gone rather quiet, so I'm not sure whether we'll ever get ARM uclinux integration complete. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - 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/
Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)
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(0xUL) asm-m68k/processor.h:#define TASK_SIZE (0xF000UL) asm-m68k/processor.h:#define TASK_SIZE (0x0E00) asm-m68k/processor.h:#define TASK_SIZE (0x0E00UL) asm-m68knommu/processor.h:#define TASK_SIZE (0xF000UL) Probably too: asm-sh/processor.h:#define TASK_SIZE0x7c00UL which has some parts with MMU. There have been others out of tree that have it like this to. It would be at 0x8000UL on SH if it weren't for address space area limitations. The 0x7c00 - 0x7fff 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/
Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)
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.0 +1000
> +++ linux-2.6.21-uc0/fs/namei.c 2007-05-01 17:16:18.0 +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(0xUL)
> >
> > asm-m68k/processor.h:#define TASK_SIZE (0xF000UL)
> > asm-m68k/processor.h:#define TASK_SIZE (0x0E00)
> > asm-m68k/processor.h:#define TASK_SIZE (0x0E00UL)
> > asm-m68knommu/processor.h:#define TASK_SIZE (0xF000UL)
>
> Probably too:
>
> asm-sh/processor.h:#define TASK_SIZE0x7c00UL
>
> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)
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.0 +1000
+++ linux-2.6.21-uc0/fs/namei.c 2007-05-01 17:16:18.0 +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(0xUL)
asm-m68k/processor.h:#define TASK_SIZE (0xF000UL)
asm-m68k/processor.h:#define TASK_SIZE (0x0E00)
asm-m68k/processor.h:#define TASK_SIZE (0x0E00UL)
asm-m68knommu/processor.h:#define TASK_SIZE (0xF000UL)
Probably too:
asm-sh/processor.h:#define TASK_SIZE0x7c00UL
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)
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. 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(0xUL) asm-m68k/processor.h:#define TASK_SIZE (0xF000UL) asm-m68k/processor.h:#define TASK_SIZE (0x0E00) asm-m68k/processor.h:#define TASK_SIZE (0x0E00UL) asm-m68knommu/processor.h:#define TASK_SIZE (0xF000UL) Probably too: asm-sh/processor.h:#define TASK_SIZE0x7c00UL 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? Regards Greg Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] SnapGear -- a Secure Computing Company PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com - 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/
Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)
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. > > > > 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(0xUL) asm-m68k/processor.h:#define TASK_SIZE (0xF000UL) asm-m68k/processor.h:#define TASK_SIZE (0x0E00) asm-m68k/processor.h:#define TASK_SIZE (0x0E00UL) asm-m68knommu/processor.h:#define TASK_SIZE (0xF000UL) I'm happy to learn we are doing something wrong, but I think that we just copied the arm/frv setup. -Robin - 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/
Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)
Robin Getz wrote:
On Wed 2 May 2007 07:32, Greg Ungerer pondered:
Robin Getz wrote:
On Wed 2 May 2007 01:23, Greg Ungerer pondered:
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.0 +1000
+++ linux-2.6.21-uc0/fs/namei.c 2007-05-01 17:16:18.0 +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) {
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.
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.
Regards
Greg
Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED]
SnapGear -- a Secure Computing Company PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
-
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/
Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)
On Wed 2 May 2007 07:32, Greg Ungerer pondered:
> Robin Getz wrote:
> > On Wed 2 May 2007 01:23, Greg Ungerer pondered:
> >> 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.0 +1000
> >> +++ linux-2.6.21-uc0/fs/namei.c 2007-05-01 17:16:18.0 +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) {
> >
> > 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.
So, then this is a problem only on one or two architectures, not all noMMU
platforms?
-Robin
-
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/
Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)
On Wed 2 May 2007 07:32, Greg Ungerer pondered:
Robin Getz wrote:
On Wed 2 May 2007 01:23, Greg Ungerer pondered:
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.0 +1000
+++ linux-2.6.21-uc0/fs/namei.c 2007-05-01 17:16:18.0 +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) {
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.
So, then this is a problem only on one or two architectures, not all noMMU
platforms?
-Robin
-
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/
Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)
Robin Getz wrote:
On Wed 2 May 2007 07:32, Greg Ungerer pondered:
Robin Getz wrote:
On Wed 2 May 2007 01:23, Greg Ungerer pondered:
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.0 +1000
+++ linux-2.6.21-uc0/fs/namei.c 2007-05-01 17:16:18.0 +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) {
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.
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.
Regards
Greg
Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED]
SnapGear -- a Secure Computing Company PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
-
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/
Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)
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. 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(0xUL) asm-m68k/processor.h:#define TASK_SIZE (0xF000UL) asm-m68k/processor.h:#define TASK_SIZE (0x0E00) asm-m68k/processor.h:#define TASK_SIZE (0x0E00UL) asm-m68knommu/processor.h:#define TASK_SIZE (0xF000UL) I'm happy to learn we are doing something wrong, but I think that we just copied the arm/frv setup. -Robin - 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/
Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)
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. 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(0xUL) asm-m68k/processor.h:#define TASK_SIZE (0xF000UL) asm-m68k/processor.h:#define TASK_SIZE (0x0E00) asm-m68k/processor.h:#define TASK_SIZE (0x0E00UL) asm-m68knommu/processor.h:#define TASK_SIZE (0xF000UL) Probably too: asm-sh/processor.h:#define TASK_SIZE0x7c00UL 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? Regards Greg Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] SnapGear -- a Secure Computing Company PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com - 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/
Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)
Hi Robin,
Robin Getz wrote:
On Wed 2 May 2007 01:23, Greg Ungerer pondered:
Hi All,
An update of the uClinux (MMU-less) code against 2.6.21.
A lot of cleanups, and a few bug fixes.
Ahead is more changes to finalize platform device support
for the new style ColdFire serial driver, and switching to
the generic irq code.
http://www.uclinux.org/pub/uClinux/uClinux-2.6.x/linux-2.6.21-uc0.patch.gz
Greg:
Is is possible to split out the m68k stuff from the generic nommu stuff?
I could do that. Usually the actual mm changes have been
a pretty small set of this. Often only 1 or 2 patches.
(or
maybe I am missing the point of this patch? - it is for review/inclusion into
the -mm tree, or just for end users wanting to use 2.6.21?)
This is specifically for review and inclusion in main line.
The patch is labeled uClinux (MMU-less), which I read as generic, but the
majority has to do with only m68knommu.
Well, if any non-mmu architecture people sent me patches that
made sense for me to push upstream I would include them here.
But that doesn't happen very often. They generally do it
themselves.
Historically the first -uc patches had m68knommu, h8300 and v850
as well as the non-mmu changes in it.
arch/m68knommu/Kconfig | 12
arch/m68knommu/Makefile |4
arch/m68knommu/kernel/process.c |2
arch/m68knommu/kernel/setup.c| 116 +---
arch/m68knommu/kernel/time.c |9
arch/m68knommu/mm/memory.c | 100 ---
arch/m68knommu/platform/5206/config.c|8
arch/m68knommu/platform/5206e/config.c |7
arch/m68knommu/platform/520x/config.c| 122
arch/m68knommu/platform/523x/config.c|8
arch/m68knommu/platform/5249/config.c| 51 +
arch/m68knommu/platform/5272/config.c|7
arch/m68knommu/platform/527x/config.c|7
arch/m68knommu/platform/528x/config.c|7
arch/m68knommu/platform/5307/config.c|5
arch/m68knommu/platform/5307/entry.S | 20
arch/m68knommu/platform/5307/ints.c | 23
arch/m68knommu/platform/5307/timers.c| 10
arch/m68knommu/platform/532x/config.c| 46 +
arch/m68knommu/platform/5407/config.c|7
arch/m68knommu/platform/68328/config.c |3
arch/m68knommu/platform/68360/config.c |2
arch/m68knommu/platform/68EZ328/config.c |2
arch/m68knommu/platform/68VZ328/config.c |7
include/asm-m68knommu/dma.h |2
include/asm-m68knommu/hw_irq.h |4
include/asm-m68knommu/m528xsim.h |3
include/asm-m68knommu/m532xsim.h | 85 ++-
include/asm-m68knommu/machdep.h | 50 -
include/asm-m68knommu/mcfuart.h | 11
include/asm-m68knommu/pgtable.h |7
include/asm-m68knommu/timex.h| 24
include/asm-m68knommu/uaccess.h | 11
drivers/net/fec.c| 71 +-
drivers/serial/68328serial.c | 59 --
drivers/serial/mcf.c | 826 +
The only generic stuff is:
Makefile |2
drivers/pci/pci.c|2
fs/binfmt_flat.c |2
fs/namei.c |2
mm/nommu.c | 15
mm/page_alloc.c |8
I looked at those, and had a question:
(copy and paste screws up the formatting, sorry):
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.0 +1000
+++ linux-2.6.21-uc0/fs/namei.c 2007-05-01 17:16:18.0 +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) {
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.
Regards
Greg
Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED]
SnapGear -- a Secure Computing Company PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)
Hi Christoph, Christoph Hellwig wrote: On Wed, May 02, 2007 at 03:23:33PM +1000, Greg Ungerer wrote: Hi All, An update of the uClinux (MMU-less) code against 2.6.21. A lot of cleanups, and a few bug fixes. Any chance you could split this into a few patches and send upstream? m68knommu has gone quite badly out of sync once again. Yes, I have already started the process. I have sent quite a few of these to Linus in the last few hours. Regards Greg -- Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] SnapGear -- a Secure Computing Company PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com - 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/
Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)
On Wed, May 02, 2007 at 03:23:33PM +1000, Greg Ungerer wrote: > Hi All, > > An update of the uClinux (MMU-less) code against 2.6.21. > A lot of cleanups, and a few bug fixes. Any chance you could split this into a few patches and send upstream? m68knommu has gone quite badly out of sync once again. - 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/
Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)
On Wed 2 May 2007 01:23, Greg Ungerer pondered:
> Hi All,
>
> An update of the uClinux (MMU-less) code against 2.6.21.
> A lot of cleanups, and a few bug fixes.
>
> Ahead is more changes to finalize platform device support
> for the new style ColdFire serial driver, and switching to
> the generic irq code.
>
> http://www.uclinux.org/pub/uClinux/uClinux-2.6.x/linux-2.6.21-uc0.patch.gz
Greg:
Is is possible to split out the m68k stuff from the generic nommu stuff? (or
maybe I am missing the point of this patch? - it is for review/inclusion into
the -mm tree, or just for end users wanting to use 2.6.21?)
The patch is labeled uClinux (MMU-less), which I read as generic, but the
majority has to do with only m68knommu.
arch/m68knommu/Kconfig | 12
arch/m68knommu/Makefile |4
arch/m68knommu/kernel/process.c |2
arch/m68knommu/kernel/setup.c| 116 +---
arch/m68knommu/kernel/time.c |9
arch/m68knommu/mm/memory.c | 100 ---
arch/m68knommu/platform/5206/config.c|8
arch/m68knommu/platform/5206e/config.c |7
arch/m68knommu/platform/520x/config.c| 122
arch/m68knommu/platform/523x/config.c|8
arch/m68knommu/platform/5249/config.c| 51 +
arch/m68knommu/platform/5272/config.c|7
arch/m68knommu/platform/527x/config.c|7
arch/m68knommu/platform/528x/config.c|7
arch/m68knommu/platform/5307/config.c|5
arch/m68knommu/platform/5307/entry.S | 20
arch/m68knommu/platform/5307/ints.c | 23
arch/m68knommu/platform/5307/timers.c| 10
arch/m68knommu/platform/532x/config.c| 46 +
arch/m68knommu/platform/5407/config.c|7
arch/m68knommu/platform/68328/config.c |3
arch/m68knommu/platform/68360/config.c |2
arch/m68knommu/platform/68EZ328/config.c |2
arch/m68knommu/platform/68VZ328/config.c |7
include/asm-m68knommu/dma.h |2
include/asm-m68knommu/hw_irq.h |4
include/asm-m68knommu/m528xsim.h |3
include/asm-m68knommu/m532xsim.h | 85 ++-
include/asm-m68knommu/machdep.h | 50 -
include/asm-m68knommu/mcfuart.h | 11
include/asm-m68knommu/pgtable.h |7
include/asm-m68knommu/timex.h| 24
include/asm-m68knommu/uaccess.h | 11
drivers/net/fec.c| 71 +-
drivers/serial/68328serial.c | 59 --
drivers/serial/mcf.c | 826 +
The only generic stuff is:
Makefile |2
drivers/pci/pci.c|2
fs/binfmt_flat.c |2
fs/namei.c |2
mm/nommu.c | 15
mm/page_alloc.c |8
I looked at those, and had a question:
(copy and paste screws up the formatting, sorry):
> 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.0 +1000
> +++ linux-2.6.21-uc0/fs/namei.c 2007-05-01 17:16:18.0 +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) {
I was trying to understand why we don't want to do the same checking on noMMU?
Thanks
-Robin
-
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/
Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)
On Wed 2 May 2007 01:23, Greg Ungerer pondered:
Hi All,
An update of the uClinux (MMU-less) code against 2.6.21.
A lot of cleanups, and a few bug fixes.
Ahead is more changes to finalize platform device support
for the new style ColdFire serial driver, and switching to
the generic irq code.
http://www.uclinux.org/pub/uClinux/uClinux-2.6.x/linux-2.6.21-uc0.patch.gz
Greg:
Is is possible to split out the m68k stuff from the generic nommu stuff? (or
maybe I am missing the point of this patch? - it is for review/inclusion into
the -mm tree, or just for end users wanting to use 2.6.21?)
The patch is labeled uClinux (MMU-less), which I read as generic, but the
majority has to do with only m68knommu.
arch/m68knommu/Kconfig | 12
arch/m68knommu/Makefile |4
arch/m68knommu/kernel/process.c |2
arch/m68knommu/kernel/setup.c| 116 +---
arch/m68knommu/kernel/time.c |9
arch/m68knommu/mm/memory.c | 100 ---
arch/m68knommu/platform/5206/config.c|8
arch/m68knommu/platform/5206e/config.c |7
arch/m68knommu/platform/520x/config.c| 122
arch/m68knommu/platform/523x/config.c|8
arch/m68knommu/platform/5249/config.c| 51 +
arch/m68knommu/platform/5272/config.c|7
arch/m68knommu/platform/527x/config.c|7
arch/m68knommu/platform/528x/config.c|7
arch/m68knommu/platform/5307/config.c|5
arch/m68knommu/platform/5307/entry.S | 20
arch/m68knommu/platform/5307/ints.c | 23
arch/m68knommu/platform/5307/timers.c| 10
arch/m68knommu/platform/532x/config.c| 46 +
arch/m68knommu/platform/5407/config.c|7
arch/m68knommu/platform/68328/config.c |3
arch/m68knommu/platform/68360/config.c |2
arch/m68knommu/platform/68EZ328/config.c |2
arch/m68knommu/platform/68VZ328/config.c |7
include/asm-m68knommu/dma.h |2
include/asm-m68knommu/hw_irq.h |4
include/asm-m68knommu/m528xsim.h |3
include/asm-m68knommu/m532xsim.h | 85 ++-
include/asm-m68knommu/machdep.h | 50 -
include/asm-m68knommu/mcfuart.h | 11
include/asm-m68knommu/pgtable.h |7
include/asm-m68knommu/timex.h| 24
include/asm-m68knommu/uaccess.h | 11
drivers/net/fec.c| 71 +-
drivers/serial/68328serial.c | 59 --
drivers/serial/mcf.c | 826 +
The only generic stuff is:
Makefile |2
drivers/pci/pci.c|2
fs/binfmt_flat.c |2
fs/namei.c |2
mm/nommu.c | 15
mm/page_alloc.c |8
I looked at those, and had a question:
(copy and paste screws up the formatting, sorry):
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.0 +1000
+++ linux-2.6.21-uc0/fs/namei.c 2007-05-01 17:16:18.0 +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) {
I was trying to understand why we don't want to do the same checking on noMMU?
Thanks
-Robin
-
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/
Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)
On Wed, May 02, 2007 at 03:23:33PM +1000, Greg Ungerer wrote: Hi All, An update of the uClinux (MMU-less) code against 2.6.21. A lot of cleanups, and a few bug fixes. Any chance you could split this into a few patches and send upstream? m68knommu has gone quite badly out of sync once again. - 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/
Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)
Hi Christoph, Christoph Hellwig wrote: On Wed, May 02, 2007 at 03:23:33PM +1000, Greg Ungerer wrote: Hi All, An update of the uClinux (MMU-less) code against 2.6.21. A lot of cleanups, and a few bug fixes. Any chance you could split this into a few patches and send upstream? m68knommu has gone quite badly out of sync once again. Yes, I have already started the process. I have sent quite a few of these to Linus in the last few hours. Regards Greg -- Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] SnapGear -- a Secure Computing Company PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com - 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/
Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)
Hi Robin,
Robin Getz wrote:
On Wed 2 May 2007 01:23, Greg Ungerer pondered:
Hi All,
An update of the uClinux (MMU-less) code against 2.6.21.
A lot of cleanups, and a few bug fixes.
Ahead is more changes to finalize platform device support
for the new style ColdFire serial driver, and switching to
the generic irq code.
http://www.uclinux.org/pub/uClinux/uClinux-2.6.x/linux-2.6.21-uc0.patch.gz
Greg:
Is is possible to split out the m68k stuff from the generic nommu stuff?
I could do that. Usually the actual mm changes have been
a pretty small set of this. Often only 1 or 2 patches.
(or
maybe I am missing the point of this patch? - it is for review/inclusion into
the -mm tree, or just for end users wanting to use 2.6.21?)
This is specifically for review and inclusion in main line.
The patch is labeled uClinux (MMU-less), which I read as generic, but the
majority has to do with only m68knommu.
Well, if any non-mmu architecture people sent me patches that
made sense for me to push upstream I would include them here.
But that doesn't happen very often. They generally do it
themselves.
Historically the first -uc patches had m68knommu, h8300 and v850
as well as the non-mmu changes in it.
arch/m68knommu/Kconfig | 12
arch/m68knommu/Makefile |4
arch/m68knommu/kernel/process.c |2
arch/m68knommu/kernel/setup.c| 116 +---
arch/m68knommu/kernel/time.c |9
arch/m68knommu/mm/memory.c | 100 ---
arch/m68knommu/platform/5206/config.c|8
arch/m68knommu/platform/5206e/config.c |7
arch/m68knommu/platform/520x/config.c| 122
arch/m68knommu/platform/523x/config.c|8
arch/m68knommu/platform/5249/config.c| 51 +
arch/m68knommu/platform/5272/config.c|7
arch/m68knommu/platform/527x/config.c|7
arch/m68knommu/platform/528x/config.c|7
arch/m68knommu/platform/5307/config.c|5
arch/m68knommu/platform/5307/entry.S | 20
arch/m68knommu/platform/5307/ints.c | 23
arch/m68knommu/platform/5307/timers.c| 10
arch/m68knommu/platform/532x/config.c| 46 +
arch/m68knommu/platform/5407/config.c|7
arch/m68knommu/platform/68328/config.c |3
arch/m68knommu/platform/68360/config.c |2
arch/m68knommu/platform/68EZ328/config.c |2
arch/m68knommu/platform/68VZ328/config.c |7
include/asm-m68knommu/dma.h |2
include/asm-m68knommu/hw_irq.h |4
include/asm-m68knommu/m528xsim.h |3
include/asm-m68knommu/m532xsim.h | 85 ++-
include/asm-m68knommu/machdep.h | 50 -
include/asm-m68knommu/mcfuart.h | 11
include/asm-m68knommu/pgtable.h |7
include/asm-m68knommu/timex.h| 24
include/asm-m68knommu/uaccess.h | 11
drivers/net/fec.c| 71 +-
drivers/serial/68328serial.c | 59 --
drivers/serial/mcf.c | 826 +
The only generic stuff is:
Makefile |2
drivers/pci/pci.c|2
fs/binfmt_flat.c |2
fs/namei.c |2
mm/nommu.c | 15
mm/page_alloc.c |8
I looked at those, and had a question:
(copy and paste screws up the formatting, sorry):
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.0 +1000
+++ linux-2.6.21-uc0/fs/namei.c 2007-05-01 17:16:18.0 +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) {
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.
Regards
Greg
Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED]
SnapGear -- a Secure Computing Company PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
[PATCH]: linux-2.6.21-uc0 (MMU-less updates)
Hi All, An update of the uClinux (MMU-less) code against 2.6.21. A lot of cleanups, and a few bug fixes. Ahead is more changes to finalize platform device support for the new style ColdFire serial driver, and switching to the generic irq code. http://www.uclinux.org/pub/uClinux/uClinux-2.6.x/linux-2.6.21-uc0.patch.gz Change log: . Arctururs UC5272 and UC5282 board supportDavid Wu . use THREAD_SIZE for stack manipulation Philippe De Muyter . remove dead code from setup.cGreg Ungerer . remove dead cache code from mm Greg Ungerer . remove useless is_in_rom() Greg Ungerer . consolidate fixed bootparam code Greg Ungerer . no need to preserve THREAD_SR in resume Philippe De Muyter . implement irq_regs in interrupt service Greg Ungerer . remove machine specific irq code Greg Ungerer . fix timer step count for ColdFirePhilippe De Muyter . add chip select mappings for cobra5329 Thomas Brinker . remove old machine specific clock definesGreg Ungerer . improve readability of fec driver code Philippe De Muyter . do not read ICR before writing in fec driver Philippe De Muyter . fix INIT_WORK usage in fec driverGreg Ungerer . remove legacy PM code in 68328 serial driver Greg Ungerer . fix errno reporting in binfmt_flat loaderPhilippe De Muyter . create hw_irq.h for m68knommuGreg Ungerer . fix CLOCK_TICK_RATE for m68knommuPhilippe De Muyter . add expand_stack() funtcion to nommu Greg Ungerer . move to platform device setup for 520x Greg Ungerer . move to platform device setup for 5249 Greg Ungerer . new style serial driver for ColdFire UARTGreg Ungerer . add QSPI defines for 528x ColdFire parts David Wu . improve SoC device defines for 523x ColdFire Thomas Brinker Regards Greg Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] SnapGear -- a division of Secure Computing PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com - 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/
[PATCH]: linux-2.6.21-uc0 (MMU-less updates)
Hi All, An update of the uClinux (MMU-less) code against 2.6.21. A lot of cleanups, and a few bug fixes. Ahead is more changes to finalize platform device support for the new style ColdFire serial driver, and switching to the generic irq code. http://www.uclinux.org/pub/uClinux/uClinux-2.6.x/linux-2.6.21-uc0.patch.gz Change log: . Arctururs UC5272 and UC5282 board supportDavid Wu . use THREAD_SIZE for stack manipulation Philippe De Muyter . remove dead code from setup.cGreg Ungerer . remove dead cache code from mm Greg Ungerer . remove useless is_in_rom() Greg Ungerer . consolidate fixed bootparam code Greg Ungerer . no need to preserve THREAD_SR in resume Philippe De Muyter . implement irq_regs in interrupt service Greg Ungerer . remove machine specific irq code Greg Ungerer . fix timer step count for ColdFirePhilippe De Muyter . add chip select mappings for cobra5329 Thomas Brinker . remove old machine specific clock definesGreg Ungerer . improve readability of fec driver code Philippe De Muyter . do not read ICR before writing in fec driver Philippe De Muyter . fix INIT_WORK usage in fec driverGreg Ungerer . remove legacy PM code in 68328 serial driver Greg Ungerer . fix errno reporting in binfmt_flat loaderPhilippe De Muyter . create hw_irq.h for m68knommuGreg Ungerer . fix CLOCK_TICK_RATE for m68knommuPhilippe De Muyter . add expand_stack() funtcion to nommu Greg Ungerer . move to platform device setup for 520x Greg Ungerer . move to platform device setup for 5249 Greg Ungerer . new style serial driver for ColdFire UARTGreg Ungerer . add QSPI defines for 528x ColdFire parts David Wu . improve SoC device defines for 523x ColdFire Thomas Brinker Regards Greg Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] SnapGear -- a division of Secure Computing PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com - 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/
