1. 09 Mar, 2008 1 commit
  2. 04 Mar, 2008 1 commit
  3. 24 Feb, 2008 1 commit
  4. 15 Feb, 2008 1 commit
  5. 14 Feb, 2008 2 commits
    • Sam Ravnborg's avatar
      kbuild: fix building vmlinux.o · cf87dcd1
      Sam Ravnborg authored
      Ingo Molnar wrote:
      >
      > i've got a build log from a weird build error below:
      >
      >   LD      init/built-in.o
      > distcc[12023] ERROR: compile (null) on localhost failed
      > make: *** [vmlinux.o] Error 1
      > make: *** Waiting for unfinished jobs....
      >   LD      .tmp_vmlinux1
      >
      
      Building vmlinux.o were moved up in the dependency chain so we started
      to build it before the kallsym stuff. This was done to let modpost
      report section mismatch bugs even when the final link failed.
      
      Originally I had expected the dependency of $(kallsyms.o) to
      cover this but it turns out that we need to be even more explicit.
      Fix this by adding a conditional dependency on firat target
      used in the kallsyms serie of builds.
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Roland McGrath <roland@redhat.com>
      cf87dcd1
    • Sam Ravnborg's avatar
      kbuild: allow -fstack-protector to take effect · e06b8b98
      Sam Ravnborg authored
      Arjan van de Ven <arjan@infradead.org> wrote:
      ===
      I just read the excellent LWN writeup of the vmsplice
      security thing, and that got me wondering why this attack
      wasn't stopped by the CONFIG_CC_STACKPROTECTOR option...
      because it plain should have been...
      
      Some analysis later.. it turns out that the following line
      in the top level Makefile, added by you in October 2007,
      entirely disables CONFIG_CC_STACKPROTECTOR ;(
      With this line removed the exploit will be nicely stopped.
      
      CFLAGS          += $(call cc-option, -fno-stack-protector)
      
      Now I realize that certain distros have patched gcc to
      compensate for their lack of distro wide CFLAGS, and it's
      great to work around that... but would there be a way to NOT
      disable this for CONFIG_CC_STACKPROTECTOR please?
      It would have made this exploit not possible for those kernels
      that enable this feature (and that includes distros like Fedora)
      ===
      
      Move the assignment to KBUILD_CFLAGS up before including
      the arch specific Makefile so arch makefiles may override
      the setting.
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Cc: Arjan van de Ven <arjan@infradead.org>
      Cc: stable@kernel.org
      e06b8b98
  6. 10 Feb, 2008 1 commit
    • Linus Torvalds's avatar
      Linux 2.6.25-rc1 · 19af3554
      Linus Torvalds authored
      .. and I really need to call it something else.  Maybe it is time to
      bring back the weasel series, since weasels always make me feel good
      about a kernel.
      19af3554
  7. 03 Feb, 2008 1 commit
  8. 28 Jan, 2008 9 commits
  9. 27 Jan, 2008 1 commit
  10. 24 Jan, 2008 1 commit
  11. 21 Jan, 2008 1 commit
  12. 15 Jan, 2008 1 commit
  13. 06 Jan, 2008 1 commit
  14. 20 Dec, 2007 1 commit
  15. 10 Dec, 2007 1 commit
  16. 09 Dec, 2007 2 commits
    • Sam Ravnborg's avatar
      kbuild: fix building with O=.. options · 18c32dac
      Sam Ravnborg authored
      The check introduced in commit:
      4f1127e2 "kbuild: fix
      infinite make recursion"
      
      caused certain external modules not to build and
      also caused 'make targz-pkg' to fail.
      This is a minimal fix so we revert to previous
      behaviour - but we do not overwrite the Makefile
      in the top-level directory.
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Tested-by: default avatarJay Cliburn <jacliburn@bellsouth.net>
      Cc: Jay Cliburn <jacliburn@bellsouth.net>
      18c32dac
    • Sam Ravnborg's avatar
      kbuild: fix building with redirected output. · 1cacc9ab
      Sam Ravnborg authored
      Jan Altenberg <jan.altenberg@linutronix.de> reported that
      building with redirected input like this failed:
      make O=dir oldconfig bzImage < /dev/null
      
      The problem were caused by a make silentoldconfig being
      run before oldconfig and with a non-recent .config the build
      failed because silentoldconfig requires non-redirected stdin.
      
      Silentoldconfig was run as a side-effect of having the
      top-level Makefile re-made by make.
      Introducing an empty rule for the top-level Makefile
      (and Kbuild.include) fixed the issue.
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      1cacc9ab
  17. 03 Dec, 2007 1 commit
  18. 17 Nov, 2007 3 commits
    • Sam Ravnborg's avatar
      x86: simplify "make ARCH=x86" and fix kconfig all.config · 6840999b
      Sam Ravnborg authored
      Simplify "make ARCH=x86" and fix kconfig so we again can set 64BIT in
      all.config.
      
      For a fix the diffstat is nice:
       6 files changed, 3 insertions(+), 36 deletions(-)
      
      The patch reverts these commits:
       - 0f855aa6 ("kconfig: add helper to set
         config symbol from environment variable")
       - 2a113281 ("kconfig: use $K64BIT to
         set 64BIT with all*config targets")
      
      Roman Zippel pointed out that kconfig supported string compares so
      the additional complexity introduced by the above two patches were
      not needed.
      
      With this patch we have following behaviour:
      
        # make {allno,allyes,allmod,rand}config [ARCH=...]
        option \ host arch      | 32bit         | 64bit
        =====================================================
        ./.                     | 32bit         | 64bit
        ARCH=x86                | 32bit         | 32bit
        ARCH=i386               | 32bit         | 32bit
        ARCH=x86_64             | 64bit         | 64bit
      
      The general rule are that ARCH= and native architecture takes
      precedence over the configuration.
      
      So make ARCH=i386 [whatever] will always build a 32-bit kernel
      no matter what the configuration says.  The configuration will
      be updated to 32-bit if it was configured to 64-bit and the
      other way around.
      
      This behaviour is consistent with previous behaviour so no
      suprises here.
      
      make ARCH=x86 will per default result in a 32-bit kernel but as
      the only ARCH= value x86 allow the user to select between 32-bit
      and 64-bit using menuconfig.
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Cc: Andreas Herrmann <aherrman@arcor.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      6840999b
    • Sam Ravnborg's avatar
      x86: simplify "make ARCH=x86" and fix kconfig all.config · 80ef88d6
      Sam Ravnborg authored
      Simplify "make ARCH=x86" and fix kconfig so we again
      can set 64BIT in all.config.
      
      For a fix the diffstat is nice:
       6 files changed, 3 insertions(+), 36 deletions(-)
      
      The patch reverts these commits:
      0f855aa6
      -> kconfig: add helper to set config symbol from environment variable
      
      2a113281
      -> kconfig: use $K64BIT to set 64BIT with all*config targets
      
      Roman Zippel pointed out that kconfig supported string
      compares so the additional complexity introduced by the
      above two patches were not needed.
      
      With this patch we have following behaviour:
      
      # make {allno,allyes,allmod,rand}config [ARCH=...]
      option \ host arch      | 32bit         | 64bit
      =====================================================
      ./.                     | 32bit         | 64bit
      ARCH=x86                | 32bit         | 32bit
      ARCH=i386               | 32bit         | 32bit
      ARCH=x86_64             | 64bit         | 64bit
      
      The general rule are that ARCH= and native architecture
      takes precedence over the configuration.
      So make ARCH=i386 [whatever] will always build a 32-bit
      kernel no matter what the configuration says.
      The configuration will be updated to 32-bit if it was
      configured to 64-bit and the other way around.
      
      This behaviour is consistent with previous behaviour so
      no suprises here.
      
      make ARCH=x86 will per default result in a 32-bit kernel
      but as the only ARCH= value x86 allow the user to select
      between 32-bit and 64-bit using menuconfig. 
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Cc: Andreas Herrmann <aherrman@arcor.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      80ef88d6
    • Thomas Gleixner's avatar
      Remove x86 merge artifact from top Makefile · d0974b11
      Thomas Gleixner authored
      The x86 merge modified the tags target to handle the two separate
      source directories. Remove it now that i386/x86_64 are gone completely.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      d0974b11
  19. 16 Nov, 2007 1 commit
  20. 12 Nov, 2007 2 commits
    • Sam Ravnborg's avatar
      x86: enable "make ARCH=x86" · daa93fab
      Sam Ravnborg authored
      After unification of the Kconfig files and
      introducing K64BIT support in kconfig
      it required only trivial changes to enable
      "make ARCH=x86".
      
      With this patch you can build for x86_64 in several ways:
      1) make ARCH=x86_64
      2) make ARCH=x86 K64BIT=y
      3) make ARCH=x86 menuconfig
         => select 64-bit
      
      Likewise for i386 with the addition that
      i386 is default is you say ARCH=x86.
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      daa93fab
    • Sam Ravnborg's avatar
      x86: do not use $(ARCH) when not needed · d746d647
      Sam Ravnborg authored
      For x86 ARCH may say i386 or x86_64 and soon x86.
      Rely on CONFIG_X64_32 to select between 32/64 or just
      hardcode the value as appropriate.
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      d746d647
  21. 06 Nov, 2007 1 commit
  22. 04 Nov, 2007 1 commit
    • Sam Ravnborg's avatar
      kbuild: do not pick up CFLAGS from the environment · 69ee0b35
      Sam Ravnborg authored
      Too many people have CFLAGS set to support building userspace.
      And now Kbuild picks up CFLAGS this caused troubles.
      
      Although people should realise that setting CFLAGS has
      a 'global' effect the impact on the kernel build is a suprise.
      So change kbuild to pick up value from KCFLAGS that is
      much less used.
      
      When kbuild pick up a value it will warn like this:
      Makefile:544: "WARNING: Appending $KCFLAGS (-O3) from environment to kernel $CFLAGS"
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Cc: Thomas Bächler <thomas@archlinux.org>
      Cc: David Miller <davem@davemloft.net>
      Cc: Ingo Molnar <mingo@redhat.com>
      69ee0b35
  23. 01 Nov, 2007 1 commit
  24. 25 Oct, 2007 1 commit
  25. 23 Oct, 2007 1 commit
    • Linus Torvalds's avatar
      Linux 2.6.24-rc1 · c9927c2b
      Linus Torvalds authored
      The patch is big.  Really big.  You just won't believe how vastly hugely
      mindbogglingly big it is.  I mean you may think it's a long way down the
      road to the chemist, but that's just peanuts to how big the patch from
      2.6.23 is.
      
      But it's all good.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c9927c2b
  26. 22 Oct, 2007 2 commits
    • Sam Ravnborg's avatar
      kbuild: allow depmod in cross builds again · d8d2e78a
      Sam Ravnborg authored
      depmod from module-init-tools 3.3-pre2 are reported
      to work fine in cross build.
      depmod from module-init-tools 3.1-pre5 are known to SEGV
      
      Do not workaround older module-init-tools bugs here.
      The right fix is for users to upgrade module-init-tools.
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      d8d2e78a
    • Sam Ravnborg's avatar
      kbuild: fix modules_install after a 'make vmlinux' · ab19f879
      Sam Ravnborg authored
      make vmlinux would delete the content of $(MODVERDIR)
      equals .tmp_versions. This caused a subsequent
      make modules_install to fail.
      
      Fix it so we clean the directory only for the
      modules build - but we still unconditionally create it so
      we can do:
      make dir/file.ko
      without a preceeding make modules.
      
      Reported by David Miller <davem@davemloft.net>
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Cc: David Miller <davem@davemloft.net>
      ab19f879