litmus-rt-edfsc.git/scripts, branch wip-joshua

gcc-plugins: update gcc-common.h for gcc-7

2017-01-12T10:39:07+00:00

commit 81d873a87114b05dbb74d1fbf0c4322ba4bfdee4 upstream.

This updates gcc-common.h from Emese Revfy for gcc 7. This fixes issues seen
by Kugan and Arnd. Build tested with gcc 5.4 and 7 snapshot.

Signed-off-by: Kees Cook 
Signed-off-by: Greg Kroah-Hartman

kconfig/nconf: Fix hang when editing symbol with a long prompt

2017-01-09T07:32:25+00:00

commit 79e51b5c2deea542b3bb8c66e0d502230b017dde upstream.

Currently it is impossible to edit the value of a config symbol with a
prompt longer than (terminal width - 2) characters.  dialog_inputbox()
calculates a negative x-offset for the input window and newwin() fails
as this is invalid.  It also doesn't check for this failure, so it
busy-loops calling wgetch(NULL) which immediately returns -1.

The additions in the offset calculations also don't match the intended
size of the window.

Limit the window size and calculate the offset similarly to
show_scroll_win().

Fixes: 692d97c380c6 ("kconfig: new configuration interface (nconfig)")
Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

latent_entropy: fix ARM build error on earlier gcc

2017-01-09T07:32:22+00:00

commit 9988f4d577f42f43b7612d755477585f35424af7 upstream.

This fixes build errors seen on gcc-4.9.3 or gcc-5.3.1 for an ARM:

arm-soc/init/initramfs.c: In function 'error':
arm-soc/init/initramfs.c:50:1: error: unrecognizable insn:
 }
 ^
(insn 26 25 27 5 (set (reg:SI 111 [ local_entropy.243 ])
        (rotatert:SI (reg:SI 116 [ local_entropy.243 ])
            (const_int -30 [0xffffffffffffffe2]))) -1
     (nil))

Patch from PaX Team 

Reported-by: Arnd Bergmann 
Reported-by: Brad Spengler 
Signed-off-by: Kees Cook 
Signed-off-by: Greg Kroah-Hartman

builddeb: fix cross-building to arm64 producing host-arch debs

2017-01-06T09:40:17+00:00

commit 152b695d74376bfe55cd2a6265ccc75b0d39dd19 upstream.

Both Debian and kernel archs are "arm64" but UTS_MACHINE and gcc say
"aarch64".  Recognizing just the latter should be enough but let's
accept both in case something regresses again or an user sets
UTS_MACHINE=arm64.

Regressed in cfa88c7: arm64: Set UTS_MACHINE in the Makefile.

Signed-off-by: Adam Borowski 
Acked-by: Riku Voipio 
Signed-off-by: Michal Marek 
Signed-off-by: Greg Kroah-Hartman

kbuild: make sure autoksyms.h exists early

2016-12-01T18:19:22+00:00

Some people are able to trigger a race where autoksyms.h is used before
its empty version is even created.  Let's create it at the same time as
the directory holding it is created.

Signed-off-by: Nicolas Pitre 
Tested-by: Prarit Bhargava 
Tested-by: Jarod Wilson 
Signed-off-by: Linus Torvalds

Merge branch 'rc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild

2016-11-19T00:45:21+00:00

Pull kbuild fixes from Michal Marek:
 "Here are some regression fixes for kbuild:

   - modversion support for exported asm symbols (Nick Piggin). The
     affected architectures need separate patches adding
     asm-prototypes.h.

   - fix rebuilds of lib-ksyms.o (Nick Piggin)

   - -fno-PIE builds (Sebastian Siewior and Borislav Petkov). This is
     not a kernel regression, but one of the Debian gcc package.
     Nevertheless, it's quite annoying, so I think it should go into
     mainline and stable now"

* 'rc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild:
  kbuild: Steal gcc's pie from the very beginning
  kbuild: be more careful about matching preprocessed asm ___EXPORT_SYMBOL
  x86/kexec: add -fno-PIE
  scripts/has-stack-protector: add -fno-PIE
  kbuild: add -fno-PIE
  kbuild: modversions for EXPORT_SYMBOL() for asm
  kbuild: prevent lib-ksyms.o rebuilds

Merge branch 'maybe-uninitialized' (patches from Arnd)

2016-11-11T18:03:01+00:00

Merge fixes for -Wmaybe-uninitialized from Arnd Bergmann:
 "It took a while for some patches to make it into mainline through
  maintainer trees, but the 28-patch series is now reduced to 10, with
  one tiny patch added at the end.

  Aside from patches that are no longer required, I did these changes
  compared to version 1:

   - Dropped "iio: maxim_thermocouple: detect invalid storage size in
     read()", which is currently in linux-next as commit 32cb7d27e65d.
     This is the only remaining warning I see for a couple of corner
     cases (kbuild bot reports it on blackfin, kernelci bot and arm-soc
     bot both report it on arm64)

   - Dropped "brcmfmac: avoid maybe-uninitialized warning in
     brcmf_cfg80211_start_ap", which is currently in net/master merge
     pending.

   - Dropped two x86 patches, "x86: math-emu: possible uninitialized
     variable use" and "x86: mark target address as output in 'insb'
     asm" as they do not seem to trigger for a default build, and I got
     no feedback on them. Both of these are ancient issues and seem
     harmless, I will send them again to the x86 maintainers once the
     rest is merged.

   - Dropped "rbd: false-postive gcc-4.9 -Wmaybe-uninitialized" based on
     feedback from Ilya Dryomov, who already has a different fix queued
     up for v4.10. The kbuild bot reports this as a warning for xtensa.

   - Replaced "crypto: aesni: avoid -Wmaybe-uninitialized warning" with
     a simpler patch, this one always triggers but my first solution
     would not be safe for linux-4.9 any more at this point. I'll follow
     up with the larger patch as a cleanup for 4.10.

   - Replaced "dib0700: fix nec repeat handling" with a better one,
     contributed by Sean Young"

* -Wmaybe-uninitialized fixes:
  Kbuild: enable -Wmaybe-uninitialized warnings by default
  pcmcia: fix return value of soc_pcmcia_regulator_set
  infiniband: shut up a maybe-uninitialized warning
  crypto: aesni: shut up -Wmaybe-uninitialized warning
  rc: print correct variable for z8f0811
  dib0700: fix nec repeat handling
  s390: pci: don't print uninitialized data for debugging
  nios2: fix timer initcall return value
  x86: apm: avoid uninitialized data
  NFSv4.1: work around -Wmaybe-uninitialized warning
  Kbuild: enable -Wmaybe-uninitialized warning for "make W=1"

Kbuild: enable -Wmaybe-uninitialized warnings by default

2016-11-11T16:45:08+00:00

Previously the warnings were added back at the W=1 level and above, this
now turns them on again by default, assuming that we have addressed all
warnings and again have a clean build for v4.10.

I found a number of new warnings in linux-next already and submitted
bugfixes for those.  Hopefully they are caught by the 0day builder in
the future as soon as this patch is merged.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Linus Torvalds

Kbuild: enable -Wmaybe-uninitialized warning for "make W=1"

2016-11-11T16:45:08+00:00

Traditionally, we have always had warnings about uninitialized variables
enabled, as this is part of -Wall, and generally a good idea [1], but it
also always produced false positives, mainly because this is a variation
of the halting problem and provably impossible to get right in all cases
[2].

Various people have identified cases that are particularly bad for false
positives, and in commit e74fc973b6e5 ("Turn off -Wmaybe-uninitialized
when building with -Os"), I turned off the warning for any build that
was done with CC_OPTIMIZE_FOR_SIZE.  This drastically reduced the number
of false positive warnings in the default build but unfortunately had
the side effect of turning the warning off completely in 'allmodconfig'
builds, which in turn led to a lot of warnings (both actual bugs, and
remaining false positives) to go in unnoticed.

With commit 877417e6ffb9 ("Kbuild: change CC_OPTIMIZE_FOR_SIZE
definition") enabled the warning again for allmodconfig builds in v4.7
and in v4.8-rc1, I had finally managed to address all warnings I get in
an ARM allmodconfig build and most other maybe-uninitialized warnings
for ARM randconfig builds.

However, commit 6e8d666e9253 ("Disable "maybe-uninitialized" warning
globally") was merged at the same time and disabled it completely for
all configurations, because of false-positive warnings on x86 that I had
not addressed until then.  This caused a lot of actual bugs to get
merged into mainline, and I sent several dozen patches for these during
the v4.9 development cycle.  Most of these are actual bugs, some are for
correct code that is safe because it is only called under external
constraints that make it impossible to run into the case that gcc sees,
and in a few cases gcc is just stupid and finds something that can
obviously never happen.

I have now done a few thousand randconfig builds on x86 and collected
all patches that I needed to address every single warning I got (I can
provide the combined patch for the other warnings if anyone is
interested), so I hope we can get the warning back and let people catch
the actual bugs earlier.

This reverts the change to disable the warning completely and for now
brings it back at the "make W=1" level, so we can get it merged into
mainline without introducing false positives.  A follow-up patch enables
it on all levels unless some configuration option turns it off because
of false-positives.

Link: https://rusty.ozlabs.org/?p=232 [1]
Link: https://gcc.gnu.org/wiki/Better_Uninitialized_Warnings [2]
Signed-off-by: Arnd Bergmann 
Signed-off-by: Linus Torvalds

scripts/bloat-o-meter: fix SIGPIPE

2016-11-11T16:12:37+00:00

Fix piping output to a program which quickly exits (read: head -n1)

	$ ./scripts/bloat-o-meter ../vmlinux-000 ../obj/vmlinux | head -n1
	add/remove: 0/0 grow/shrink: 9/60 up/down: 124/-305 (-181)
	close failed in file object destructor:
	sys.excepthook is missing
	lost sys.stderr

Link: http://lkml.kernel.org/r/20161028204618.GA29923@avx2
Signed-off-by: Alexey Dobriyan 
Cc: Matt Mackall 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds