linux-stable.git/scripts, branch linux-3.4.y

ftrace/scripts: Fix incorrect use of sprintf in recordmcount

2016-10-26T15:15:42+00:00

commit 713a3e4de707fab49d5aa4bceb77db1058572a7b upstream.

Fix build warning:

scripts/recordmcount.c:589:4: warning: format not a string
literal and no format arguments [-Wformat-security]
    sprintf("%s: failed\n", file);

Fixes: a50bd43935586 ("ftrace/scripts: Have recordmcount copy the object file")
Link: http://lkml.kernel.org/r/1451516801-16951-1-git-send-email-colin.king@canonical.com

Cc: Li Bin 
Cc: Russell King 
Cc: Will Deacon 
Signed-off-by: Colin Ian King 
Signed-off-by: Steven Rostedt 
Signed-off-by: Zefan Li

ftrace/scripts: Have recordmcount copy the object file

2016-10-26T15:15:39+00:00

commit a50bd43935586420fb75f4558369eb08566fac5e upstream.

Russell King found that he had weird side effects when compiling the kernel
with hard linked ccache. The reason was that recordmcount modified the
kernel in place via mmap, and when a file gets modified twice by
recordmcount, it will complain about it. To fix this issue, Russell wrote a
patch that checked if the file was hard linked more than once and would
unlink it if it was.

Linus Torvalds was not happy with the fact that recordmcount does this in
place modification. Instead of doing the unlink only if the file has two or
more hard links, it does the unlink all the time. In otherwords, it always
does a copy if it changed something. That is, it does the write out if a
change was made.

Signed-off-by: Steven Rostedt 
Signed-off-by: Zefan Li

scripts: recordmcount: break hardlinks

2016-10-26T15:15:38+00:00

commit dd39a26538e37f6c6131e829a4a510787e43c783 upstream.

recordmcount edits the file in-place, which can cause problems when
using ccache in hardlink mode.  Arrange for recordmcount to break a
hardlinked object.

Link: http://lkml.kernel.org/r/E1a7MVT-0000et-62@rmk-PC.arm.linux.org.uk

Signed-off-by: Russell King 
Signed-off-by: Steven Rostedt 
Signed-off-by: Zefan Li

recordmcount: Fix endianness handling bug for nop_mcount

2016-10-26T15:15:23+00:00

commit c84da8b9ad3761eef43811181c7e896e9834b26b upstream.

In nop_mcount, shdr->sh_offset and welp->r_offset should handle
endianness properly, otherwise it will trigger Segmentation fault
if the recordmcount main and file.o have different endianness.

Link: http://lkml.kernel.org/r/563806C7.7070606@huawei.com

Signed-off-by: Li Bin 
Signed-off-by: Steven Rostedt 
Signed-off-by: Zefan Li

localmodconfig: Use Kbuild files too

2016-03-21T01:17:51+00:00

commit c0ddc8c745b7f89c50385fd7aa03c78dc543fa7a upstream.

In kbuild it is allowed to define objects in files named "Makefile"
and "Kbuild".
Currently localmodconfig reads objects only from "Makefile"s and misses
modules like nouveau.

Link: http://lkml.kernel.org/r/1437948415-16290-1-git-send-email-richard@nod.at

Reported-and-tested-by: Leonidas Spyropoulos 
Signed-off-by: Richard Weinberger 
Signed-off-by: Steven Rostedt 
Signed-off-by: Zefan Li

scripts/recordmcount.pl: There is no -m32 gcc option on Super-H anymore

2015-04-14T09:33:54+00:00

commit 1caf6aaaa47471831d77c75f094d4e00ad1ec808 upstream.

Compiling SH with gcc-4.8 fails due to the -m32 option not being
supported.

From http://buildd.debian-ports.org/status/fetch.php?pkg=linux&arch=sh4&ver=3.16.7-ckt4-1&stamp=1421425783

      CC      init/main.o
    gcc-4.8: error: unrecognized command line option '-m32'
    ld: cannot find init/.tmp_mc_main.o: No such file or directory
    objcopy: 'init/.tmp_mx_main.o': No such file
    rm: cannot remove 'init/.tmp_mx_main.o': No such file or directory
    rm: cannot remove 'init/.tmp_mc_main.o': No such file or directory

Link: http://lkml.kernel.org/r/1421537778-29001-1-git-send-email-kernel@mkarcher.dialup.fu-berlin.de
Link: http://lkml.kernel.org/r/54BCBDD4.10102@physik.fu-berlin.de

Cc: Matt Fleming 
Reported-by: John Paul Adrian Glaubitz 
Signed-off-by: Michael Karcher 
Signed-off-by: Steven Rostedt 
Signed-off-by: Zefan Li

sched: add macros to define bitops for task atomic flags

2014-12-01T10:02:38+00:00

commit e0e5070b20e01f0321f97db4e4e174f3f6b49e50 upstream.

This will simplify code when we add new flags.

v3:
- Kees pointed out that no_new_privs should never be cleared, so we
shouldn't define task_clear_no_new_privs(). we define 3 macros instead
of a single one.

v2:
- updated scripts/tags.sh, suggested by Peter

Cc: Ingo Molnar 
Cc: Miao Xie 
Cc: Tetsuo Handa 
Acked-by: Peter Zijlstra (Intel) 
Acked-by: Kees Cook 
Signed-off-by: Zefan Li 
Signed-off-by: Tejun Heo 
[lizf: Backported to 3.4:
 - adjust context
 - remove no_new_priv code
 - add atomic_flags to struct task_struct]

recordmcount/MIPS: Fix possible incorrect mcount_loc table entries in modules

2014-07-07T01:49:19+00:00

commit 91ad11d7cc6f4472ebf177a6252fbf0fd100d798 upstream.

On MIPS calls to _mcount in modules generate 2 instructions to load
the _mcount address (and therefore 2 relocations). The mcount_loc
table should only reference the first of these, so the second is
filtered out by checking the relocation offset and ignoring ones that
immediately follow the previous one seen.

However if a module has an _mcount call at offset 0, the second
relocation would not be filtered out due to old_r_offset == 0
being taken to mean that the current relocation is the first one
seen, and both would end up in the mcount_loc table.

This results in ftrace_make_nop() patching both (adjacent)
instructions to branches over the _mcount call sequence like so:

  0xffffffffc08a8000:  04 00 00 10     b       0xffffffffc08a8014
  0xffffffffc08a8004:  04 00 00 10     b       0xffffffffc08a8018
  0xffffffffc08a8008:  2d 08 e0 03     move    at,ra
  ...

The second branch is in the delay slot of the first, which is
defined to be unpredictable - on the platform on which this bug was
encountered, it triggers a reserved instruction exception.

Fix by initializing old_r_offset to ~0 and using that instead of 0
to determine whether the current relocation is the first seen.

Signed-off-by: Alex Smith 
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/7098/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman

powerpc: Add vr save/restore functions

2014-05-18T12:25:56+00:00

commit 8fe9c93e7453e67b8bd09f263ec1bb0783c733fc upstream.

GCC 4.8 now generates out-of-line vr save/restore functions when
optimizing for size.  They are needed for the raid6 altivec support.

Signed-off-by: Andreas Schwab 
Signed-off-by: Benjamin Herrenschmidt 
Cc: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman

deb-pkg: Fix cross-building linux-headers package

2014-03-31T04:40:30+00:00

commit f8ce239dfc7ba9add41d9ecdc5e7810738f839fa upstream.

builddeb generates a control file that says the linux-headers package
can only be built for the build system primary architecture.  This
breaks cross-building configurations.  We should use $debarch for this
instead.

Since $debarch is not yet set when generating the control file, set
Architecture: any and use control file variables to fill in the
description.

Fixes: cd8d60a20a45 ('kbuild: create linux-headers package in deb-pkg')
Reported-and-tested-by: "Niew, Sh." 
Signed-off-by: Ben Hutchings 
Signed-off-by: Michal Marek 
Signed-off-by: Greg Kroah-Hartman