> ---------------------------------------------------------------------- > arch/x86/kernel/syscall_table_32.S: > ... > 194 .long sys_mmap_pgoff > ... > > mm/mmap.c: > 1080 SYSCALL_DEFINE6(mmap_pgoff, unsigned long, addr, unsigned long, len, > 1081 unsigned long, prot, unsigned long, flags, > 1082 unsigned long, fd, unsigned long, pgoff) > ... > 1111 down_write(¤t->mm->mmap_sem); > 1112 retval = do_mmap_pgoff(file, addr, len, prot, flags, pgoff); > 1113 up_write(¤t->mm->mmap_sem); > ---------------------------------------------------------------------- > >> value. We have >> no reason to make artificial limit. Why don't you meke a overflow >> check in sys_mmap()? > > I consider it is better to make an overflow check in do_mmap_pgoff. > There are two reasons: > > 1. If we make an overflow check in the entrance of system call, we > have to check in sys_mmap for x86_64 and in sys_mmap_pgoff for > x86. It means that we have to check for each architecture > individually. Therefore, it is more effective to make an > overflow check in do_mmap_pgoff because both sys_mmap and > sys_mmap_pgoff call do_mmap_pgoff. arch/x86/include/asm/posix_types_32.h --------------------------------------------- typedef long __kernel_off_t; So, your patch introduce 2GB limitation to 32bit arch. It makes no sense. > 2. Because the argument "offset" of sys_mmap is a multiple > of the page size(otherwise, EINVAL is returned.), no information > is lost after shifting right by PAGE_SHIFT bits. Therefore > to make an overflow check in do_mmap_pgoff is equivalent > to check in sys_mmap. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href