diff -u --new-file --recursive --exclude-from exclude linux.11p3/mm/mmap.c linux.ac/mm/mmap.c
--- linux.11p3/mm/mmap.c Tue May 4 18:44:38 1999
+++ linux.ac/mm/mmap.c Sat Jul 31 16:42:23 1999
@@ -359,8 +359,11 @@
if (len > TASK_SIZE)
return 0;
- if (!addr)
- addr = TASK_UNMAPPED_BASE;
+ if (!addr) {
+ addr = current->rlim[RLIMIT_DATA].rlim_cur;
+ if (addr >= RLIM_INFINITY)
+ addr = TASK_UNMAPPED_BASE;
+ }
addr = PAGE_ALIGN(addr);
for (vmm = find_vma(current->mm, addr); ; vmm = vmm->vm_next) {
Hmm this patch looks wrong. Think if you set the rlimit value to
0x7ffffff0. Then addr will be < of RLIM_INFINITY so you'll left `addr'
equal to 0x7ffffff0. In a 2giga-mem setup 0x8000000 will just be in kernel
space so there will be only 16 byte for the data segment, but rlimit set
to 0x7ffffff0 would mean that you allowed 0x7ffffff0 bytes to be allocated
(and not only 16 bytes) in the data segment.
The max _size_ of the stack segment should have nothing to do with the
_offset_ at which the data is allocated.
A check of the data segment limit is just done here:
/* Check against rlimit and stack.. */
rlim = current->rlim[RLIMIT_DATA].rlim_cur;
if (rlim < RLIM_INFINITY && brk - mm->end_code > rlim)
goto out;
BTW, in pre4 this ext2 bug I pointed out last week is still present, here
it is the patch:
--- 2.2.11-pre4/fs/ext2/file.c Sun Aug 1 19:03:17 1999
+++ /tmp/file.c Sun Aug 1 19:04:07 1999
@@ -229,7 +229,7 @@
if (!count)
return -EFBIG;
}
- if (((pos + count) >> 33) &&
+ if (((pos + count) >> 31) &&
!(sb->u.ext2_sb.s_es->s_feature_ro_compat &
cpu_to_le32(EXT2_FEATURE_RO_COMPAT_LARGE_FILE))) {
/* If this is the first large file created, add a flag
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/