Messages in this thread Patches in this message | | | Date | Sun, 1 Aug 1999 19:05:06 +0200 (CEST) | From | Andrea Arcangeli <> | Subject | Re: Linux 2.2.11pre4 |
| |
In pre4 you included this:
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/
| |