linux-toradex.git/scripts, branch v2.6.27.62

kbuild: Fix passing -Wno-* options to gcc 4.4+

2012-02-11T14:40:52+00:00

commit 8417da6f2128008c431c7d130af6cd3d9079922e upstream.

Starting with 4.4, gcc will happily accept -Wno- in the
cc-option test and complain later when compiling a file that has some
other warning. This rather unexpected behavior is intentional as per
http://gcc.gnu.org/PR28322, so work around it by testing for support of
the opposite option (without the no-). Introduce a new Makefile function
cc-disable-warning that does this and update two uses of cc-option in
the toplevel Makefile.

Reported-and-tested-by: Stephen Rothwell 
Signed-off-by: Michal Marek 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Willy Tarreau

fixes for using make 3.82

2010-08-26T23:40:12+00:00

commit 3c955b407a084810f57260d61548cc92c14bc627 upstream.

It doesn't like pattern and explicit rules to be on the same line,
and it seems to be more picky when matching file (or really directory)
names with different numbers of trailing slashes.

Signed-off-by: Jan Beulich 
Acked-by: Sam Ravnborg 
Andrew Benton 
Signed-off-by: Michal Marek 
Signed-off-by: Greg Kroah-Hartman

kbuild: Fix modpost segfault

2010-08-02T17:18:51+00:00

commit 1c938663d58b5b2965976a6f54cc51b5d6f691aa upstream.

Alan  writes:

> program: /home/alan/GitTrees/linux-2.6-mid-ref/scripts/mod/modpost -o
> Module.symvers -S vmlinux.o
>
> Program received signal SIGSEGV, Segmentation fault.

It just hit me.
It's the offset calculation in reloc_location() which overflows:
        return (void *)elf->hdr + sechdrs[section].sh_offset +
               (r->r_offset - sechdrs[section].sh_addr);

E.g. for the first rodata r entry:
r->r_offset < sechdrs[section].sh_addr
and the expression in the parenthesis produces 0xFFFFFFE0 or something
equally wise.

Reported-by: Alan 
Signed-off-by: Krzysztof Hałasa 
Tested-by: Alan 
Signed-off-by: Michal Marek 
Signed-off-by: Greg Kroah-Hartman

gconfig: fix build failure on fedora 13

2010-07-05T18:08:44+00:00

commit cbab05f041a4cff6ca15856bdd35238b282b64eb upstream.

Making gconfig fails on fedora 13 as the linker cannot resolve dlsym.

Adding libdl to the link command fixes this.

make shows this error :-
    /usr/bin/ld: scripts/kconfig/kconfig_load.o: undefined reference to symbol 'dlsym@@GLIBC_2.2.5'
    /usr/bin/ld: note: 'dlsym@@GLIBC_2.2.5' is defined in DSO /lib64/libdl.so.2 so try adding it to the linker command line
    /lib64/libdl.so.2: could not read symbols: Invalid operation

tested on x86_64 fedora 13.

Signed-off-by: Richard Kennedy 
Reviewed-by: WANG Cong 
Signed-off-by: Andrew Morton 
Signed-off-by: Michal Marek 
Signed-off-by: Greg Kroah-Hartman

kbuild: fix C libary confusion in unifdef.c due to getline()

2009-07-02T23:32:13+00:00

commit d15bd1067b1fcb2b7250d22bc0c7c7fea0b759f7 upstream.

This fixes an error when compiling the kernel.

  CHK     include/linux/version.h
  HOSTCC  scripts/unifdef
scripts/unifdef.c:209: error: conflicting types for 'getline'
/usr/include/stdio.h:651: note: previous declaration of 'getline' was here
make[1]: *** [scripts/unifdef] Error 1
make: *** [__headers] Error 2

Signed-off-by: Justin P. Mattock 
Cc:  Frederic Weisbecker 
Signed-off-by: Andrew Morton 
Signed-off-by: Sam Ravnborg 
Cc: Gilles Espinasse 
Signed-off-by: Greg Kroah-Hartman

kbuild: fix Module.markers permission error under cygwin

2009-05-08T21:54:34+00:00

commit 99e3a1eb3c22bb671c6f3d22d8244bfc9fad8185 upstream.

While building the kernel, we end-up calling modpost with -K and -M
options for the same file (Modules.markers).  This is resulting in
modpost's main function calling read_markers() and then write_markers() on
the same file.

We then have read_markers() mmap'ing the file, and writer_markers()
opening that same file for writing.

The issue is that read_markers() exits without munmap'ing the file and is
as a matter holding a reference on Modules.markers.  When write_markers()
is opening that very same file for writing, we still have a reference on
it and cygwin (Windows?) is then making fopen() fail with EPERM.

Calling release_file() before exiting read_markers() clears that reference
(and memory leak) and fopen() then succeeds.

Tested on both cygwin (1.3.22) and Linux.  Also ran modpost within
valgrind on Linux to make sure that the munmap'ed file was not accessed
after read_markers()

Signed-off-by: Cedric Hombourger 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Sam Ravnborg 
Signed-off-by: Greg Kroah-Hartman

kernel-doc: fix syscall wrapper processing

2009-02-17T17:46:14+00:00

commit b4870bc5ee8c7a37541a3eb1208b5c76c13a078a upstream.

Fix kernel-doc processing of SYSCALL wrappers.

The SYSCALL wrapper patches played havoc with kernel-doc for
syscalls.  Syscalls that were scanned for DocBook processing
reported warnings like this one, for sys_tgkill:

Warning(kernel/signal.c:2285): No description found for parameter 'tgkill'
Warning(kernel/signal.c:2285): No description found for parameter 'pid_t'
Warning(kernel/signal.c:2285): No description found for parameter 'int'

because the macro parameters all "look like" function parameters,
although they are not:

/**
 *  sys_tgkill - send signal to one specific thread
 *  @tgid: the thread group ID of the thread
 *  @pid: the PID of the thread
 *  @sig: signal to be sent
 *
 *  This syscall also checks the @tgid and returns -ESRCH even if the PID
 *  exists but it's not belonging to the target process anymore. This
 *  method solves the problem of threads exiting and PIDs getting reused.
 */
SYSCALL_DEFINE3(tgkill, pid_t, tgid, pid_t, pid, int, sig)
{
...

This patch special-cases the handling SYSCALL_DEFINE* function
prototypes by expanding them to
	long sys_foobar(type1 arg1, type1 arg2, ...)

Signed-off-by: Randy Dunlap 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

kbuild: Fixup deb-pkg target to generate separate firmware deb

2008-11-20T22:54:46+00:00

commit bf1b36445dc868cbbde194aa1dd87e38fe24cf16 upstream.

The below is a simplistic fix for "make deb-pkg"; it splits the
firmware out to a linux-firmware-image package and adds an
(unversioned) Suggests to the linux package for this firmware.

Signed-Off-By: Jonathan McDowell 
Acked-by: Frans Pop 
Signed-off-by: Sam Ravnborg 
Signed-off-by: Greg Kroah-Hartman

kbuild: mkspec - fix build rpm

2008-11-07T03:05:39+00:00

commit 46dca86cb93db80992a45e4b55737ff2b2f61cd0 upstream
Date: Wed, 15 Oct 2008 23:37:26 +0600
Subject: kbuild: mkspec - fix build rpm

This is patch to fix incorrect mkspec script to make rpm correctly at 2.6.27 vanilla kernel.
This is regression in 2.6.27. 2.6.26 make rpm work good.
In 2.6.27 'make rpm' say error from rpmbuild "Many unpacked files (*.fw)."

Signed-off-by: Evgeniy Manachkin 
Acked-by: Alan Cox 
Signed-off-by: Sam Ravnborg 
Signed-off-by: Greg Kroah-Hartman

Marker depmod fix core kernel list

2008-10-06T23:34:19+00:00

* Theodore Ts'o (tytso@mit.edu) wrote:
>
> I've been playing with adding some markers into ext4 to see if they
> could be useful in solving some problems along with Systemtap.  It
> appears, though, that as of 2.6.27-rc8, markers defined in code which is
> compiled directly into the kernel (i.e., not as modules) don't show up
> in Module.markers:
>
> kvm_trace_entryexit arch/x86/kvm/kvm-intel  %u %p %u %u %u %u %u %u
> kvm_trace_handler arch/x86/kvm/kvm-intel  %u %p %u %u %u %u %u %u
> kvm_trace_entryexit arch/x86/kvm/kvm-amd  %u %p %u %u %u %u %u %u
> kvm_trace_handler arch/x86/kvm/kvm-amd  %u %p %u %u %u %u %u %u
>
> (Note the lack of any of the kernel_sched_* markers, and the markers I
> added for ext4_* and jbd2_* are missing as wel.)
>
> Systemtap apparently depends on in-kernel trace_mark being recorded in
> Module.markers, and apparently it's been claimed that it used to be
> there.  Is this a bug in systemtap, or in how Module.markers is getting
> built?   And is there a file that contains the equivalent information
> for markers located in non-modules code?

I think the problem comes from "markers: fix duplicate modpost entry"
(commit d35cb360c29956510b2fe1a953bd4968536f7216)

Especially :

  -   add_marker(mod, marker, fmt);
  +   if (!mod->skip)
  +     add_marker(mod, marker, fmt);
    }
    return;
   fail:

Here is a fix that should take care if this problem.

Thanks for the bug report!

Signed-off-by: Mathieu Desnoyers 
Tested-by: "Theodore Ts'o" 
CC: Greg KH 
CC: David Smith 
CC: Roland McGrath 
CC: Sam Ravnborg 
CC: Wenji Huang 
CC: Takashi Nishiie 
Signed-off-by: Linus Torvalds