From: Jan Niehusmann <jan@gondor.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: David.Mosberger@acm.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [patch] remove hugetlb syscalls
Date: Sat, 16 Nov 2002 19:23:17 +0100 [thread overview]
Message-ID: <20021116182317.GA22083@gondor.com> (raw)
In-Reply-To: <1037304844.16003.63.camel@irongate.swansea.linux.org.uk>
On Thu, Nov 14, 2002 at 08:14:04PM +0000, Alan Cox wrote:
> On Thu, 2002-11-14 at 19:52, Alan Cox wrote:
> > On Thu, 2002-11-14 at 18:53, David Mosberger-Tang wrote:
> > > But that's excactly the point. The hugepage interface returns a
> > > different kind of virtual memory. There are tons of programs out
> > > there using mmap(). If such a program gets fed a path to the
> > > hugepagefs, it might end up with huge pages without knowing anything
> > > about huge pages. For the most part, that might work fine, but it
> > > could lead to subtle failures.
> >
> > Your argument makes sense. You are arguing
> Makes no sense rather 8)
Sorry, I didn't follow the whole discussion, so my argument may make no
sense at all, too. :-)
If I understand David correctly, he doesn't worry about programs that
want to use huge pages, but about programs just using mmap just to
access some file. If they get called with a file that behaves subtly
different than usual files, that may lead to failures or even security
holes.
But that's no argument to keep the syscalls, if you decide to implement
hugepagefs. The existance of the syscalls doesn't prevent bugs created
or triggered by hugepagefs.
Jan
next prev parent reply other threads:[~2002-11-16 18:16 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-13 23:45 [patch] remove hugetlb syscalls Benjamin LaHaise
2002-11-14 0:42 ` Rik van Riel
2002-11-14 8:52 ` dada1
2002-11-14 14:13 ` Christoph Hellwig
[not found] ` <ugel9oa vk4.fsf@panda.mostang.com>
2002-11-14 15:13 ` dada1
2002-11-14 15:31 ` Benjamin LaHaise
2002-11-14 15:38 ` dada1
[not found] ` <3DD3FED2.2010901@unix-os.sc.intel.com>
2002-11-14 20:01 ` Benjamin LaHaise
2002-11-14 21:06 ` Benjamin LaHaise
2002-11-14 20:11 ` Rohit Seth
2002-11-14 20:36 ` William Lee Irwin III
2002-11-14 17:51 ` David Mosberger-Tang
2002-11-14 18:31 ` Alan Cox
2002-11-14 18:53 ` David Mosberger-Tang
2002-11-14 19:52 ` Alan Cox
2002-11-14 20:14 ` Alan Cox
2002-11-16 18:23 ` Jan Niehusmann [this message]
2002-11-14 20:34 ` William Lee Irwin III
2002-11-14 21:31 ` David Mosberger-Tang
2002-11-14 21:38 ` William Lee Irwin III
2002-11-14 21:46 ` David Mosberger-Tang
2002-11-14 19:28 ` Jeff Garzik
2002-11-14 20:15 ` Alan Cox
2002-11-16 18:00 ` Rik van Riel
2002-11-16 18:15 ` Linus Torvalds
2002-11-14 20:30 ` William Lee Irwin III
2002-11-14 20:48 ` Benjamin LaHaise
2002-11-14 21:02 ` William Lee Irwin III
2002-11-14 21:11 ` Benjamin LaHaise
2002-11-14 21:31 ` William Lee Irwin III
2002-11-14 21:40 ` Rohit Seth
2002-11-14 21:59 ` Benjamin LaHaise
2002-11-14 21:06 ` Benjamin LaHaise
2002-11-14 21:06 ` Benjamin LaHaise
-- strict thread matches above, loose matches on Subject: below --
2002-11-14 22:12 Seth, Rohit
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=20021116182317.GA22083@gondor.com \
--to=jan@gondor.com \
--cc=David.Mosberger@acm.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox