From: Naotaka Hamaguchi <n.hamaguchi@jp.fujitsu.com>
To: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] mm: mmap system call does not return EOVERFLOW
Date: Tue, 27 Dec 2011 15:21:58 +0900 [thread overview]
Message-ID: <4EF96406.6080102@jp.fujitsu.com> (raw)
In-Reply-To: <4EF36BDA.5080105@gmail.com>
Hi, Kosaki-san
> Which version are you looking at? Current code seems to don't have
> sys_mmap().
This sys_mmap() means the entrance of mmap system call for x86_64.
----------------------------------------------------------------------
arch/x86/kernel/sys_x86_64.c:
84 SYSCALL_DEFINE6(mmap, unsigned long, addr, unsigned long, len,
85 unsigned long, prot, unsigned long, flags,
86 unsigned long, fd, unsigned long, off)
87 {
88 long error;
89 error = -EINVAL;
90 if (off & ~PAGE_MASK)
91 goto out;
92
93 error = sys_mmap_pgoff(addr, len, prot, flags, fd, off >> PAGE_SHIFT);
94 out:
95 return error;
96 }
----------------------------------------------------------------------
This function calls sys_mmap_pgoff, which has the argument
"off >> PAGE_SHIFT". It means that sys_mmap_pgoff does not use off,
which is the argument of sys_mmap, with no change, but uses the value
obtained after off is shifted right by PAGE_SHIFT bits.
In mmap system call for x86, the following sys_mmap_pgoff is the
entrance in kernel.
----------------------------------------------------------------------
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.
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.
Best Regards,
Naotaka Hamaguchi
(2011/12/23 2:41), KOSAKI Motohiro wrote:
>> The argument "offset" is shifted right by PAGE_SHIFT bits
>> in sys_mmap(mmap systemcall).
>>
>> ------------------------------------------------------------------------
>> sys_mmap(unsigned long addr, unsigned long len,
>> unsigned long prot, unsigned long flags,
>> unsigned long fd, unsigned long off)
>> {
>> error = sys_mmap_pgoff(addr, len, prot, flags, fd, off>> PAGE_SHIFT);
>> }
>> ------------------------------------------------------------------------
>
> Hm.
> Which version are you looking at? Current code seems to don't have
> sys_mmap().
>
>
>
>
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. 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=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Naotaka Hamaguchi <n.hamaguchi@jp.fujitsu.com>
To: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] mm: mmap system call does not return EOVERFLOW
Date: Tue, 27 Dec 2011 15:21:58 +0900 [thread overview]
Message-ID: <4EF96406.6080102@jp.fujitsu.com> (raw)
In-Reply-To: <4EF36BDA.5080105@gmail.com>
Hi, Kosaki-san
> Which version are you looking at? Current code seems to don't have
> sys_mmap().
This sys_mmap() means the entrance of mmap system call for x86_64.
----------------------------------------------------------------------
arch/x86/kernel/sys_x86_64.c:
84 SYSCALL_DEFINE6(mmap, unsigned long, addr, unsigned long, len,
85 unsigned long, prot, unsigned long, flags,
86 unsigned long, fd, unsigned long, off)
87 {
88 long error;
89 error = -EINVAL;
90 if (off & ~PAGE_MASK)
91 goto out;
92
93 error = sys_mmap_pgoff(addr, len, prot, flags, fd, off >> PAGE_SHIFT);
94 out:
95 return error;
96 }
----------------------------------------------------------------------
This function calls sys_mmap_pgoff, which has the argument
"off >> PAGE_SHIFT". It means that sys_mmap_pgoff does not use off,
which is the argument of sys_mmap, with no change, but uses the value
obtained after off is shifted right by PAGE_SHIFT bits.
In mmap system call for x86, the following sys_mmap_pgoff is the
entrance in kernel.
----------------------------------------------------------------------
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.
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.
Best Regards,
Naotaka Hamaguchi
(2011/12/23 2:41), KOSAKI Motohiro wrote:
>> The argument "offset" is shifted right by PAGE_SHIFT bits
>> in sys_mmap(mmap systemcall).
>>
>> ------------------------------------------------------------------------
>> sys_mmap(unsigned long addr, unsigned long len,
>> unsigned long prot, unsigned long flags,
>> unsigned long fd, unsigned long off)
>> {
>> error = sys_mmap_pgoff(addr, len, prot, flags, fd, off>> PAGE_SHIFT);
>> }
>> ------------------------------------------------------------------------
>
> Hm.
> Which version are you looking at? Current code seems to don't have
> sys_mmap().
>
>
>
>
>
next prev parent reply other threads:[~2011-12-27 6:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-22 9:35 [PATCH] mm: mmap system call does not return EOVERFLOW Naotaka Hamaguchi
2011-12-22 9:35 ` Naotaka Hamaguchi
2011-12-22 16:58 ` KOSAKI Motohiro
2011-12-22 16:58 ` KOSAKI Motohiro
2011-12-22 17:41 ` KOSAKI Motohiro
2011-12-22 17:41 ` KOSAKI Motohiro
2011-12-27 6:21 ` Naotaka Hamaguchi [this message]
2011-12-27 6:21 ` Naotaka Hamaguchi
2011-12-28 2:04 ` KOSAKI Motohiro
2011-12-28 2:04 ` KOSAKI Motohiro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EF96406.6080102@jp.fujitsu.com \
--to=n.hamaguchi@jp.fujitsu.com \
--cc=kosaki.motohiro@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.