19 May, 2011
4 commits
-
Modifications to recordmcount must be performed on all object
files to stay consistent with what the kernel code may expect.
Add the recordmcount files to the main dependencies to make sure
any change to them causes a full recompile.Signed-off-by: Michal Marek
Link: http://lkml.kernel.org/r/20110517133646.GP13293@sepie.suse.cz
Signed-off-by: Steven Rostedt -
perf bench needs this to build the kernel's memcpy routine:
In file included from bench/mem-memcpy-x86-64-asm.S:2:0:
bench/../../../arch/x86/lib/memcpy_64.S:7:33: fatal error: asm/alternative-asm.h: No such file or directoryCc: Peter Zijlstra
Cc: Arnaldo Carvalho de Melo
Cc: Frederic Weisbecker
Cc: Mike Galbraith
Cc: Steven Rostedt
Link: http://lkml.kernel.org/n/tip-c5d41xibgullk8h2280q4gv0@git.kernel.org
Signed-off-by: Ingo Molnar -
Merge reason: memcpy_64.S changes an assumption perf bench has, so merge this
here so we can fix it.Signed-off-by: Ingo Molnar
-
…rostedt/linux-2.6-trace into perf/core
18 May, 2011
12 commits
-
As reported in BZ #30352:
https://bugzilla.kernel.org/show_bug.cgi?id=30352
there's a kernel bug related to reading the last allowed page on x86_64.
The _copy_to_user() and _copy_from_user() functions use the following
check for address limit:if (buf + size >= limit)
fail();while it should be more permissive:
if (buf + size > limit)
fail();That's because the size represents the number of bytes being
read/write from/to buf address AND including the buf address.
So the copy function will actually never touch the limit
address even if "buf + size == limit".Following program fails to use the last page as buffer
due to the wrong limit check:#include
#include
#include#define PAGE_SIZE (4096)
#define LAST_PAGE ((void*)(0x7fffffffe000))int main()
{
int fds[2], err;
void * ptr = mmap(LAST_PAGE, PAGE_SIZE, PROT_READ | PROT_WRITE,
MAP_ANONYMOUS | MAP_PRIVATE | MAP_FIXED, -1, 0);
assert(ptr == LAST_PAGE);
err = socketpair(AF_LOCAL, SOCK_STREAM, 0, fds);
assert(err == 0);
err = send(fds[0], ptr, PAGE_SIZE, 0);
perror("send");
assert(err == PAGE_SIZE);
err = recv(fds[1], ptr, PAGE_SIZE, MSG_WAITALL);
perror("recv");
assert(err == PAGE_SIZE);
return 0;
}The other place checking the addr limit is the access_ok() function,
which is working properly. There's just a misleading comment
for the __range_not_ok() macro - which this patch fixes as well.The last page of the user-space address range is a guard page and
Brian Gerst observed that the guard page itself due to an erratum on K8 cpus
(#121 Sequential Execution Across Non-Canonical Boundary Causes Processor
Hang).However, the test code is using the last valid page before the guard page.
The bug is that the last byte before the guard page can't be read
because of the off-by-one error. The guard page is left in place.This bug would normally not show up because the last page is
part of the process stack and never accessed via syscalls.Signed-off-by: Jiri Olsa
Acked-by: Brian Gerst
Acked-by: Linus Torvalds
Cc:
Link: http://lkml.kernel.org/r/1305210630-7136-1-git-send-email-jolsa@redhat.com
Signed-off-by: Ingo Molnar -
Support memset() with enhanced rep stosb. On processors supporting enhanced
REP MOVSB/STOSB, the alternative memset_c_e function using enhanced rep stosb
overrides the fast string alternative memset_c and the original function.Signed-off-by: Fenghua Yu
Link: http://lkml.kernel.org/r/1305671358-14478-10-git-send-email-fenghua.yu@intel.com
Signed-off-by: H. Peter Anvin -
Support memmove() by enhanced rep movsb. On processors supporting enhanced
REP MOVSB/STOSB, the alternative memmove() function using enhanced rep movsb
overrides the original function.The patch doesn't change the backward memmove case to use enhanced rep
movsb.Signed-off-by: Fenghua Yu
Link: http://lkml.kernel.org/r/1305671358-14478-9-git-send-email-fenghua.yu@intel.com
Signed-off-by: H. Peter Anvin -
Support memcpy() with enhanced rep movsb. On processors supporting enhanced
rep movsb, the alternative memcpy() function using enhanced rep movsb overrides the original function and the fast string
function.Signed-off-by: Fenghua Yu
Link: http://lkml.kernel.org/r/1305671358-14478-8-git-send-email-fenghua.yu@intel.com
Signed-off-by: H. Peter Anvin -
Support copy_to_user/copy_from_user() by enhanced REP MOVSB/STOSB.
On processors supporting enhanced REP MOVSB/STOSB, the alternative
copy_user_enhanced_fast_string function using enhanced rep movsb overrides the
original function and the fast string function.Signed-off-by: Fenghua Yu
Link: http://lkml.kernel.org/r/1305671358-14478-7-git-send-email-fenghua.yu@intel.com
Signed-off-by: H. Peter Anvin -
Intel processors are adding enhancements to REP MOVSB/STOSB and the use of
REP MOVSB/STOSB for optimal memcpy/memset or similar functions is recommended.
Enhancement availability is indicated by CPUID.7.0.EBX[9] (Enhanced REP MOVSB/
STOSB).Support clear_page() with rep stosb for processor supporting enhanced REP MOVSB
/STOSB. On processors supporting enhanced REP MOVSB/STOSB, the alternative
clear_page_c_e function using enhanced REP STOSB overrides the original function
and the fast string function.Signed-off-by: Fenghua Yu
Link: http://lkml.kernel.org/r/1305671358-14478-6-git-send-email-fenghua.yu@intel.com
Signed-off-by: H. Peter Anvin -
Add altinstruction_entry macro to generate .altinstructions section
entries from assembly code. This should be less failure-prone than
open-coding.Signed-off-by: Fenghua Yu
Link: http://lkml.kernel.org/r/1305671358-14478-5-git-send-email-fenghua.yu@intel.com
Signed-off-by: H. Peter Anvin -
Some string operation functions may be patched twice, e.g. on enhanced REP MOVSB
/STOSB processors, memcpy is patched first by fast string alternative function,
then it is patched by enhanced REP MOVSB/STOSB alternative function.Add comment for applying alternatives order to warn people who may change the
applying alternatives order for any reason.[ Documentation-only patch ]
Signed-off-by: Fenghua Yu
Link: http://lkml.kernel.org/r/1305671358-14478-4-git-send-email-fenghua.yu@intel.com
Signed-off-by: H. Peter Anvin -
If kernel intends to use enhanced REP MOVSB/STOSB, it must ensure
IA32_MISC_ENABLE.Fast_String_Enable (bit 0) is set and CPUID.(EAX=07H, ECX=0H):
EBX[bit 9] also reports 1.Signed-off-by: Fenghua Yu
Link: http://lkml.kernel.org/r/1305671358-14478-3-git-send-email-fenghua.yu@intel.com
Signed-off-by: H. Peter Anvin -
Intel processors are adding enhancements to REP MOVSB/STOSB and the use of
REP MOVSB/STOSB for optimal memcpy/memset or similar functions is recommended.
Enhancement availability is indicated by CPUID.7.0.EBX[9] (Enhanced REP MOVSB/
STOSB).Signed-off-by: Fenghua Yu
Link: http://lkml.kernel.org/r/1305671358-14478-2-git-send-email-fenghua.yu@intel.com
Signed-off-by: H. Peter Anvin -
CPUID leaf 7, subleaf 0 returns the maximum subleaf in EAX, not the
number of subleaves. Since so far only subleaf 0 is defined (and only
the EBX bitfield) we do not need to qualify the test.Signed-off-by: Fenghua Yu
Link: http://lkml.kernel.org/r/1305660806-17519-1-git-send-email-fenghua.yu@intel.com
Signed-off-by: H. Peter Anvin
Cc: 2.6.36..39 -
This patch fixes an issue with event parsing.
The following commit appears to have broken the
ability to specify a comma separated list of events:commit ceb53fbf6dbb1df26d38379a262c6981fe73dd36
Author: Ingo Molnar
Date: Wed Apr 27 04:06:33 2011 +0200perf stat: Fail more clearly when an invalid modifier is specified
This patch fixes this while preserving the desired effect:
$ perf stat -e instructions:u,instructions:k ls /dev/null /dev/null
Performance counter stats for 'ls /dev/null':
365956 instructions:u # 0.00 insns per cycle
731806 instructions:k # 0.00 insns per cycle0.001108862 seconds time elapsed
$ perf stat -e task-clock-msecs true
invalid event modifier: '-msecs'
Run 'perf list' for a list of valid events and modifiersSigned-off-by: Stephane Eranian
Cc: acme@redhat.com
Cc: peterz@infradead.org
Cc: fweisbec@gmail.com
Link: http://lkml.kernel.org/r/20110517133619.GA6999@quad
Signed-off-by: Ingo Molnar
17 May, 2011
14 commits
-
Do the mcount offset adjustment in the recordmcount.pl/recordmcount.[ch]
at compile time and not in ftrace_call_adjust at run time.Signed-off-by: Martin Schwidefsky
Signed-off-by: Steven Rostedt -
Do the mcount offset adjustment in the recordmcount.pl/recordmcount.[ch]
at compile time and not in ftrace_call_adjust at run time.Signed-off-by: Martin Schwidefsky
Signed-off-by: Steven Rostedt -
Introduce mcount_adjust{,_32,_64} to the C implementation of
recordmcount analog to $mcount_adjust in the perl script.
The adjustment is added to the address of the relocations
against the mcount symbol. If this adjustment is done by
recordmcount at compile time the ftrace_call_adjust function
can be turned into a nop.Cc: John Reiser
Signed-off-by: Martin Schwidefsky
Signed-off-by: Steven Rostedt -
The code to get the symbol, string, and relp pointers in the two functions
sift_rel_mcount() and nop_mcount() are identical and also non-trivial.
Moving this duplicate code into a single helper function makes the code
easier to read and more maintainable.Cc: John Reiser
Link: http://lkml.kernel.org/r/20110421023739.723658553@goodmis.org
Signed-off-by: Steven Rostedt -
The code in sift_rel_mcount() and nop_mcount() to get the mcount symbol
number is identical. Replace the two locations with a call to a function
that does the work.Cc: John Reiser
Link: http://lkml.kernel.org/r/20110421023739.488093407@goodmis.org
Signed-off-by: Steven Rostedt -
The section called .discard.text has tracing attached to it and is
currently ignored by ftrace. But it does include a call to the mcount
stub. Adding a notrace to the code keeps gcc from adding the useless
mcount caller to it.Link: http://lkml.kernel.org/r/20110421023739.243651696@goodmis.org
Signed-off-by: Steven Rostedt -
The init and exit sections should not be traced and adding a call to
mcount to them is a waste of text and instruction cache. Have the
macro section attributes include notrace to ignore these functions
for tracing from the build.Link: http://lkml.kernel.org/r/20110421023738.953028219@goodmis.org
Signed-off-by: Steven Rostedt -
When mcount is called in a section that ftrace will not modify it into
a nop, we want to warn about this. But not warn about this always. Now
if the user builds the kernel with the option RECORDMCOUNT_WARN=1 then
the build will warn about mcount callers that are ignored and will just
waste execution time.Acked-by: Michal Marek
Cc: linux-kbuild@vger.kernel.org
Link: http://lkml.kernel.org/r/20110421023738.714956282@goodmis.org
Signed-off-by: Steven Rostedt -
There's some sections that should not have mcount recorded and should not have
modifications to the that code. But currently they waste some time by calling
mcount anyway (which simply returns). As the real answer should be to
either whitelist the section or have gcc ignore it fully.This change adds a option to recordmcount to warn when it finds a section
that is ignored by ftrace but still contains mcount callers. This is not on
by default as developers may not know if the section should be completely
ignored or added to the whitelist.Cc: John Reiser
Link: http://lkml.kernel.org/r/20110421023738.476989377@goodmis.org
Signed-off-by: Steven Rostedt -
There are sections that are ignored by ftrace for the function tracing because
the text is in a section that can be removed without notice. The mcount calls
in these sections are ignored and ftrace never sees them. The downside of this
is that the functions in these sections still call mcount. Although the mcount
function is defined in assembly simply as a return, this added overhead is
unnecessary.The solution is to convert these callers into nops at compile time.
A better solution is to add 'notrace' to the section markers, but as new sections
come up all the time, it would be nice that they are delt with when they
are created.Later patches will deal with finding these sections and doing the proper solution.
Thanks to H. Peter Anvin for giving me the right nops to use for x86.
Cc: "H. Peter Anvin"
Cc: John Reiser
Link: http://lkml.kernel.org/r/20110421023738.237101176@goodmis.org
Signed-off-by: Steven Rostedt -
PROGBITS is not enough to determine if the section should be modified
or not. Only process sections that are marked as executable.Cc: John Reiser
Link: http://lkml.kernel.org/r/20110421023737.991485123@goodmis.org
Signed-off-by: Steven Rostedt -
The .kprobe.text section is safe to modify mcount to nop and tracing.
Add it to the whitelist in recordmcount.c and recordmcount.pl.Cc: John Reiser
Cc: Masami Hiramatsu
Link: http://lkml.kernel.org/r/20110421023737.743350547@goodmis.org
Signed-off-by: Steven Rostedt -
The Linux style for switch statements is:
switch (var) {
case x:
[...]
break;
}Not:
switch (var) {
case x: {
[...]
} break;Cc: John Reiser
Link: http://lkml.kernel.org/r/20110421023737.523968644@goodmis.org
Signed-off-by: Steven Rostedt -
The Linux ftrace subsystem style for comparing is:
var == 1
var > 0and not:
1 == var
0 < varIt is considered that Linux developers are smart enough not to do the
if (var = 1)
mistake.
Cc: John Reiser
Link: http://lkml.kernel.org/r/20110421023737.290712238@goodmis.org
Signed-off-by: Steven Rostedt
12 May, 2011
1 commit
-
Both warning and warning_symbol are nowhere used.
Let's get rid of them.Signed-off-by: Richard Weinberger
Cc: Oleg Nesterov
Cc: Andrew Morton
Cc: Huang Ying
Cc: Soeren Sandmann Pedersen
Cc: Namhyung Kim
Cc: x86
Cc: H. Peter Anvin
Cc: Thomas Gleixner
Cc: Robert Richter
Cc: Paul Mundt
Link: http://lkml.kernel.org/r/1305205872-10321-2-git-send-email-richard@nod.at
Signed-off-by: Frederic Weisbecker
10 May, 2011
9 commits
-
pubname_callback_param::found should be initialized to 0 in
fastpath lookup, the structure is on the stack and
uninitialized otherwise.Signed-off-by: Lin Ming
Cc: Arnaldo Carvalho de Melo
Link: http://lkml.kernel.org/r/1304066518-30420-2-git-send-email-ming.m.lin@intel.com
Signed-off-by: Ingo Molnar -
Merge reason: pull in the latest fixes.
Signed-off-by: Ingo Molnar
-
Commit a626ca6a6564 ("vm: fix vm_pgoff wrap in stack expansion") fixed
the case of an expanding mapping causing vm_pgoff wrapping when you had
downward stack expansion. But there was another case where IA64 and
PA-RISC expand mappings: upward expansion.This fixes that case too.
Signed-off-by: Hugh Dickins
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds -
* 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6:
drm/i915/lvds: Only act on lid notify when the device is on
drm/i915: fix intel_crtc_clock_get pipe reads after "cleanup cleanup"
drm/i915: Only enable the plane after setting the fb base (pre-ILK)
drm/i915/dp: Be paranoid in case we disable a DP before it is attached
drm/i915: Release object along create user fb error path -
Linux kernel excludes guard page when performing mlock on a VMA with
down-growing stack. However, some architectures have up-growing stack
and locking the guard page should be excluded in this case too.This patch fixes lvm2 on PA-RISC (and possibly other architectures with
up-growing stack). lvm2 calculates number of used pages when locking and
when unlocking and reports an internal error if the numbers mismatch.[ Patch changed fairly extensively to also fix /proc//maps for the
grows-up case, and to move things around a bit to clean it all up and
share the infrstructure with the /proc bits.Tested on ia64 that has both grow-up and grow-down segments - Linus ]
Signed-off-by: Mikulas Patocka
Tested-by: Tony Luck
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds -
* 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mjg59/platform-drivers-x86:
eeepc-laptop: Use ACPI handle to identify rfkill port
[PATCH] sony-laptop: limit brightness range to DSDT provided ones
sony-laptop: report failures on setting LCD brightness
thinkpad-acpi: module autoloading for newer Lenovo ThinkPads. -
If we're using vga switcheroo, the device may be turned off
and poking it can return random state. This provokes an OOPS fixed
separately by 8ff887c847 (drm/i915/dp: Be paranoid in case we disable a
DP before it is attached). Trying to use and respond to events on a
device that has been turned off by the user is in principle a silly thing
to do.Signed-off-by: Alex Williamson
Signed-off-by: Chris Wilson
Cc: stable@kernel.org
Signed-off-by: Keith Packard -
Despite the fixes in 548f245ba6a31 (drm/i915: fix per-pipe reads after
"cleanup"), we missed one neighbouring read that was mistakenly replaced
with the reg value in 9db4a9c (drm/i915: cleanup per-pipe reg usage).
This was preventing us from correctly determining the mode the BIOS left
the panel in for machines that neither have an OpRegion nor access to
the VBT, (e.g. the EeePC 700).Signed-off-by: Chris Wilson
Cc: Jesse Barnes
Cc: stable@kernel.org
Reviewed-by: Jesse Barnes
Signed-off-by: Keith Packard
