The current logic to check objcopy's version is incorrect. This patch
fixes the algorithm and disables the use of local functions as a reference
if the objcopy version does not support static to global conversions.
Also remove some usused variables.
Signed-off-by: Li Hong <lihong.hi@gmail.com>
LKML-Reference: <20091028050421.GD30758@uhli>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
The ftrace.c file may reference the mcount function and this may interfere
with the recordmcount.pl processing. To avoid this, the code does not
process the kernel/trace/ftrace.o. But currently the check is against
a relative path. This patch modifies the check to succeed if the path
is an absolute path.
Signed-off-by: Li Hong <lihong.hi@gmail.com>
LKML-Reference: <20091028050332.GC30758@uhli>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
The number of arguments passed into recordmcount.pl is 10, but the code
checks if only 7 are passed in.
Signed-off-by: Li Hong <lihong.hi@gmail.com>
LKML-Reference: <20091027065733.GB22032@uhli>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
The documentation currently says we will use the first function in a section
as a reference. The actual algorithm is: choose the first global function we
meet as a reference. If there is none, choose the first local one.
Change the documentation to be consistent with the code.
Also add several other clarifications.
Signed-off-by: Li Hong <lihong.hi@gmail.com>
LKML-Reference: <20091028050138.GA30758@uhli>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Ingo reported that the following lines triggered a false warning,
static struct lock_class_key rcu_lock_key;
struct lockdep_map rcu_lock_map =
STATIC_LOCKDEP_MAP_INIT("rcu_read_lock", &rcu_lock_key);
EXPORT_SYMBOL_GPL(rcu_lock_map);
from kernel/rcutree.c , and the false warning looked like this,
WARNING: EXPORT_SYMBOL(foo); should immediately follow its
function/variable
+EXPORT_SYMBOL_GPL(rcu_lock_map);
We actually should be checking the statement before the EXPORT_* for a
mention of the exported object, and complain where it is not there.
[akpm@linux-foundation.org: coding-style fixes]
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reported-by: Daniel Walker <dwalker@fifo99.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In the following code,
union thread_union init_thread_union
__attribute__((__section__(".data.init_task"))) =
{ INIT_THREAD_INFO(init_task) };
There is a non-conforming declaration. It should really be like the
following,
union thread_union init_thread_union
__attribute__((__section__(".data.init_task"))) = {
INIT_THREAD_INFO(init_task)
};
However, checkpatch doesn't catch this right now because it doesn't
correctly evaluate the "__attribute__".
It is not at all clear that we care what preceeds an assignment style
attribute when we find the open brace. Relax the test so we do not need
to check the __attribute__.
Reported-by: Daniel Walker <dwalker@fifo99.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The macro concatenation (##) sequence can cause false errors when checking
macro's. Checkpatch doesn't currently know about the operator.
For example this line,
+ entry = (struct ftrace_raw_##call *)raw_data; \
is correct but it produces the following error,
ERROR: need consistent spacing around '*' (ctx:WxB)
+ entry = (struct ftrace_raw_##call *)raw_data;\
^
The line above doesn't have any spacing problems, and if you remove the
macro concatenation sequence checkpatch doesn't give any errors.
Extend identifier handling to include ## concatenation within the
definition of an identifier.
Reported-by: Daniel Walker <dwalker@fifo99.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We are allowing context scanning checks to apply against the first line of
context outside at the end of the hunk. This can lead to false matches to
patch names leading to various perl warnings. Correctly stop at the
bottom of the hunk.
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Prevent known non types being detected as modifiers. Ensure we do not
look at any type which starts with a keyword.
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Based on an idea from Wolfram Sang.
Add search for MAINTAINERS line "K:" regex pattern match in a patch or file
Matches are added after file pattern matches
Add --keywords command line switch (default 1, on)
Change version to 0.21
Signed-off-by: Joe Perches <joe@perches.com>
Cc: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The SELinux dynamic class work in c6d3aaa4e3
creates a number of dynamic header files and scripts. Add .gitignore files
so git doesn't complain about these.
Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Stephen D. Smalley <sds@tycho.nsa.gov>
Signed-off-by: James Morris <jmorris@namei.org>
zconf.y includes zconf.hash.c from the initial code section.
zconf.hash.c references the token constants from zconf.y. However,
current bison defines the token constants after the initial code
section, making zconf.hash.c fail to compile. Move the include of
zconf.hash.c later in zconf.y, so bison puts it after the token
constants.
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Merge reason: to add event filter support we need the following
commits from the tracing tree:
3f6fe06: tracing/filters: Unify the regex parsing helpers
1889d20: tracing/filters: Provide basic regex support
737f453: tracing/filters: Cleanup useless headers
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Based on the commit:
a586df06 "x86: Support __attribute__((__cold__)) in gcc 4.3"
some of the functions goes to the ".text.unlikely" section.
Looks like there's not many of them (I found printk, panic,
__ssb_dma_not_implemented, fat_fs_error), but still worth to
include I think.
Signed-off-by: Jiri Olsa <jolsa@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
LKML-Reference: <20091013203426.175845614@goodmis.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
User applications frequently hit problems when they try to use
the kernel headers directly, rather than the exported headers.
This adds an explicit warning for this case, and points to
a URL holding an explanation of why this is wrong and what
to do about it.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
The Makefile.lib will call "echo -ne" to append uncompressed kernel size to
bzip2/lzma kernel image.
The "echo" here depends on the shell that /bin/sh pointing to.
On Ubuntu system, the /bin/sh is pointing to dash, which does not support
"echo -e" at all. Use /bin/echo instead of shell echo should always be safe.
Signed-off-by: Alek Du <alek.du@intel.com>
Acked-by: WANG Cong <xiyou.wangcong@gmail.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Alek reported that on Ubuntu, where dash is used, 'echo -e'
can't work, so let's use non-builtin echo in this case.
Reported-by: Alek Du <alek.du@intel.com>
Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
The binrpm-pkg target (binary RPM only) fails when called with
KBUILD_OUTPUT set. This patch makes it work.
For the rpm-pkg target (source + binary RPM), building with
KBUILD_OUTPUT set is not possible and also not needed as the
actual build is done in a temporary directory anyway, so check
that KBUILD_OUTPUT is not set in that case to avoid later errors.
Signed-off-by: Frans Pop <elendil@planet.nl>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
I've rewritten the extract-ikconfig script to extract the kernel
configuration from a kernel compiled with CONFIG_IKCONFIG. The main
motivation for the rewrite was to remove the dependency on the
external C program binoffset.c, which is compiled on the initial run.
The binoffset executable is invoked with a relative path, which means
that the old script can only be run from the top of the kernel tree,
and only when you have write permission in the scripts directory.
The new script uses tr/grep/tail/zcat only, and can be invoked from
anywhere. The binoffset.c program has been removed. This script
requires GNU grep 2.5 (released 2002-03-13) or higher, because the -o
option was introduced in that version.
Signed-off-by: Dick Streefland <dick@streefland.net>
LKML-Reference: <20091006203540.GA14634@streefland.net>
Tested-by: Steven Rostedt <rostedt@goodmis.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Add a simple utility (scripts/selinux/genheaders) and invoke it to
generate the kernel-private class and permission indices in flask.h
and av_permissions.h automatically during the kernel build from the
security class mapping definitions in classmap.h. Adding new kernel
classes and permissions can then be done just by adding them to classmap.h.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: James Morris <jmorris@namei.org>
