Eric Lee / smarc-fsl-linux-kernel

17 Mar, 2008

1 commit

10 Mar, 2008

1 commit

05 Mar, 2008

1 commit

25 Feb, 2008

1 commit

19 Feb, 2008

1 commit

16 Feb, 2008

1 commit

15 Feb, 2008

2 commits

  • cf87dcd14   kbuild: fix building vmlinux.o ... Browse Code »

    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: Sam Ravnborg
    Cc: Ingo Molnar
    Cc: Roland McGrath

    Sam Ravnborg
     
  • e06b8b98d   kbuild: allow -fstack-protector to take effect ... Browse Code »

    Arjan van de Ven 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: Sam Ravnborg
    Cc: Arjan van de Ven
    Cc: stable@kernel.org

    Sam Ravnborg
     

11 Feb, 2008

1 commit

03 Feb, 2008

1 commit

29 Jan, 2008

9 commits

28 Jan, 2008

1 commit

25 Jan, 2008

1 commit

22 Jan, 2008

1 commit

16 Jan, 2008

1 commit

07 Jan, 2008

1 commit

21 Dec, 2007

1 commit

11 Dec, 2007

1 commit

09 Dec, 2007

2 commits

  • 18c32dac7   kbuild: fix building with O=.. options ... Browse Code »

    The check introduced in commit:
    4f1127e204377cbd2a56d112d323466f668e8334 "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: Sam Ravnborg
    Tested-by: Jay Cliburn
    Cc: Jay Cliburn

    Sam Ravnborg
     
  • 1cacc9ab8   kbuild: fix building with redirected output. ... Browse Code »

    Jan Altenberg 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: Sam Ravnborg

    Sam Ravnborg
     

04 Dec, 2007

1 commit

18 Nov, 2007

1 commit

  • 80ef88d6d   x86: simplify "make ARCH=x86" and fix kconfig all.config ... Browse Code »

    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:
    0f855aa64b3f63d35a891510cf7db932a435c116
    -> kconfig: add helper to set config symbol from environment variable

    2a113281f5cd2febbab21a93c8943f8d3eece4d3
    -> 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: Sam Ravnborg
    Cc: Roman Zippel
    Cc: Andreas Herrmann
    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Cc: "H. Peter Anvin"

    Sam Ravnborg
     

17 Nov, 2007

2 commits

13 Nov, 2007

2 commits

  • daa93fab8   x86: enable "make ARCH=x86" ... Browse Code »

    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: Sam Ravnborg
    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Cc: "H. Peter Anvin"

    Sam Ravnborg
     
  • d746d647f   x86: do not use $(ARCH) when not needed ... Browse Code »

    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: Sam Ravnborg
    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Cc: "H. Peter Anvin"

    Sam Ravnborg
     

07 Nov, 2007

1 commit

05 Nov, 2007

1 commit

  • 69ee0b352   kbuild: do not pick up CFLAGS from the environment ... Browse Code »
    44

    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: Sam Ravnborg
    Cc: Thomas Bächler
    Cc: David Miller
    Cc: Ingo Molnar

    Sam Ravnborg
     

02 Nov, 2007

1 commit

  • 236b19574   sh: Correct SUBARCH matching. ... Browse Code »

    When configuring the kernel natively the uname matching is off,
    so fix up the uname mangling to get the proper SUBARCH. Needs
    an explicit range so that SH-5 doesn't break.

    Signed-off-by: Mike Frysinger
    Signed-off-by: Paul Mundt

    Paul Mundt
     

26 Oct, 2007

1 commit

24 Oct, 2007

1 commit

  • c9927c2bf   Linux 2.6.24-rc1 ... Browse Code »

    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: Linus Torvalds

    Linus Torvalds
     

23 Oct, 2007

1 commit

  • d8d2e78a0   kbuild: allow depmod in cross builds again ... Browse Code »

    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: Sam Ravnborg
    Cc: Geert Uytterhoeven

    Sam Ravnborg