Eric Lee / smarc-fsl-linux-kernel

03 Oct, 2019

1 commit

  • 87d6021b8   x86/math-emu: Limit MATH_EMULATION to 486SX compatibles ... Browse Code »

    The FPU emulation code is old and fragile in places, try to limit its
    use to builds for CPUs that actually use it. As far as I can tell,
    this is only true for i486sx compatibles, including the Cyrix 486SLC,
    AMD Am486SX and ÉLAN SC410, UMC U5S amd DM&P VortexSX86, all of which
    were relatively short-lived and got replaced with i486DX compatible
    processors soon after introduction, though some of the embedded versions
    remained available much longer.

    Signed-off-by: Arnd Bergmann
    Signed-off-by: Borislav Petkov
    Reviewed-by: Kees Cook
    Cc: "H. Peter Anvin"
    Cc: Andrew Morton
    Cc: Bill Metzenthen
    Cc: Ingo Molnar
    Cc: Masahiro Yamada
    Cc: Thomas Gleixner
    Cc: x86-ml
    Link: https://lkml.kernel.org/r/20191001142344.1274185-2-arnd@arndb.de

    Arnd Bergmann
     

02 Nov, 2017

1 commit

  • b24413180   License cleanup: add SPDX GPL-2.0 license identifier to files with no license ... Browse Code »

    Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

25 Jun, 2017

1 commit

  • 39a33ff80   kbuild: remove cc-option-align ... Browse Code »

    Documentation/kbuild/makefiles.txt says the change for align options
    occurred at GCC 3.0, and Documentation/process/changes.rst says the
    minimal supported GCC version is 3.2, so it should be safe to hard-code
    -falign* options.

    Fix the only user arch/x86/Makefile_32.cpu and remove cc-option-align.

    Signed-off-by: Masahiro Yamada
    Acked-by: Ingo Molnar

    Masahiro Yamada
     

30 Mar, 2017

1 commit

  • 3f135e57a   x86/build: Mostly disable '-maccumulate-outgoing-args' ... Browse Code »

    The GCC '-maccumulate-outgoing-args' flag is enabled for most configs,
    mostly because of issues which are no longer relevant. For most
    configs, and with most recent versions of GCC, it's no longer needed.

    Clarify which cases need it, and only enable it for those cases. Also
    produce a compile-time error for the ftrace graph + mcount + '-Os' case,
    which will otherwise cause runtime failures.

    The main benefit of '-maccumulate-outgoing-args' is that it prevents an
    ugly prologue for functions which have aligned stacks. But removing the
    option also has some benefits: more readable argument saves, smaller
    text size, and (presumably) slightly improved performance.

    Here are the object size savings for 32-bit and 64-bit defconfig
    kernels:

    text data bss dec hex filename
    10006710 3543328 1773568 15323606 e9d1d6 vmlinux.x86-32.before
    9706358 3547424 1773568 15027350 e54c96 vmlinux.x86-32.after

    text data bss dec hex filename
    10652105 4537576 843776 16033457 f4a6b1 vmlinux.x86-64.before
    10639629 4537576 843776 16020981 f475f5 vmlinux.x86-64.after

    That comes out to a 3% text size improvement on x86-32 and a 0.1% text
    size improvement on x86-64.

    Signed-off-by: Josh Poimboeuf
    Cc: Andrew Lutomirski
    Cc: Andy Lutomirski
    Cc: Borislav Petkov
    Cc: Brian Gerst
    Cc: Denys Vlasenko
    Cc: Linus Torvalds
    Cc: Pavel Machek
    Cc: Peter Zijlstra
    Cc: Steven Rostedt
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/20170316193133.zrj6gug53766m6nn@treble
    Signed-off-by: Ingo Molnar

    Josh Poimboeuf
     

30 Nov, 2012

1 commit

09 Apr, 2011

1 commit

  • ce9c99af8   x86, cpu: Move AMD Elan Kconfig under "Processor family" ... Browse Code »

    Currently the option resides under X86_EXTENDED_PLATFORM due to historical
    nonstandard A20M# handling. However that is no longer the case and so Elan can
    be treated as part of the standard processor choice Kconfig option.

    Signed-off-by: Ian Campbell
    Link: http://lkml.kernel.org/r/1302245177.31620.47.camel@localhost.localdomain
    Cc: H. Peter Anvin
    Signed-off-by: H. Peter Anvin

    Ian Campbell
     

30 Oct, 2010

1 commit

  • 45f81b1c9   jump label: Add work around to i386 gcc asm goto bug ... Browse Code »

    On i386 (not x86_64) early implementations of gcc would have a bug
    with asm goto causing it to produce code like the following:

    (This was noticed by Peter Zijlstra)

    56 pushl 0
    67 nopl jmp 0x6f
    popl
    jmp 0x8c

    6f mov
    test
    je 0x8c

    8c mov
    call *(%esp)

    The jump added in the asm goto skipped over the popl that matched
    the pushl 0, which lead up to a quick crash of the system when
    the jump was enabled. The nopl is defined in the asm goto () statement
    and when tracepoints are enabled, the nop changes to a jump to the label
    that was specified by the asm goto. asm goto is suppose to tell gcc that
    the code in the asm might jump to an external label. Here gcc obviously
    fails to make that work.

    The bug report for gcc is here:

    http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46226

    The bug only appears on x86 when not compiled with
    -maccumulate-outgoing-args. This option is always set on x86_64 and it
    is also the work around for a function graph tracer i386 bug.
    (See commit: 746357d6a526d6da9d89a2ec645b28406e959c2e)
    This explains why the bug only showed up on i386 when function graph
    tracer was not enabled.

    This patch now adds a CONFIG_JUMP_LABEL option that is default
    off instead of using jump labels by default. When jump labels are
    enabled, the -maccumulate-outgoing-args will be used (causing a
    slightly larger kernel image on i386). This option will exist
    until we have a way to detect if the gcc compiler in use is safe
    to use on all configurations without the work around.

    Note, there exists such a test, but for now we will keep the enabling
    of jump label as a manual option.

    Archs that know the compiler is safe with asm goto, may choose to
    select JUMP_LABEL and enable it by default.

    Reported-by: Ingo Molnar
    Cause-discovered-by: Peter Zijlstra
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: Jason Baron
    Cc: H. Peter Anvin
    Cc: David Daney
    Cc: Mathieu Desnoyers
    Cc: Masami Hiramatsu
    Cc: David Miller
    Cc: Richard Henderson
    LKML-Reference:
    Signed-off-by: Steven Rostedt

    Steven Rostedt
     

09 Dec, 2009

1 commit

  • 86ed4aa45   Merge branch 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/… ... Browse Code »

    …git/tip/linux-2.6-tip

    * 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
    x86, mce: don't restart timer if disabled
    x86: Use -maccumulate-outgoing-args for sane mcount prologues
    x86: Prevent GCC 4.4.x (pentium-mmx et al) function prologue wreckage
    x86: AMD Northbridge: Verify NB's node is online
    x86 VSDO: Fix Kconfig help
    x86: Fix typo in Intel CPU cache size descriptor
    x86: Add new Intel CPU cache size descriptors

    Linus Torvalds
     

28 Nov, 2009

1 commit

  • b8b7d791a   x86: Use -maccumulate-outgoing-args for sane mcount prologues ... Browse Code »

    commit 746357d (x86: Prevent GCC 4.4.x (pentium-mmx et al) function
    prologue wreckage) uses -mtune=generic to work around the function
    prologue problem with mcount on -march=pentium-mmx and others.

    Jakub pointed out that we can use -maccumulate-outgoing-args instead
    which is selected by -mtune=generic and prevents the problem without
    losing the -march specific optimizations.

    Pointed-out-by: Jakub Jelinek
    Signed-off-by: Thomas Gleixner
    Cc: Linus Torvalds
    Cc: stable@kernel.org

    Thomas Gleixner
     

20 Nov, 2009

1 commit

  • 746357d6a   x86: Prevent GCC 4.4.x (pentium-mmx et al) function prologue wreckage ... Browse Code »

    When the kernel is compiled with -pg for tracing GCC 4.4.x inserts
    stack alignment of a function _before_ the mcount prologue if the
    -march=pentium-mmx is set and -mtune=generic is not set. This breaks
    the assumption of the function graph tracer which expects that the
    mcount prologue

    push %ebp
    mov %esp, %ebp

    is the first stack operation in a function because it needs to modify
    the function return address on the stack to trap into the tracer
    before returning to the real caller.

    The generated code is:

    push %edi
    lea 0x8(%esp),%edi
    and $0xfffffff0,%esp
    pushl -0x4(%edi)
    push %ebp
    mov %esp,%ebp

    so the tracer modifies the copy of the return address which is stored
    after the stack alignment and therefor does not trap the return which
    in turn breaks the call chain logic of the tracer and leads to a
    kernel panic.

    Aside of the fact that the generated code is horrible for no good
    reason other -march -mtune options generate the expected:

    push %ebp
    mov %esp,%ebp
    and $0xfffffff0,%esp

    which does the same and keeps everything intact.

    After some experimenting we found out that this problem is restricted
    to gcc4.4.x and to the following -march settings:

    i586, pentium, pentium-mmx, k6, k6-2, k6-3, winchip-c6, winchip2, c3,
    geode

    By adding -mtune=generic the code generator produces always the
    expected code.

    So forcing -mtune=generic when CONFIG_FUNCTION_GRAPH_TRACER=y is not
    pretty, but at the moment the only way to prevent that the kernel
    trips over gcc-shrooms induced code madness.

    Most distro kernels have CONFIG_X86_GENERIC=y anyway which forces
    -mtune=generic as well so it will not impact those.

    References: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42109
    http://lkml.org/lkml/2009/11/19/17

    Signed-off-by: Thomas Gleixner
    LKML-Reference:
    Cc: Linus Torvalds
    Cc: Andrew Morton
    Cc: Ingo Molnar
    Cc: Peter Zijlstra
    Cc: H. Peter Anvin
    Cc: Steven Rostedt
    Cc: Frederic Weisbecker ,
    Cc: Jeff Law
    Cc: gcc@gcc.gnu.org
    Cc: David Daney
    Cc: Andrew Haley
    Cc: Richard Guenther
    Cc: stable@kernel.org

    Thomas Gleixner
     

03 Oct, 2009

1 commit

23 Aug, 2009

1 commit

13 Oct, 2008

1 commit

10 Sep, 2008

1 commit

  • 28f7e66fc   x86: prevent binutils from being "smart" and generating NOPLs for us ... Browse Code »

    binutils, contrary to documented behaviour, will generate long NOPs (a
    P6-or-higher instruction which is broken on at least some VIA chips,
    Virtual PC/Virtual Server, and some versions of Qemu) depending on the
    -mtune= option, which is not supposed to change architectural
    behaviour.

    Pass an explicit override to the assembler, in case ends up passing
    the -mtune= parameter to gas (gcc 4.3.0 does not appear to.)

    Signed-off-by: H. Peter Anvin

    H. Peter Anvin
     

26 Oct, 2007

1 commit