Discussion:
TASK_SIZE for !MMU
Uwe Kleine-König
2014-04-29 10:00:28 UTC
Permalink
Hello,

I grepped through the kernel (v3.15-rc1) for usages of TASK_SIZE to
check if/how it is used on !MMU ARM machines. Most open questions also
affect the other !MMU platforms, so I put the blackfin, c6x, frv and
m32r, m68k, microblaze and xtensa lists on Cc:. (Did I miss a platform
that cares for !MMU ?)

Most occurences are fine, see the list at the end of this mail. However
some are not or are unclear to me. Here is the complete list[1] apart f=
rom
the definition of TASK_SIZE for !MMU in arch/arm/include/asm/memory.h:

- Probably this should be explict s/TASK_SIZE/CONFIG_DRAM_SIZE/. This
is generic code however while CONFIG_DRAM_SIZE is ARM only.
mm/nommu.c: if (!rlen || rlen > TASK_SIZE)

- The issue the patch by Rabin is addressing (Subject: [PATCH] ARM: fi=
x
string functions on !MMU), alternatively make TASK_SIZE ~0UL.
arch/arm/include/asm/uaccess.h:#define user_addr_max() \
arch/arm/include/asm/uaccess.h: (segment_eq(get_fs(), USER_DS) =
? TASK_SIZE : ~0UL)

- probably bearable if broken:
drivers/misc/lkdtm.c: if (user_addr >=3D TASK_SIZE) {
lib/test_user_copy.c: user_addr =3D vm_mmap(...)
lib/test_user_copy.c: if (user_addr >=3D (unsigned long)(TASK=
_SIZE)) {
lib/test_user_copy.c: pr_warn("Failed to allocate use=
r memory\n");
lib/test_user_copy.c: return -ENOMEM;

- unclear to me:
fs/exec.c: current->mm->task_size =3D TASK_SIZE;
- depends on PERF_EVENTS
kernel/events/core.c: if (!addr || addr >=3D TASK_SIZE)
kernel/events/core.c: return TASK_SIZE - addr;
kernel/events/uprobes.c: area->vaddr =3D get_unm=
apped_area(NULL, TASK_SIZE - PAGE_SIZE,
- depends on (PERF_EVENTS && (CPU_V6 || CPU_V6K || CPU_V7)):
arch/arm/kernel/hw_breakpoint.c: return (va >=3D TASK_SI=
ZE) && ((va + len - 1) >=3D TASK_SIZE);
- seems to cope with big TASK_SIZE
fs/namespace.c: size =3D TASK_SIZE - (unsigned long)data=
;
fs/namespace.c: if (size > PAGE_SIZE)
fs/namespace.c: size =3D PAGE_SIZE;
- depends on PLAT_S5P || ARCH_EXYNOS, this looks wrong
drivers/media/platform/s5p-mfc/s5p_mfc_common.h:#define DST_QUE=
UE_OFF_BASE (TASK_SIZE / 2)
- used for prctl(PR_SET_MM, ...)
kernel/sys.c: if (addr >=3D TASK_SIZE || addr < mmap_min_addr=
)

Any help to judge if these are OK is appreciated (even from Will :-)

I think it would be OK to define TASK_SIZE to 0xffffffff for !MMU.
blackfin, frv and m68k also do this. c6x does define it to 0xFFFFF000 t=
o
leave space for error codes.

Thoughts?

Best regards
Uwe

[1] complete as in "skip everything below arch/ but arch/arm" :-)

=3D=3D=3D=3D=3D=3D=3D These occurences are fine =3D=3D=3D=3D=3D=3D=3D
mmu-only:
arch/arm/include/asm/memory.h: * TASK_SIZE - the maximum size o=
f a user space task.
arch/arm/include/asm/memory.h:#define TASK_SIZE (UL(CON=
=46IG_PAGE_OFFSET) - UL(SZ_16M))
arch/arm/include/asm/memory.h:#define TASK_UNMAPPED_BASE =
ALIGN(TASK_SIZE / 3, SZ_16M)
arch/arm/include/asm/memory.h:#define TASK_SIZE_26 =
(UL(1) << 26)
arch/arm/include/asm/memory.h: * The module space lives between=
the addresses given by TASK_SIZE
arch/arm/include/asm/memory.h:#if TASK_SIZE > MODULES_VADDR
arch/arm/include/asm/pgtable-2level.h:#define USER_PTRS_PER_PGD=
(TASK_SIZE / PGDIR_SIZE)
arch/arm/include/asm/pgtable-3level.h: BUG_ON(addr >=3D TASK_S=
IZE);
arch/arm/include/asm/pgtable.h: * Use TASK_SIZE as the ceiling =
argument for free_pgtables() and
arch/arm/include/asm/pgtable.h:#define USER_PGTABLES_CEILING =
TASK_SIZE
arch/arm/include/asm/pgtable.h: if (addr < TASK_SIZE && pte_val=
id_user(pteval)) {
arch/arm/include/asm/tlb.h: tlb->range_start =3D TA=
SK_SIZE;
arch/arm/include/asm/tlb.h: tlb->range_start =3D TA=
SK_SIZE;
arch/arm/kernel/entry-armv.S: cmp r4, #TASK_SIZE
arch/arm/mm/fault.c: if (addr < TASK_SIZE)
arch/arm/mm/init.c: BUILD_BUG_ON(TASK_SIZE =
MODULES_VADDR);
arch/arm/mm/init.c: BUG_ON(TASK_SIZE =
MODULES_VADDR);
arch/arm/mm/mmap.c:#define MAX_GAP ((TASK_SIZE)/6*5)
arch/arm/mm/mmap.c: return PAGE_ALIGN(TASK_SIZE - gap - rnd=
);
arch/arm/mm/mmap.c: if (len > TASK_SIZE)
arch/arm/mm/mmap.c: if (TASK_SIZE - len >=3D addr &=
&
arch/arm/mm/mmap.c: info.high_limit =3D TASK_SIZE;
arch/arm/mm/mmap.c: if (len > TASK_SIZE)
arch/arm/mm/mmap.c: if (TASK_SIZE - len >=3D addr &=
&
arch/arm/mm/mmap.c: info.high_limit =3D TASK_SIZE;
arch/arm/mm/mmu.c: if (md->virtual !=3D vectors_base() && =
md->virtual < TASK_SIZE) {
arch/arm/include/asm/uaccess.h:#define USER_DS TASK_SI=
ZE
mm/memory.c: if (pg > TASK_SIZE)
mm/mlock.c: mm_populate(0, TASK_SIZE);
mm/mmap.c: if (len > TASK_SIZE - mmap_min_addr)
mm/mmap.c: if (TASK_SIZE - len >=3D addr && addr >=
=3D mmap_min_addr &&
mm/mmap.c: info.high_limit =3D TASK_SIZE;
mm/mmap.c: if (len > TASK_SIZE - mmap_min_addr)
mm/mmap.c: if (TASK_SIZE - len >=3D addr && addr >=
=3D mmap_min_addr &&
mm/mmap.c: info.high_limit =3D TASK_SIZE;
mm/mmap.c: if (len > TASK_SIZE)
mm/mmap.c: if (addr > TASK_SIZE - len)
mm/mmap.c: if ((start & ~PAGE_MASK) || start > TASK_SIZE |=
| len > TASK_SIZE
mm/mremap.c: if (new_len > TASK_SIZE || new_addr > TASK_SIZE=
- new_len)

enabled by CONFIG_NUMA, unavailable on ARM:
mm/mempolicy.c: pvma.vm_end =3D TASK_SIZE; /* po=
licy covers entire

Only used in fs/exec.c in #ifdef CONFIG_MMU:
arch/arm/include/asm/processor.h:#define STACK_TOP_MAX TASK_SI=
ZE

Used in:
- fs/binfmt_aout.c (HAVE_AOUT=3Dn on ARM)
- fs/binfmt_elf.c (depends on MMU)
- fs/binfmt_som.c (BINFMT_SOM depends on PARISC && HPUX)
- fs/exec.c (#ifdef CONFIG_MMU)
arch/arm/include/asm/processor.h:#define STACK_TOP ((curr=
ent->personality & ADDR_LIMIT_32BIT) ? \
arch/arm/include/asm/processor.h: TASK_S=
IZE : TASK_SIZE_26)

Only used in fs/{,compat_}binfmt_elf.c, depends on MMU
arch/arm/include/asm/elf.h:#define ELF_ET_DYN_BASE (2 * TA=
SK_SIZE / 3)

fs/binfmt_aout.c (HAVE_AOUT=3Dn on ARM)
fs/binfmt_aout.c:#define BAD_ADDR(x) ((unsigned long)(x) >=3D=
TASK_SIZE)
fs/binfmt_elf.c (depends on MMU)
fs/binfmt_elf.c:#define BAD_ADDR(x) ((unsigned long)(x) >=3D TA=
SK_SIZE)
fs/binfmt_elf.c: eppnt->p_memsz > TA=
SK_SIZE ||
fs/binfmt_elf.c: TASK_SIZE - eppnt->=
p_memsz < k) {
fs/binfmt_elf.c: elf_ppnt->p_memsz > TASK_SI=
ZE ||
fs/binfmt_elf.c: TASK_SIZE - elf_ppnt->p_mem=
sz < k) {

HUGETLBFS depends on !ARM || ARM_LPAE || BROKEN, LPAE depends on MMU
fs/hugetlbfs/inode.c: if (len > TASK_SIZE)
fs/hugetlbfs/inode.c: if (TASK_SIZE - len >=3D addr &=
&
fs/hugetlbfs/inode.c: info.high_limit =3D TASK_SIZE;

USER_DS is defined in arch/arm/include/asm/uaccess.h:
include/asm-generic/uaccess.h:#ifndef USER_DS
include/asm-generic/uaccess.h:#define USER_DS MAKE_MM=
_SEG(TASK_SIZE -
include/asm-generic/uaccess.h:#endif

Only used in fs/proc/task_mmu.c, depends on CONFIG_MMU
include/linux/sched.h:#define TASK_SIZE_OF(tsk) TASK_SIZE

--=20
Pengutronix e.K. | Uwe Kleine-K=F6nig =
|
Industrial Linux Solutions | http://www.pengutronix.de/=
|
Uwe Kleine-König
2014-06-02 08:51:50 UTC
Permalink
Hello

[expand Cc: a bit]
Post by Uwe Kleine-König
I grepped through the kernel (v3.15-rc1) for usages of TASK_SIZE to
check if/how it is used on !MMU ARM machines. Most open questions als=
o
Post by Uwe Kleine-König
affect the other !MMU platforms, so I put the blackfin, c6x, frv and
m32r, m68k, microblaze and xtensa lists on Cc:. (Did I miss a platfor=
m
Post by Uwe Kleine-König
that cares for !MMU ?)
=20
Most occurences are fine, see the list at the end of this mail. Howev=
er
Post by Uwe Kleine-König
some are not or are unclear to me. Here is the complete list[1] apart=
from
Post by Uwe Kleine-König
the definition of TASK_SIZE for !MMU in arch/arm/include/asm/memory.h=
=20
- Probably this should be explict s/TASK_SIZE/CONFIG_DRAM_SIZE/. Thi=
s
Post by Uwe Kleine-König
is generic code however while CONFIG_DRAM_SIZE is ARM only.
mm/nommu.c: if (!rlen || rlen > TASK_SIZE)
=20
- The issue the patch by Rabin is addressing (Subject: [PATCH] ARM: =
fix
Post by Uwe Kleine-König
string functions on !MMU), alternatively make TASK_SIZE ~0UL.
arch/arm/include/asm/uaccess.h:#define user_addr_max() \
arch/arm/include/asm/uaccess.h: (segment_eq(get_fs(), USER_DS=
) ? TASK_SIZE : ~0UL)
[reference: http://www.spinics.net/lists/arm-kernel/msg324112.html ]
=20
Post by Uwe Kleine-König
drivers/misc/lkdtm.c: if (user_addr >=3D TASK_SIZE)=
{
Post by Uwe Kleine-König
lib/test_user_copy.c: user_addr =3D vm_mmap(...)
lib/test_user_copy.c: if (user_addr >=3D (unsigned long)(TA=
SK_SIZE)) {
Post by Uwe Kleine-König
lib/test_user_copy.c: pr_warn("Failed to allocate u=
ser memory\n");
Post by Uwe Kleine-König
lib/test_user_copy.c: return -ENOMEM;
=20
fs/exec.c: current->mm->task_size =3D TASK_SIZE;
- depends on PERF_EVENTS
kernel/events/core.c: if (!addr || addr >=3D TASK_SIZE)
kernel/events/core.c: return TASK_SIZE - addr;
kernel/events/uprobes.c: area->vaddr =3D get_u=
nmapped_area(NULL, TASK_SIZE - PAGE_SIZE,
Post by Uwe Kleine-König
arch/arm/kernel/hw_breakpoint.c: return (va >=3D TASK_=
SIZE) && ((va + len - 1) >=3D TASK_SIZE);
Post by Uwe Kleine-König
- seems to cope with big TASK_SIZE
fs/namespace.c: size =3D TASK_SIZE - (unsigned long)da=
ta;
Post by Uwe Kleine-König
fs/namespace.c: if (size > PAGE_SIZE)
fs/namespace.c: size =3D PAGE_SIZE;
- depends on PLAT_S5P || ARCH_EXYNOS, this looks wrong
drivers/media/platform/s5p-mfc/s5p_mfc_common.h:#define DST_Q=
UEUE_OFF_BASE (TASK_SIZE / 2)
Post by Uwe Kleine-König
- used for prctl(PR_SET_MM, ...)
kernel/sys.c: if (addr >=3D TASK_SIZE || addr < mmap_min_ad=
dr)
Post by Uwe Kleine-König
=20
Any help to judge if these are OK is appreciated (even from Will :-)
=20
I think it would be OK to define TASK_SIZE to 0xffffffff for !MMU.
blackfin, frv and m68k also do this. c6x does define it to 0xFFFFF000=
to
Post by Uwe Kleine-König
leave space for error codes.
=20
Thoughts?
The problem is that current linus/master (and also next) doesn't boot o=
n
my ARM-nommu machine because the user string functions (strnlen_user,
strncpy_from_user et al.) refuse to work on strings above TASK_SIZE
which in my case also includes the XIP kernel image.

Maybe someone of the mm people can bring light into the unclear points
above and the question what TASK_SIZE is supposed to be on no-MMU
machines?

Best regards
Uwe
Post by Uwe Kleine-König
[1] complete as in "skip everything below arch/ but arch/arm" :-)
=20
[removed the list, if you're interested, it's available at
http://mid.gmane.org/***@pengutronix.de]

--=20
Pengutronix e.K. | Uwe Kleine-K=F6nig =
|
Industrial Linux Solutions | http://www.pengutronix.de/=
|
Greg Ungerer
2014-06-03 12:14:55 UTC
Permalink
Hi Uwe,
Post by Uwe Kleine-König
Hello
[expand Cc: a bit]
Post by Uwe Kleine-König
I grepped through the kernel (v3.15-rc1) for usages of TASK_SIZE to
check if/how it is used on !MMU ARM machines. Most open questions al=
so
Post by Uwe Kleine-König
Post by Uwe Kleine-König
affect the other !MMU platforms, so I put the blackfin, c6x, frv and
m32r, m68k, microblaze and xtensa lists on Cc:. (Did I miss a platfo=
rm
Post by Uwe Kleine-König
Post by Uwe Kleine-König
that cares for !MMU ?)
Most occurences are fine, see the list at the end of this mail. Howe=
ver
Post by Uwe Kleine-König
Post by Uwe Kleine-König
some are not or are unclear to me. Here is the complete list[1] apar=
t from
Post by Uwe Kleine-König
Post by Uwe Kleine-König
the definition of TASK_SIZE for !MMU in arch/arm/include/asm/memory.=
- Probably this should be explict s/TASK_SIZE/CONFIG_DRAM_SIZE/. T=
his
Post by Uwe Kleine-König
Post by Uwe Kleine-König
is generic code however while CONFIG_DRAM_SIZE is ARM only.
mm/nommu.c: if (!rlen || rlen > TASK_SIZE)
- The issue the patch by Rabin is addressing (Subject: [PATCH] ARM=
: fix
Post by Uwe Kleine-König
Post by Uwe Kleine-König
string functions on !MMU), alternatively make TASK_SIZE ~0UL.
arch/arm/include/asm/uaccess.h:#define user_addr_max() \
arch/arm/include/asm/uaccess.h: (segment_eq(get_fs(), USER_=
DS) ? TASK_SIZE : ~0UL)
Post by Uwe Kleine-König
[reference: http://www.spinics.net/lists/arm-kernel/msg324112.html ]
Post by Uwe Kleine-König
drivers/misc/lkdtm.c: if (user_addr >=3D TASK_SIZ=
E) {
Post by Uwe Kleine-König
Post by Uwe Kleine-König
lib/test_user_copy.c: user_addr =3D vm_mmap(...)
lib/test_user_copy.c: if (user_addr >=3D (unsigned long)(=
TASK_SIZE)) {
Post by Uwe Kleine-König
Post by Uwe Kleine-König
lib/test_user_copy.c: pr_warn("Failed to allocate=
user memory\n");
Post by Uwe Kleine-König
Post by Uwe Kleine-König
lib/test_user_copy.c: return -ENOMEM;
fs/exec.c: current->mm->task_size =3D TASK_SIZE;
- depends on PERF_EVENTS
kernel/events/core.c: if (!addr || addr >=3D TASK_SIZE)
kernel/events/core.c: return TASK_SIZE - addr;
kernel/events/uprobes.c: area->vaddr =3D get=
_unmapped_area(NULL, TASK_SIZE - PAGE_SIZE,
Post by Uwe Kleine-König
Post by Uwe Kleine-König
arch/arm/kernel/hw_breakpoint.c: return (va >=3D TAS=
K_SIZE) && ((va + len - 1) >=3D TASK_SIZE);
Post by Uwe Kleine-König
Post by Uwe Kleine-König
- seems to cope with big TASK_SIZE
fs/namespace.c: size =3D TASK_SIZE - (unsigned long)=
data;
Post by Uwe Kleine-König
Post by Uwe Kleine-König
fs/namespace.c: if (size > PAGE_SIZE)
fs/namespace.c: size =3D PAGE_SIZE;
- depends on PLAT_S5P || ARCH_EXYNOS, this looks wrong
drivers/media/platform/s5p-mfc/s5p_mfc_common.h:#define DST=
_QUEUE_OFF_BASE (TASK_SIZE / 2)
Post by Uwe Kleine-König
Post by Uwe Kleine-König
- used for prctl(PR_SET_MM, ...)
kernel/sys.c: if (addr >=3D TASK_SIZE || addr < mmap_min_=
addr)
Post by Uwe Kleine-König
Post by Uwe Kleine-König
Any help to judge if these are OK is appreciated (even from Will :-)
I think it would be OK to define TASK_SIZE to 0xffffffff for !MMU.
blackfin, frv and m68k also do this. c6x does define it to 0xFFFFF00=
0 to
Post by Uwe Kleine-König
Post by Uwe Kleine-König
leave space for error codes.
I did that same change for m68k in commit cc24c40 ("m68knommu: remove
size limit on non-MMU TASK_SIZE"). For similar reasons as you need to
now.
Post by Uwe Kleine-König
Post by Uwe Kleine-König
Thoughts?
The problem is that current linus/master (and also next) doesn't boot=
on
Post by Uwe Kleine-König
my ARM-nommu machine because the user string functions (strnlen_user,
strncpy_from_user et al.) refuse to work on strings above TASK_SIZE
which in my case also includes the XIP kernel image.
I seem to recall that we were not considering flash or anything else
other than RAM when defining that original TASK_SIZE (back many, many
years ago). Some of the address checks you list above made some sense
if you had everything in RAM (though only upper bounds are checked).
The thinking was some checking is better than none I suppose.

Setting a hard coded memory size in CONFIG_DRAM_SIZE is not all that
fantastic either...

Regards
Greg
Post by Uwe Kleine-König
Maybe someone of the mm people can bring light into the unclear point=
s
Post by Uwe Kleine-König
above and the question what TASK_SIZE is supposed to be on no-MMU
machines?
Best regards
Uwe
Post by Uwe Kleine-König
[1] complete as in "skip everything below arch/ but arch/arm" :-)
[removed the list, if you're interested, it's available at
Uwe Kleine-König
2014-06-03 14:11:38 UTC
Permalink
Hello Greg,

thanks for your reply.
Post by Greg Ungerer
Post by Uwe Kleine-König
I think it would be OK to define TASK_SIZE to 0xffffffff for !MMU.
blackfin, frv and m68k also do this. c6x does define it to 0xFFFFF0=
00 to
Post by Greg Ungerer
Post by Uwe Kleine-König
leave space for error codes.
=20
I did that same change for m68k in commit cc24c40 ("m68knommu: remove
size limit on non-MMU TASK_SIZE"). For similar reasons as you need to
now.
ok.
=20
Post by Greg Ungerer
Post by Uwe Kleine-König
Thoughts?
The problem is that current linus/master (and also next) doesn't boo=
t on
Post by Greg Ungerer
my ARM-nommu machine because the user string functions (strnlen_user=
,
Post by Greg Ungerer
strncpy_from_user et al.) refuse to work on strings above TASK_SIZE
which in my case also includes the XIP kernel image.
=20
I seem to recall that we were not considering flash or anything else
other than RAM when defining that original TASK_SIZE (back many, many
years ago). Some of the address checks you list above made some sense
if you had everything in RAM (though only upper bounds are checked).
The thinking was some checking is better than none I suppose.
What is the actual meaning of TASK_SIZE? The maximal value of a valid
userspace address?
Post by Greg Ungerer
Setting a hard coded memory size in CONFIG_DRAM_SIZE is not all that
fantastic either...
Not sure what you mean? Having CONFIG_DRAM_SIZE at all or use it for
boundary checking?

CONFIG_DRAM_SIZE is hardly used apart from defining TASK_SIZE:

- #define END_MEM (UL(CONFIG_DRAM_BASE) + CONFIG_DRAM_SIZE)
which is only used to define MODULES_END. Ap
- Some memory configuration using cp15 registers in
arch/arm/mm/proc-arm{740,940,946}.S

=46or the former I'd say better use 0xffffffff, too. For the latter I
wonder if we should just drop CPU_ARM740T, CPU_ARM940T and CPU_ARM946E.
These are only selectable if ARCH_INTEGRATOR and are not selected by
other symbols. As ARCH_INTEGRATOR selects ARM_PATCH_PHYS_VIRT since
commit fe9891454473 (ARM: integrator: Default enable
ARM_PATCH_PHYS_VIRT, AUTO_ZRELADDR) for Linux 3.13 and
ARM_PATCH_PHYS_VIRT depends on MMU the Integrator-noMMU targets are
broken anyhow.

I will prepare a patch series with some cleanups.

Best regards
Uwe

--=20
Pengutronix e.K. | Uwe Kleine-K=F6nig =
|
Industrial Linux Solutions | http://www.pengutronix.de/=
|
Geert Uytterhoeven
2014-06-03 15:19:56 UTC
Permalink
On Tue, Jun 3, 2014 at 4:11 PM, Uwe Kleine-K=C3=B6nig
Post by Uwe Kleine-König
I did that same change for m68k in commit cc24c40 ("m68knommu: remov=
e
Post by Uwe Kleine-König
size limit on non-MMU TASK_SIZE"). For similar reasons as you need t=
o
Post by Uwe Kleine-König
now.
ok.
Post by Uwe Kleine-König
Thoughts?
The problem is that current linus/master (and also next) doesn't bo=
ot on
Post by Uwe Kleine-König
my ARM-nommu machine because the user string functions (strnlen_use=
r,
Post by Uwe Kleine-König
strncpy_from_user et al.) refuse to work on strings above TASK_SIZE
which in my case also includes the XIP kernel image.
I seem to recall that we were not considering flash or anything else
other than RAM when defining that original TASK_SIZE (back many, man=
y
Post by Uwe Kleine-König
years ago). Some of the address checks you list above made some sens=
e
Post by Uwe Kleine-König
if you had everything in RAM (though only upper bounds are checked).
The thinking was some checking is better than none I suppose.
What is the actual meaning of TASK_SIZE? The maximal value of a valid
userspace address?
Yes

$ git show cc24c40
commit cc24c405949e3d4418a90014d10166679d78141a
Author: Greg Ungerer <***@uclinux.org>
Date: Mon May 24 11:22:05 2010 +1000

m68knommu: remove size limit on non-MMU TASK_SIZE

The TASK_SIZE define is used in some places as a limit on the size =
of
the virtual address space of a process. On non-MMU systems those ad=
dresses
used in comparison will be physical addresses, and they could be an=
ywhere
in the 32bit physical address space. So for !CONFIG_MMU systems set=
the
TASK_SIZE to the maximum physical address.

Signed-off-by: Greg Ungerer <***@uclinux.org>

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ***@linux-=
m68k.org

In personal conversations with technical people, I call myself a hacker=
=2E But
when I'm talking to journalists I just say "programmer" or something li=
ke that.
-- Linus Torvalds
Geert Uytterhoeven
2014-06-03 15:19:56 UTC
Permalink
On Tue, Jun 3, 2014 at 4:11 PM, Uwe Kleine-König
Post by Uwe Kleine-König
Post by Greg Ungerer
I did that same change for m68k in commit cc24c40 ("m68knommu: remove
size limit on non-MMU TASK_SIZE"). For similar reasons as you need to
now.
ok.
Post by Greg Ungerer
Post by Uwe Kleine-König
Thoughts?
The problem is that current linus/master (and also next) doesn't boot on
my ARM-nommu machine because the user string functions (strnlen_user,
strncpy_from_user et al.) refuse to work on strings above TASK_SIZE
which in my case also includes the XIP kernel image.
I seem to recall that we were not considering flash or anything else
other than RAM when defining that original TASK_SIZE (back many, many
years ago). Some of the address checks you list above made some sense
if you had everything in RAM (though only upper bounds are checked).
The thinking was some checking is better than none I suppose.
What is the actual meaning of TASK_SIZE? The maximal value of a valid
userspace address?
Yes

$ git show cc24c40
commit cc24c405949e3d4418a90014d10166679d78141a
Author: Greg Ungerer <***@uclinux.org>
Date: Mon May 24 11:22:05 2010 +1000

m68knommu: remove size limit on non-MMU TASK_SIZE

The TASK_SIZE define is used in some places as a limit on the size of
the virtual address space of a process. On non-MMU systems those addresses
used in comparison will be physical addresses, and they could be anywhere
in the 32bit physical address space. So for !CONFIG_MMU systems set the
TASK_SIZE to the maximum physical address.

Signed-off-by: Greg Ungerer <***@uclinux.org>

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ***@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Greg Ungerer
2014-06-04 11:57:40 UTC
Permalink
Hi Uwe,
Post by Uwe Kleine-König
Post by Uwe Kleine-König
I think it would be OK to define TASK_SIZE to 0xffffffff for !MMU.
blackfin, frv and m68k also do this. c6x does define it to 0xFFFFF=
000 to
Post by Uwe Kleine-König
Post by Uwe Kleine-König
leave space for error codes.
I did that same change for m68k in commit cc24c40 ("m68knommu: remov=
e
Post by Uwe Kleine-König
size limit on non-MMU TASK_SIZE"). For similar reasons as you need t=
o
Post by Uwe Kleine-König
now.
ok.
Post by Uwe Kleine-König
Thoughts?
The problem is that current linus/master (and also next) doesn't bo=
ot on
Post by Uwe Kleine-König
my ARM-nommu machine because the user string functions (strnlen_use=
r,
Post by Uwe Kleine-König
strncpy_from_user et al.) refuse to work on strings above TASK_SIZE
which in my case also includes the XIP kernel image.
I seem to recall that we were not considering flash or anything else
other than RAM when defining that original TASK_SIZE (back many, man=
y
Post by Uwe Kleine-König
years ago). Some of the address checks you list above made some sens=
e
Post by Uwe Kleine-König
if you had everything in RAM (though only upper bounds are checked).
The thinking was some checking is better than none I suppose.
What is the actual meaning of TASK_SIZE? The maximal value of a valid
userspace address?
Yes (as Geert pointed out :-)
The limit of virtual userspace addresses.
Post by Uwe Kleine-König
Setting a hard coded memory size in CONFIG_DRAM_SIZE is not all that
fantastic either...
Not sure what you mean? Having CONFIG_DRAM_SIZE at all or use it for
boundary checking?
Having the DRAM size be a configure time constant. And as you have
found RAM isn't the only place in the physical address space that
code will necessarily access.
Post by Uwe Kleine-König
- #define END_MEM (UL(CONFIG_DRAM_BASE) + CONFIG_DRAM_SIZE)
which is only used to define MODULES_END. Ap
- Some memory configuration using cp15 registers in
arch/arm/mm/proc-arm{740,940,946}.S
For the former I'd say better use 0xffffffff, too. For the latter I
wonder if we should just drop CPU_ARM740T, CPU_ARM940T and CPU_ARM946=
E.
Post by Uwe Kleine-König
These are only selectable if ARCH_INTEGRATOR and are not selected by
other symbols. As ARCH_INTEGRATOR selects ARM_PATCH_PHYS_VIRT since
commit fe9891454473 (ARM: integrator: Default enable
ARM_PATCH_PHYS_VIRT, AUTO_ZRELADDR) for Linux 3.13 and
ARM_PATCH_PHYS_VIRT depends on MMU the Integrator-noMMU targets are
broken anyhow.
I will prepare a patch series with some cleanups.
I have no idea how many people would be using those older ARM CPU types=
=2E
It was hard to get much interest for them in mainline even years ago.

Regards
Greg

Loading...