1. 18 2月, 2013 9 次提交
  2. 31 1月, 2013 7 次提交
    • A
      MIPS: Function tracer: Fix broken function tracing · 58b69401
      Al Cooper 提交于
      Function tracing is currently broken for all 32 bit MIPS platforms.
      When tracing is enabled, the kernel immediately hangs on boot.
      This is a result of commit b732d439
      that changes the kernel/trace/Kconfig file so that is no longer
      forces FRAME_POINTER when FUNCTION_TRACING is enabled.
      
      MIPS frame pointers are generally considered to be useless because
      they cannot be used to unwind the stack. Unfortunately the MIPS
      function tracing code has bugs that are masked by the use of frame
      pointers. This commit fixes the bugs so that MIPS frame pointers
      don't need to be enabled.
      
      The bugs are a result of the odd calling sequence used to call the trace
      routine. This calling sequence is inserted into every traceable function
      when the tracing CONFIG option is enabled. This sequence is generated
      for 32bit MIPS platforms by the compiler via the "-pg" flag.
      
      Part of the sequence is "addiu sp,sp,-8" in the delay slot after every
      call to the trace routine "_mcount" (some legacy thing where 2 arguments
      used to be pushed on the stack). The _mcount routine is expected to
      adjust the sp by +8 before returning.  So when not disabled, the original
      jalr and addiu will be there, so _mcount has to adjust sp.
      
      The problem is that when tracing is disabled for a function, the
      "jalr _mcount" instruction is replaced with a nop, but the
      "addiu sp,sp,-8" is still executed and the stack pointer is left
      trashed. When frame pointers are enabled the problem is masked
      because any access to the stack is done through the frame
      pointer and the stack pointer is restored from the frame pointer when
      the function returns.
      
      This patch writes two nops starting at the address of the "jalr _mcount"
      instruction whenever tracing is disabled. This means that the
      "addiu sp,sp.-8" will be converted to a nop along with the "jalr".  When
      disabled, there will be two nops.
      
      This is SMP safe because the first time this happens is during
      ftrace_init() which is before any other processor has been started.
      Subsequent calls to enable/disable tracing when other CPUs ARE running
      will still be safe because the enable will only change the first nop
      to a "jalr" and the disable, while writing 2 nops, will only be changing
      the "jalr". This patch also stops using stop_machine() to call the
      tracer enable/disable routines and calls them directly because the
      routines are SMP safe.
      
      When the kernel first boots we have to be able to handle the gcc
      generated jalr, addui sequence until ftrace_init gets a chance to run
      and change the sequence. At this point mcount just adjusts the stack
      and returns. When ftrace_init runs, we convert the jalr/addui to nops.
      Then whenever tracing is enabled we convert the first nop to a "jalr
      mcount+8". The mcount+8 entry point skips the stack adjust.
      
      [ralf@linux-mips.org: Folded in  Steven Rostedt's build fix.]
      Signed-off-by: NAl Cooper <alcooperx@gmail.com>
      Cc: rostedt@goodmis.org
      Cc: ddaney.cavm@gmail.com
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/4806/
      Patchwork: https://patchwork.linux-mips.org/patch/4841/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      58b69401
    • S
      mips: Move __virt_addr_valid() to a place for MIPS 64 · 196897a2
      Steven Rostedt 提交于
      Commit d3ce8843 "MIPS: Fix modpost error in modules attepting to use
      virt_addr_valid()" moved __virt_addr_valid() from a macro in a header
      file to a function in ioremap.c. But ioremap.c is only compiled for MIPS
      32, and not for MIPS 64.
      
      When compiling for my yeeloong2, which supposedly supports hibernation,
      which compiles kernel/power/snapshot.c which calls virt_addr_valid(), I
      got this error:
      
        LD      init/built-in.o
      kernel/built-in.o: In function `memory_bm_free':
      snapshot.c:(.text+0x4c9c4): undefined reference to `__virt_addr_valid'
      snapshot.c:(.text+0x4ca58): undefined reference to `__virt_addr_valid'
      kernel/built-in.o: In function `snapshot_write_next':
      (.text+0x4e44c): undefined reference to `__virt_addr_valid'
      kernel/built-in.o: In function `snapshot_write_next':
      (.text+0x4e890): undefined reference to `__virt_addr_valid'
      make[1]: *** [vmlinux] Error 1
      make: *** [sub-make] Error 2
      
      I suspect that __virt_addr_valid() is fine for mips 64. I moved it to
      mmap.c such that it gets compiled for mips 64 and 32.
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/4842/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      196897a2
    • J
      MIPS: Netlogic: Fix UP compilation on XLR · 26f5ae86
      Jayachandran C 提交于
      The commit 2a37b1ae "MIPS: Netlogic: Move from u32 cpumask to cpumask_t"
      breaks uniprocessor compilation on XLR with:
      
      arch/mips/netlogic/xlr/setup.c: In function 'prom_init':
      arch/mips/netlogic/xlr/setup.c:196:6: error: unused variable 'i'
      
      Fix by defining 'i' only when CONFIG_SMP is defined.
      Signed-off-by: NJayachandran C <jchandra@broadcom.com>
      Patchwork: http://patchwork.linux-mips.org/patch/4760/Signed-off-by: NJohn Crispin <blogic@openwrt.org>
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      26f5ae86
    • G
      MIPS: AR71xx: Fix AR71XX_PCI_MEM_SIZE · fe950df7
      Gabor Juhos 提交于
      The base address of the PCI memory is 0x10000000 and the base address of the
      PCI configuration space is 0x17000000 on the AR71xx SoCs.
      
      The AR71XX_PCI_MEM_SIZE is defined as 0x08000000 which is wrong because that
      overlaps with the configuration space.  This patch fixes the value of the
      AR71XX_PCI_MEM_SIZE constant, in order to avoid this resource conflicts.
      Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
      Patchwork: http://patchwork.linux-mips.org/patch/4873/Signed-off-by: NJohn Crispin <blogic@openwrt.org>
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      fe950df7
    • G
      MIPS: AR724x: Fix AR724X_PCI_MEM_SIZE · 4c960910
      Gabor Juhos 提交于
      The base address of the PCI memory is
      0x10000000 and the base address of the
      PCI configuration space is 0x14000000
      on the AR724x SoCs.
      
      The AR724X_PCI_MEM_SIZE is defined as
      0x08000000 which is wrong because that
      overlaps  with the configuration space.
      
      The patch fixes the value of the
      AR724X_PCI_MEM_SIZE constant, in order
      to avoid this resource conflicts.
      Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
      Patchwork: http://patchwork.linux-mips.org/patch/4872/Signed-off-by: NJohn Crispin <blogic@openwrt.org>
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      4c960910
    • J
      MIPS: Lantiq: Fix cp0_perfcount_irq mapping · 79d61a04
      John Crispin 提交于
      The introduction of the OF support broke the cp0_perfcount_irq mapping. This
      resulted in oprofile not working anymore.
      
      Offending commit is :
      
      commit 3645da02
      Author: John Crispin <blogic@openwrt.org>
      Date:   Tue Apr 17 10:18:32 2012 +0200
      
      OF: MIPS: lantiq: implement irq_domain support
      Signed-off-by: NConor O'Gorman <i@conorogorman.net>
      Signed-off-by: NJohn Crispin <blogic@openwrt.org>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/4875/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      79d61a04
    • M
      efi: Make 'efi_enabled' a function to query EFI facilities · 83e68189
      Matt Fleming 提交于
      Originally 'efi_enabled' indicated whether a kernel was booted from
      EFI firmware. Over time its semantics have changed, and it now
      indicates whether or not we are booted on an EFI machine with
      bit-native firmware, e.g. 64-bit kernel with 64-bit firmware.
      
      The immediate motivation for this patch is the bug report at,
      
          https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557
      
      which details how running a platform driver on an EFI machine that is
      designed to run under BIOS can cause the machine to become
      bricked. Also, the following report,
      
          https://bugzilla.kernel.org/show_bug.cgi?id=47121
      
      details how running said driver can also cause Machine Check
      Exceptions. Drivers need a new means of detecting whether they're
      running on an EFI machine, as sadly the expression,
      
          if (!efi_enabled)
      
      hasn't been a sufficient condition for quite some time.
      
      Users actually want to query 'efi_enabled' for different reasons -
      what they really want access to is the list of available EFI
      facilities.
      
      For instance, the x86 reboot code needs to know whether it can invoke
      the ResetSystem() function provided by the EFI runtime services, while
      the ACPI OSL code wants to know whether the EFI config tables were
      mapped successfully. There are also checks in some of the platform
      driver code to simply see if they're running on an EFI machine (which
      would make it a bad idea to do BIOS-y things).
      
      This patch is a prereq for the samsung-laptop fix patch.
      
      Cc: David Airlie <airlied@linux.ie>
      Cc: Corentin Chary <corentincj@iksaif.net>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Dave Jiang <dave.jiang@intel.com>
      Cc: Olof Johansson <olof@lixom.net>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Colin Ian King <colin.king@canonical.com>
      Cc: Steve Langasek <steve.langasek@canonical.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      83e68189
  3. 30 1月, 2013 1 次提交
  4. 29 1月, 2013 6 次提交
    • T
      powerpc: Max next_tb to prevent from replaying timer interrupt · 689dfa89
      Tiejun Chen 提交于
      With lazy interrupt, we always call __check_irq_replaysome with
      decrementers_next_tb to check if we need to replay timer interrupt.
      So in hotplug case we also need to set decrementers_next_tb as MAX
      to make sure __check_irq_replay don't replay timer interrupt
      when return as we expect, otherwise we'll trap here infinitely.
      Signed-off-by: NTiejun Chen <tiejun.chen@windriver.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      689dfa89
    • C
      powerpc: kernel/kgdb.c: Fix memory leakage · fefd9e6f
      Cong Ding 提交于
      the variable backup_current_thread_info isn't freed before existing the
      function.
      Signed-off-by: NCong Ding <dinggnu@gmail.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      fefd9e6f
    • T
      powerpc/book3e: Disable interrupt after preempt_schedule_irq · 572177d7
      Tiejun Chen 提交于
      In preempt case current arch_local_irq_restore() from
      preempt_schedule_irq() may enable hard interrupt but we really
      should disable interrupts when we return from the interrupt,
      and so that we don't get interrupted after loading SRR0/1.
      Signed-off-by: NTiejun Chen <tiejun.chen@windriver.com>
      CC: <stable@vger.kernel.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      572177d7
    • C
      powerpc/oprofile: Fix error in oprofile power7_marked_instr_event() function · 46ed7a76
      Carl E. Love 提交于
      The calculation for the left shift of the mask OPROFILE_PM_PMCSEL_MSK has an
      error.  The calculation is should be to shift left by (max_cntrs - cntr) times
      the width of the pmsel field width.  However, the #define OPROFILE_MAX_PMC_NUM
      was used instead of OPROFILE_PMSEL_FIELD_WIDTH.  This patch fixes the
      calculation.
      Signed-off-by: NCarl Love <cel@us.ibm.com>
      Acked-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      46ed7a76
    • S
      powerpc/pasemi: Fix crash on reboot · 72640d88
      Steven Rostedt 提交于
      commit f96972f2 "kernel/sys.c: call disable_nonboot_cpus() in
      kernel_restart()"
      
      added a call to disable_nonboot_cpus() on kernel_restart(), which tries
      to shutdown all the CPUs except the first one. The issue with the PA
      Semi, is that it does not support CPU hotplug.
      
      When the call is made to __cpu_down(), it calls the notifiers
      CPU_DOWN_PREPARE, and then tries to take the CPU down.
      
      One of the notifiers to the CPU hotplug code, is the cpufreq. The
      DOWN_PREPARE will call __cpufreq_remove_dev() which calls
      cpufreq_driver->exit. The PA Semi exit handler unmaps regions of I/O
      that is used by an interrupt that goes off constantly
      (system_reset_common, but it goes off during normal system operations
      too). I'm not sure exactly what this interrupt does.
      
      Running a simple function trace, you can see it goes off quite a bit:
      
      # tracer: function
      #
      #           TASK-PID    CPU#    TIMESTAMP  FUNCTION
      #              | |       |          |         |
                <idle>-0     [001]  1558.859363: .pasemi_system_reset_exception <-.system_reset_exception
                <idle>-0     [000]  1558.860112: .pasemi_system_reset_exception <-.system_reset_exception
                <idle>-0     [000]  1558.861109: .pasemi_system_reset_exception <-.system_reset_exception
                <idle>-0     [001]  1558.861361: .pasemi_system_reset_exception <-.system_reset_exception
                <idle>-0     [000]  1558.861437: .pasemi_system_reset_exception <-.system_reset_exception
      
      When the region is unmapped, the system crashes with:
      
      Disabling non-boot CPUs ...
      Error taking CPU1 down: -38
      Unable to handle kernel paging request for data at address 0xd0000800903a0100
      Faulting instruction address: 0xc000000000055fcc
      Oops: Kernel access of bad area, sig: 11 [#1]
      PREEMPT SMP NR_CPUS=64 NUMA PA Semi PWRficient
      Modules linked in: shpchp
      NIP: c000000000055fcc LR: c000000000055fb4 CTR: c0000000000df1fc
      REGS: c0000000012175d0 TRAP: 0300   Not tainted  (3.8.0-rc4-test-dirty)
      MSR: 9000000000009032 <SF,HV,EE,ME,IR,DR,RI>  CR: 24000088  XER: 00000000
      SOFTE: 0
      DAR: d0000800903a0100, DSISR: 42000000
      TASK = c0000000010e9008[0] 'swapper/0' THREAD: c000000001214000 CPU: 0
      GPR00: d0000800903a0000 c000000001217850 c0000000012167e0 0000000000000000
      GPR04: 0000000000000000 0000000000000724 0000000000000724 0000000000000000
      GPR08: 0000000000000000 0000000000000000 0000000000000001 0000000000a70000
      GPR12: 0000000024000080 c00000000fff0000 ffffffffffffffff 000000003ffffae0
      GPR16: ffffffffffffffff 0000000000a21198 0000000000000060 0000000000000000
      GPR20: 00000000008fdd35 0000000000a21258 000000003ffffaf0 0000000000000417
      GPR24: 0000000000a226d0 c000000000000000 0000000000000000 0000000000000000
      GPR28: c00000000138b358 0000000000000000 c000000001144818 d0000800903a0100
      NIP [c000000000055fcc] .set_astate+0x5c/0xa4
      LR [c000000000055fb4] .set_astate+0x44/0xa4
      Call Trace:
      [c000000001217850] [c000000000055fb4] .set_astate+0x44/0xa4 (unreliable)
      [c0000000012178f0] [c00000000005647c] .restore_astate+0x2c/0x34
      [c000000001217980] [c000000000054668] .pasemi_system_reset_exception+0x6c/0x88
      [c000000001217a00] [c000000000019ef0] .system_reset_exception+0x48/0x84
      [c000000001217a80] [c000000000001e40] system_reset_common+0x140/0x180
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      72640d88
    • L
      powerpc: Fix MAX_STACK_TRACE_ENTRIES too low warning for ppc32 · 41d82bdb
      Li Zhong 提交于
      This patch fixes MAX_STACK_TRACE_ENTRIES too low warning for ppc32,
      which is similar to commit 12660b17.
      Reported-by: NChristian Kujau <lists@nerdbynature.de>
      Signed-off-by: NLi Zhong <zhong@linux.vnet.ibm.com>
      Tested-by: NChristian Kujau <lists@nerdbynature.de>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      41d82bdb
  5. 28 1月, 2013 6 次提交
  6. 25 1月, 2013 4 次提交
    • M
      x86, efi: Set runtime_version to the EFI spec revision · 712ba9e9
      Matt Fleming 提交于
      efi.runtime_version is erroneously being set to the value of the
      vendor's firmware revision instead of that of the implemented EFI
      specification. We can't deduce which EFI functions are available based
      on the revision of the vendor's firmware since the version scheme is
      likely to be unique to each vendor.
      
      What we really need to know is the revision of the implemented EFI
      specification, which is available in the EFI System Table header.
      
      Cc: Seiji Aguchi <seiji.aguchi@hds.com>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: stable@vger.kernel.org # 3.7.x
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      712ba9e9
    • J
      x86, efi: fix 32-bit warnings in setup_efi_pci() · bc754790
      Jan Beulich 提交于
      Fix four similar build warnings on 32-bit (casts between different
      size pointers and integers).
      Signed-off-by: NJan Beulich <jbeulich@suse.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Stefan Hasko <hasko.stevo@gmail.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      bc754790
    • A
      x86/msr: Add capabilities check · c903f045
      Alan Cox 提交于
      At the moment the MSR driver only relies upon file system
      checks. This means that anything as root with any capability set
      can write to MSRs. Historically that wasn't very interesting but
      on modern processors the MSRs are such that writing to them
      provides several ways to execute arbitary code in kernel space.
      Sample code and documentation on doing this is circulating and
      MSR attacks are used on Windows 64bit rootkits already.
      
      In the Linux case you still need to be able to open the device
      file so the impact is fairly limited and reduces the security of
      some capability and security model based systems down towards
      that of a generic "root owns the box" setup.
      
      Therefore they should require CAP_SYS_RAWIO to prevent an
      elevation of capabilities. The impact of this is fairly minimal
      on most setups because they don't have heavy use of
      capabilities. Those using SELinux, SMACK or AppArmor rules might
      want to consider if their rulesets on the MSR driver could be
      tighter.
      Signed-off-by: NAlan Cox <alan@linux.intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Horses <stable@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      c903f045
    • M
      x86/dma-debug: Bump PREALLOC_DMA_DEBUG_ENTRIES · 73b664ce
      Maarten Lankhorst 提交于
      I ran out of free entries when I had CONFIG_DMA_API_DEBUG
      enabled. Some other archs seem to default to 65536, so increase
      this limit for x86 too.
      Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Link: http://lkml.kernel.org/r/50A612AA.7040206@canonical.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      ----
      73b664ce
  7. 24 1月, 2013 6 次提交
  8. 23 1月, 2013 1 次提交