GitLab

commit a137802e upstream.

This causes kernel images that don't run init to completion with certain
broken gcc versions.

This fixes kernel bugzilla entry:
	http://bugzilla.kernel.org/show_bug.cgi?id=13012

I suspect the gcc problem is this:
	http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28230



Fix the problem by using the -fno-strict-overflow flag instead, which
not only does not exist in the known-to-be-broken versions of gcc (it
was introduced later than fwrapv), but seems to be much less disturbing
to gcc too: the difference in the generated code by -fno-strict-overflow
are smaller (compared to using neither flag) than when using -fwrapv.
Reported-by: Barry K. Nathan <barryn@pobox.com>
Pushed-by: Frans Pop <elendil@planet.nl>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit a3ca86ae upstream.

Turning on this flag could prevent the compiler from optimising away
some "useless" checks for null pointers.  Such bugs can sometimes become
exploitable at compile time because of the -O2 optimisation.

See http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Optimize-Options.html

An example that clearly shows this 'problem' is commit 6bf67672

.

 static void __devexit agnx_pci_remove(struct pci_dev *pdev)
 {
     struct ieee80211_hw *dev = pci_get_drvdata(pdev);
-    struct agnx_priv *priv = dev->priv;
+    struct agnx_priv *priv;
     AGNX_TRACE;

     if (!dev)
         return;
+    priv = dev->priv;

By reverting this patch, and compile it with and without
-fno-delete-null-pointer-checks flag, we can see that the check for dev
is compiled away.

    call    printk  #
-   testq   %r12, %r12  # dev
-   je  .L94    #,
    movq    %r12, %rdi  # dev,

Clearly the 'fix' is to stop using dev before it is tested, but building
with -fno-delete-null-pointer-checks flag at least makes it harder to
abuse.
Signed-off-by: Eugene Teo <eugeneteo@kernel.sg>
Acked-by: Eric Paris <eparis@redhat.com>
Acked-by: Wang Cong <amwang@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

The checking of CONFIG_FRAME_WARN in the top level Makefile forgot to
actually derefence the variable thus leading to an always true check.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Cc: Andi Kleen <ak@suse.de>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Correct the Makefile help text to read "make modules_prepare".
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>

Signed-off-by: Frédéric Brière <fbriere@fbriere.net>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>

We need a location for generated files.
Today they are spread over several places and bringing them
together to a common place makes it obvious hat is generated
and what isreal files.

Al Viro originally suggested: include/gen
Linus suggested to spell it out.

This patch implement support for

    include/generated

All files in include/generated are ignored by git.
include/generated is removed during "make mrproper".

With this we are ready to implement support for include/generated
in the various architctures and in the base kernel.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>

Make it possible for the linker to discard local symbols from vmlinux as
they cause vmlinux to balloon when CONFIG_KALLSYMS=y and they cause
dump_stack() and get_wchan() to produce useless information under some
circumstances.

With this we add a config option (CONFIG_STRIP_ASM_SYMS) that will cause
the build to supply -X to the linker to tell it to strip temporary local
symbols.

This doesn't seem to cause gdb any problems.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>

Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
Acked-by: Dmitry Gryazin <gdu@mns.spb.ru>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>

This adds in support for building with ARCH=sh64 using the sh SRCARCH.
This tidies up the randconfig generation somewhat to make sure that we
don't end up with impossible configurations, and without having to rely
on things like KCONFIG_ALLCONFIG to detect the proper CPU support subset.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>

With a sufficiently new compiler and binutils, code which wasn't
previously generating .eh_frame sections has begun to.  Certain
architectures (powerpc, in this case) may generate unexpected relocation
formats in response to this, preventing modules from loading.

While the new relocation types should probably be handled, revert to the
previous behaviour with regards to generation of .eh_frame sections.

(This was reported against Fedora, which appears to be the only distro
doing any building against gcc-4.4 at present: RH bz#486545.)
Signed-off-by: Kyle McMartin <kyle@redhat.com>
Acked-by: Roland McGrath <roland@redhat.com>
Cc: Alexandre Oliva <aoliva@redhat.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Sam Ravnborg says:
 "We have several architectures that plays strange games with $(CC) and
  $(CROSS_COMPILE).

  So we need to postpone any use of $(call cc-option..) until we have
  included the arch specific Makefile so we try with the correct $(CC)
  version."
Requested-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

This makes sure that gcc doesn't try to optimize away wrapping
arithmetic, which the kernel occasionally uses for overflow testing, ie
things like

	if (ptr + offset < ptr)

which technically is undefined for non-unsigned types. See

	http://bugzilla.kernel.org/show_bug.cgi?id=12597



for details.

Not all versions of gcc support it, so we need to make it conditional
(it looks like it was introduced in gcc-3.4).
Reminded-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Following a thread on busybox mailing list
depmod -r option is ignored by module-init-tools depmod
-r option break busybox depmod.

So the best solution look to remove -r from kernel Makefile
Signed-off-by: Gilles Espinasse <g.esp@free.fr>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>

Running 'make rpm' fails when CONFIG_LOCALVERSION_AUTO=y and using a kernel source
tree under SCM.  This is due to KERNELRELEASE being different when the initial make
is run and when make is run from rpmbuild.

mkspec creates kernel.spec using KERNELRELEASE:

<mkspec>
echo "%files"
echo '%defattr (-, root, root)'
echo "%dir /lib/modules"
echo "/lib/modules/$KERNELRELEASE"
echo "/lib/firmware"
echo "/boot/*"
echo ""
</mkspec>

When CONFIG_LOCALVERSION_AUTO=y scripts/setlocalversion is called and grabs any
additional version info from SCM.  Next, the srctree is tarred up and SCM
information is excluded.

rpmbuild reruns make and in the process generates a new include/config/kernel.release
and thus a new KERNELRELEASE.  However this time the SCM information is gone so
KERNELRELEASE no longer has the additional version information.  When "make modules_install"
runs, it uses the new KERNELRELEASE value to determine where to install the modules.
This conflicts with where the spec file assumes they are going because of the
mis-matching KERNELRELEASE versions.

<snippet>
+ INSTALL_MOD_PATH=/var/tmp/kernel-2.6.29rc4tip01479g5d85422-root
+ make -j16 modules_install
  INSTALL crypto/aead.ko
  INSTALL crypto/cbc.ko
  INSTALL crypto/chainiv.ko
  INSTALL crypto/crc32c.ko
  INSTALL crypto/crypto_algapi.ko
  INSTALL crypto/crypto_blkcipher.ko
  INSTALL crypto/crypto_hash.ko
  INSTALL crypto/cryptomgr.ko
  INSTALL crypto/ecb.ko
  INSTALL crypto/eseqiv.ko
  INSTALL crypto/krng.ko
  INSTALL crypto/md5.ko
  INSTALL crypto/pcbc.ko
  INSTALL crypto/rng.ko
  INSTALL drivers/block/cciss.ko
  INSTALL drivers/hid/hid-dummy.ko
  INSTALL drivers/scsi/iscsi_tcp.ko
  INSTALL drivers/scsi/libiscsi.ko
  INSTALL drivers/scsi/libiscsi_tcp.ko
  INSTALL drivers/scsi/scsi_transport_iscsi.ko
  INSTALL drivers/scsi/scsi_wait_scan.ko
  INSTALL fs/lockd/lockd.ko
  INSTALL fs/nfs/nfs.ko
  INSTALL fs/nfsd/nfsd.ko
  INSTALL lib/libcrc32c.ko
  INSTALL net/sunrpc/sunrpc.ko
  DEPMOD  2.6.29-rc4-tip
+ cp arch/x86/boot/bzImage
/var/tmp/kernel-2.6.29rc4tip01479g5d85422-root/boot/vmlinuz-2.6.29-rc4-tip-01479-g5d85422
+ cp System.map
/var/tmp/kernel-2.6.29rc4tip01479g5d85422-root/boot/System.map-2.6.29-rc4-tip-01479-g5d85422
+ cp .config
/var/tmp/kernel-2.6.29rc4tip01479g5d85422-root/boot/config-2.6.29-rc4-tip-01479-g5d85422
+ cp vmlinux vmlinux.orig
+ bzip2 -9 vmlinux
+ mv vmlinux.bz2
/var/tmp/kernel-2.6.29rc4tip01479g5d85422-root/boot/vmlinux-2.6.29-rc4-tip-01479-g5d85422.bz2
+ mv vmlinux.orig vmlinux
+ /usr/lib/rpm/brp-compress
Processing files: kernel-2.6.29rc4tip01479g5d85422-2
error: File not found:
/var/tmp/kernel-2.6.29rc4tip01479g5d85422-root/lib/modules/2.6.29-rc4-tip-01479-g5d85422

RPM build errors:
    File not found:
/var/tmp/kernel-2.6.29rc4tip01479g5d85422-root/lib/modules/2.6.29-rc4-tip-01479-g5d85422
make[1]: *** [rpm] Error 1
make: *** [rpm] Error 2
</snippet>

I have tested this patch on git -tip, Linus' git tree, and the kernel.org tar files, both
with and without CONFIG_LOCALVERSION_AUTO=y.
Signed-off-by: Josh Hunt <josh@scalex86.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
----

It's useful to already have the source symlink in a
objdir when one just runs make *config. Then one
can do

mkdir obj-allyes
cd obj-allyes
make -C ../sourcedir O=$(pwd) allyesconfig
./source/scripts/config --disable debug_info
make CC=icecc -j18

without having to interrupt the make first just to
get the source symlink.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
[sam: deleted the other source symlink statement]
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>

Impact: no default -fno-stack-protector if stackp is enabled, cleanup

Stackprotector make rules had the following problems.

* cc support test and warning are scattered across makefile and
  kernel/panic.c.

* -fno-stack-protector was always added regardless of configuration.

Update such that cc support test and warning are contained in makefile
and -fno-stack-protector is added iff stackp is turned off.  While at
it, prepare for 32bit support.
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>