11 Feb, 2009

1 commit


10 Feb, 2009

2 commits

  • Impact: stack protector for x86_32

    Implement stack protector for x86_32. GDT entry 28 is used for it.
    It's set to point to stack_canary-20 and have the length of 24 bytes.
    CONFIG_CC_STACKPROTECTOR turns off CONFIG_X86_32_LAZY_GS and sets %gs
    to the stack canary segment on entry. As %gs is otherwise unused by
    the kernel, the canary can be anywhere. It's defined as a percpu
    variable.

    x86_32 exception handlers take register frame on stack directly as
    struct pt_regs. With -fstack-protector turned on, gcc copies the
    whole structure after the stack canary and (of course) doesn't copy
    back on return thus losing all changed. For now, -fno-stack-protector
    is added to all files which contain those functions. We definitely
    need something better.

    Signed-off-by: Tejun Heo
    Signed-off-by: Ingo Molnar

    Tejun Heo
     
  • 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
    Signed-off-by: Ingo Molnar

    Tejun Heo
     

06 Feb, 2009

1 commit

  • Impact: fix link failure on certain toolchains with specific configs

    Recent percpu change made x86_64 split .data.init section into three
    separate segments - data.init, percpu and data.init2. data.init2 gets
    .data.nosave and .bss.* and is followed by .notes segment. Depending
    on configuration both segments might contain no data, in which case
    the tool chain makes the section header to contain offset beyond the
    end of the file.

    modpost isn't too happy about it and fails build - as reported by
    Pawel Dziekonski:

    Building modules, stage 2.
    MODPOST 416 modules
    FATAL: vmlinux is truncated. sechdrs[i].sh_offset=10354688 >
    sizeof(*hrd)=64
    make[1]: *** [__modpost] Error 1

    Teach modpost that NOBITS section may point beyond the end of the file
    and that .modinfo can't be NOBITS.

    Reported-by: Pawel Dziekonski
    Signed-off-by: Tejun Heo
    Signed-off-by: Ingo Molnar

    Tejun Heo
     

27 Jan, 2009

1 commit


21 Jan, 2009

1 commit


16 Jan, 2009

6 commits


15 Jan, 2009

2 commits

  • Requested by Sam.

    Signed-off-by: Andi Kleen
    Signed-off-by: Sam Ravnborg

    Andi Kleen
     
  • This reverts commit ad7a953c522ceb496611d127e51e278bfe0ff483.

    And commit: ("allow stripping of generated symbols under CONFIG_KALLSYMS_ALL")
    9bb482476c6c9d1ae033306440c51ceac93ea80c

    These stripping patches has caused a set of issues:

    1) People have reported compatibility issues with binutils due to
    lack of support for `--strip-unneeded-symbols' with objcopy 2.15.92.0.2
    Reported by: Wenji
    2) ccache and distcc no longer works as expeced
    Reported by: Ted, Roland, + others
    3) The installed modules increased a lot in size
    Reported by: Ted, Davej + others

    Reported-by: Wenji Huang
    Reported-by: "Theodore Ts'o"
    Reported-by: Dave Jones
    Reported-by: Roland McGrath
    Signed-off-by: Sam Ravnborg

    Sam Ravnborg
     

13 Jan, 2009

1 commit

  • There has been some light flamewar on lkml about decoding oopses
    in modules (as part of the crashdump flamewar).

    Now this isn't rocket science, just the markup_oops.pl script
    cheaped out and didn't handle modules. But really; a flamewar
    all about that?? What happened to C++ in the kernel or reading
    files from inside the kernel?

    This patch adds module support to markup_oops.pl; it's not the
    most pretty perl but it works for my testcases...

    Signed-off-by: Arjan van de Ven
    Signed-off-by: Linus Torvalds

    Arjan van de Ven
     

11 Jan, 2009

1 commit


08 Jan, 2009

4 commits

  • I often change single options in .config files. Instead of using
    an editor or one of the frontends it's convenient to do this from
    the command line. It's also useful to do from automated build scripts
    when building different variants from a base config file.

    I extracted most of the CONFIG manipulation code from one of my
    build scripts into a new shell script scripts/config

    The script is not integrated with the normal Kconfig machinery
    and doesn't do any checking against Kconfig files, but just manipulates
    that text format. This is always done at make time anyways.

    I believe this script would be a useful standard addition for scripts/*

    Sample usage:

    ./scripts/config --disable smp
    Disable SMP in .config file

    ./scripts/config --file otherdir/.config --module e1000e
    Enable E1000E as module in otherdir/.config

    ./scripts/config --state smp
    y
    Check state of config option CONFIG_SMP

    After merging into git please make scripts/config executable

    Signed-off-by: Andi Kleen
    Signed-off-by: Sam Ravnborg

    Andi Kleen
     
  • This patch reintroduce the ALLSOURCE_ARCHS support for tags/TAGS/
    cscope targets. The Kbuild previously has this feature, but after
    moving the targets into scripts/tags.sh, ALLSOURCE_ARCHS disappears.

    It's something like this:

    $ make ALLSOURCE_ARCHS="x86 mips arm" tags cscope

    Signed-off-by: Jike Song
    Signed-off-by: Sam Ravnborg

    Jike Song
     
  • Dave Jones, in his blog, had some feedback about the bootchart script:
    Primarily his complaint was that shorter delays weren't visualized.

    The reason for that was that too small delays will have their labels
    mixed up in the graph in an unreadable mess.

    This patch has a fix for this; for one, it makes the output wider,
    so more will fit.
    The second part is that smaller delays are now shown with a
    much smaller font for the label; while this isn't per se
    readable at a 1:1 zoom, at least you can zoom in with most SVG
    viewing applications and see what it is you are looking at.

    Signed-off-by: Arjan van de Ven
    Signed-off-by: Sam Ravnborg

    Arjan van de Ven
     
  • Rafael reported:

    I get the following error from 'make modules_install' on my test boxes:

    HOSTCC firmware/ihex2fw
    /home/rafael/src/linux-2.6/firmware/ihex2fw.c:268: fatal error: opening dependency file firmware/.ihex2fw.d: Read-only file system
    compilation terminated.
    make[3]: *** [firmware/ihex2fw] Error 1
    make[2]: *** [_modinst_post] Error 2
    make[1]: *** [sub-make] Error 2
    make: *** [all] Error 2

    where the configuration is that the kernel is compiled on a build box
    with 'make O= -j5' and then is mounted over NFS read-only by
    each test box (full path to this directory is the same on the build box and on
    the test boxes). Then, I cd into , run 'make modules_install' and get
    the error above.

    The issue turns out to be that we when we install firmware pick
    up the list of firmware blobs from firmware/Makefile.
    And this triggers the Makefile rules to update ihex2fw.

    There were two solutions for this issue:
    1) Move the list of firmware blobs to a separate file
    2) Avoid ihex2fw rebuild by moving it to scripts

    As I seriously beleive that the list of firmware blobs should be
    done in a fundamental different way solution 2) was selected.

    Reported-and-tested-by: "Rafael J. Wysocki"
    Signed-off-by: Sam Ravnborg
    Cc: David Woodhouse

    Sam Ravnborg
     

07 Jan, 2009

20 commits