01 Nov, 2011

1 commit


01 Jul, 2011

1 commit

  • The nmi parameter indicated if we could do wakeups from the current
    context, if not, we would set some state and self-IPI and let the
    resulting interrupt do the wakeup.

    For the various event classes:

    - hardware: nmi=0; PMI is in fact an NMI or we run irq_work_run from
    the PMI-tail (ARM etc.)
    - tracepoint: nmi=0; since tracepoint could be from NMI context.
    - software: nmi=[0,1]; some, like the schedule thing cannot
    perform wakeups, and hence need 0.

    As one can see, there is very little nmi=1 usage, and the down-side of
    not using it is that on some platforms some software events can have a
    jiffy delay in wakeup (when arch_irq_work_raise isn't implemented).

    The up-side however is that we can remove the nmi parameter and save a
    bunch of conditionals in fast paths.

    Signed-off-by: Peter Zijlstra
    Cc: Michael Cree
    Cc: Will Deacon
    Cc: Deng-Cheng Zhu
    Cc: Anton Blanchard
    Cc: Eric B Munson
    Cc: Heiko Carstens
    Cc: Paul Mundt
    Cc: David S. Miller
    Cc: Frederic Weisbecker
    Cc: Jason Wessel
    Cc: Don Zickus
    Link: http://lkml.kernel.org/n/tip-agjev8eu666tvknpb3iaj0fg@git.kernel.org
    Signed-off-by: Ingo Molnar

    Peter Zijlstra
     

30 Oct, 2010

1 commit

  • Software events are required as part of the measurable stuff by the
    Linux performance counter subsystem. Here is the list of events added by
    this patch:
    PERF_COUNT_SW_PAGE_FAULTS
    PERF_COUNT_SW_PAGE_FAULTS_MIN
    PERF_COUNT_SW_PAGE_FAULTS_MAJ
    PERF_COUNT_SW_ALIGNMENT_FAULTS
    PERF_COUNT_SW_EMULATION_FAULTS

    Signed-off-by: Deng-Cheng Zhu
    To: linux-mips@linux-mips.org
    Cc: a.p.zijlstra@chello.nl
    Cc: paulus@samba.org
    Cc: mingo@elte.hu
    Cc: acme@redhat.com
    Cc: jamie.iles@picochip.com
    Acked-by: David Daney
    Reviewed-by: Matt Fleming
    Patchwork: https://patchwork.linux-mips.org/patch/1686/
    Signed-off-by: Ralf Baechle

    Deng-Cheng Zhu
     

18 Oct, 2010

1 commit

  • Put the original syscall number into ->regs[0] when we leave syscall
    with error. Use it in restart logics. Everything else will have
    it 0 since we pass through SAVE_SOME on all the ways in. Note that
    in places like bad_stack and inllegal_syscall we leave it 0 - it's not
    restartable.

    Signed-off-by: Al Viro
    Cc: linux-kernel@vger.kernel.org
    Cc: linux-arch@vger.kernel.org
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/1698/
    Signed-off-by: Ralf Baechle

    Al Viro
     

17 Dec, 2009

1 commit


14 May, 2009

1 commit

  • When init is started it is SIGNAL_UNKILLABLE. If it were to get an
    address error, we would try to send it SIGBUS, but it would be ignored
    and the faulting instruction restarted. This results in an endless
    loop.

    We need to use force_sig() instead so it will actually die and give us
    some useful information.

    Reported-by: Florian Fainelli
    Signed-off-by: David Daney
    Signed-off-by: Ralf Baechle

    David Daney
     

30 Oct, 2008

1 commit

  • Arguably using the address error handler has always been ugly. But with
    processors that handle unaligned loads and stores in hardware the
    current mechanism ceases to work so switch it to a BREAK instruction and
    allocate break code 514 to the FPU emulator.

    Yoichi Yuasa provided a build fix for CONFIG_BUG=n.

    Signed-off-by: Ralf Baechle
    Signed-off-by: Yoichi Yuasa

    Ralf Baechle
     

28 Oct, 2008

1 commit


12 Oct, 2007

1 commit


01 Aug, 2007

2 commits


11 Jul, 2007

1 commit

  • Currently a number of unaligned instructions is counted but not used.
    Add /debug/mips/unaligned_instructions file to show the value.

    And add /debug/mips/unaligned_action to control behavior upon an
    unaligned access. Possible actions are:

    0: silently fixup the unaligned access.
    1: send SIGBUS.
    2: dump registers, process name, etc. and fixup.

    Signed-off-by: Atsushi Nemoto
    Signed-off-by: Ralf Baechle

    Atsushi Nemoto
     

22 May, 2007

1 commit

  • First thing mm.h does is including sched.h solely for can_do_mlock() inline
    function which has "current" dereference inside. By dealing with can_do_mlock()
    mm.h can be detached from sched.h which is good. See below, why.

    This patch
    a) removes unconditional inclusion of sched.h from mm.h
    b) makes can_do_mlock() normal function in mm/mlock.c
    c) exports can_do_mlock() to not break compilation
    d) adds sched.h inclusions back to files that were getting it indirectly.
    e) adds less bloated headers to some files (asm/signal.h, jiffies.h) that were
    getting them indirectly

    Net result is:
    a) mm.h users would get less code to open, read, preprocess, parse, ... if
    they don't need sched.h
    b) sched.h stops being dependency for significant number of files:
    on x86_64 allmodconfig touching sched.h results in recompile of 4083 files,
    after patch it's only 3744 (-8.3%).

    Cross-compile tested on

    all arm defconfigs, all mips defconfigs, all powerpc defconfigs,
    alpha alpha-up
    arm
    i386 i386-up i386-defconfig i386-allnoconfig
    ia64 ia64-up
    m68k
    mips
    parisc parisc-up
    powerpc powerpc-up
    s390 s390-up
    sparc sparc-up
    sparc64 sparc64-up
    um-x86_64
    x86_64 x86_64-up x86_64-defconfig x86_64-allnoconfig

    as well as my two usual configs.

    Signed-off-by: Alexey Dobriyan
    Signed-off-by: Linus Torvalds

    Alexey Dobriyan
     

09 May, 2007

1 commit


27 Feb, 2007

1 commit


01 Jul, 2006

1 commit


30 Oct, 2005

1 commit


05 Sep, 2005

1 commit


17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds