From: "David S. Miller" <davem@davemloft.net>
To: Andi Kleen <ak@suse.de>
Cc: rmk@arm.linux.org.uk, torvalds@osdl.org, akpm@osdl.org,
dwmw2@infradead.org, linux-arch@vger.kernel.org
Subject: Re: [patch 19/24] TASK_SIZE is variable.
Date: Sun, 6 Feb 2005 14:31:10 -0800 [thread overview]
Message-ID: <20050206143110.59dc039f.davem@davemloft.net> (raw)
In-Reply-To: <20050206215020.GJ18245@wotan.suse.de>
On Sun, 6 Feb 2005 22:50:20 +0100
Andi Kleen <ak@suse.de> wrote:
> And yes this stuff does matter - i remember i got LM benchmarkable
> improvements in signal latency by optimizing __copy_to_user
> to use optimized inlines for small stores.
Moving access_ok() out-of-line might even improve I-cache access
over what we have today, even with the new min-max check. The
min-max variables will be in the same cache line in whatever
struct we place them into, so whatever cache miss access_ok() gets
now will also be the same for the min-max version.
This is kind of strange to be arguing about, given that we just
put 4-level page tables into the tree, right? That regressed
everybody performance wise, even people not using the full
4-level support. But I have not barked at you about this, I
undersand why it's needed. And yet you're using lmbench cycle
counting to justify your position against this new verification
scheme.
And it's not just a sparc64 issue. Sparc64 hardware traps the
access, but it's a bug regardless of platform to try to do user
accesses whilst get_fs()==KERNEL_DS. All the user has to do is
pass in a valid kernel address and you have a root exploit. I
mean, do folks really disagree with this?
next prev parent reply other threads:[~2005-02-06 22:31 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200502050150.j151osl11380@mail.osdl.org>
2005-02-05 2:16 ` [patch 19/24] TASK_SIZE is variable Linus Torvalds
2005-02-05 3:29 ` Linus Torvalds
2005-02-05 5:52 ` David S. Miller
2005-02-07 10:59 ` David Howells
2005-02-07 19:30 ` David S. Miller
2005-02-08 9:05 ` Martin Schwidefsky
2005-02-08 19:09 ` David S. Miller
2005-02-05 9:06 ` Russell King
2005-02-05 23:44 ` David S. Miller
2005-02-06 10:50 ` Andi Kleen
2005-02-06 21:19 ` David S. Miller
2005-02-06 21:31 ` Andi Kleen
2005-02-06 21:31 ` David S. Miller
2005-02-06 21:50 ` Andi Kleen
2005-02-06 22:25 ` David S. Miller
2005-02-06 22:31 ` David S. Miller [this message]
2005-02-07 8:11 ` Andi Kleen
2005-02-07 19:28 ` David S. Miller
2005-02-07 20:15 ` Andi Kleen
2005-02-07 20:13 ` David S. Miller
2005-02-05 6:54 ` Andi Kleen
2005-02-05 7:18 ` Andrew Morton
2005-02-05 7:40 ` Andi Kleen
2005-02-05 23:27 ` David S. Miller
2005-02-06 10:38 ` Andi Kleen
2005-02-06 13:05 ` Matthew Wilcox
2005-02-05 23:15 ` David S. Miller
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=20050206143110.59dc039f.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=dwmw2@infradead.org \
--cc=linux-arch@vger.kernel.org \
--cc=rmk@arm.linux.org.uk \
--cc=torvalds@osdl.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.