1. 13 10月, 2015 3 次提交
  2. 12 10月, 2015 3 次提交
  3. 10 10月, 2015 1 次提交
    • Y
      arm64: fix a migrating irq bug when hotplug cpu · 217d453d
      Yang Yingliang 提交于
      When cpu is disabled, all irqs will be migratged to another cpu.
      In some cases, a new affinity is different, the old affinity need
      to be updated and if irq_set_affinity's return value is IRQ_SET_MASK_OK_DONE,
      the old affinity can not be updated. Fix it by using irq_do_set_affinity.
      
      And migrating interrupts is a core code matter, so use the generic
      function irq_migrate_all_off_this_cpu() to migrate interrupts in
      kernel/irq/migration.c.
      
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
      Cc: Hanjun Guo <hanjun.guo@linaro.org>
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      217d453d
  4. 09 10月, 2015 6 次提交
  5. 07 10月, 2015 19 次提交
  6. 04 10月, 2015 1 次提交
  7. 03 10月, 2015 3 次提交
    • M
      MIPS: Octeon: Fix kernel panic on startup from memory corruption · 66803dd9
      Matt Bennett 提交于
      During development it was found that a number of builds would panic
      during the kernel init process, more specifically in 'delayed_fput()'.
      The panic showed the kernel trying to access a memory address of
      '0xb7fdc00' while traversing the 'delayed_fput_list' structure.
      Comparing this memory address to the value of the pointer used on
      builds that did not panic confirmed that the pointer on crashing
      builds must have been corrupted at some stage earlier in the init
      process.
      
      By traversing the list earlier and earlier in the code it was found
      that 'plat_mem_setup()' was responsible for corrupting the list.
      Specifically the line:
      
          memory = cvmx_bootmem_phy_alloc(mem_alloc_size,
      			__pa_symbol(&__init_end), -1,
      			0x100000,
      			CVMX_BOOTMEM_FLAG_NO_LOCKING);
      
      Which would eventually call:
      
          cvmx_bootmem_phy_set_size(new_ent_addr,
      		cvmx_bootmem_phy_get_size
      		(ent_addr) -
      		(desired_min_addr -
      			ent_addr));
      
      Where 'new_ent_addr'=0x4800000 (the address of 'delayed_fput_list')
      and the second argument (size)=0xb7fdc00 (the address causing the
      kernel panic). The job of this part of 'plat_mem_setup()' is to
      allocate chunks of memory for the kernel to use. At the start of
      each chunk of memory the size of the chunk is written, hence the
      value 0xb7fdc00 is written onto memory at 0x4800000, therefore the
      kernel panics when it goes back to access 'delayed_fput_list' later
      on in the initialisation process.
      
      On builds that were not crashing it was found that the compiler had
      placed 'delayed_fput_list' at 0x4800008, meaning it wasn't corrupted
      (but something else in memory was overwritten).
      
      As can be seen in the first function call above the code begins to
      allocate chunks of memory beginning from the symbol '__init_end'.
      The MIPS linker script (vmlinux.lds.S) however defines the .bss
      section to begin after '__init_end'. Therefore memory within the
      .bss section is allocated to the kernel to use (System.map shows
      'delayed_fput_list' and other kernel structures to be in .bss).
      
      To stop the kernel panic (and the .bss section being corrupted)
      memory should begin being allocated from the symbol '_end'.
      Signed-off-by: NMatt Bennett <matt.bennett@alliedtelesis.co.nz>
      Acked-by: NDavid Daney <david.daney@cavium.com>
      Cc: linux-mips@linux-mips.org
      Cc: aleksey.makarov@auriga.com
      Patchwork: https://patchwork.linux-mips.org/patch/11251/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      66803dd9
    • P
      MIPS: Fix R2300 FP context switch handling · 085c2f25
      Paul Burton 提交于
      Commit 1a3d5957 ("MIPS: Tidy up FPU context switching") removed FP
      context saving from the asm-written resume function in favour of reusing
      existing code to perform the same task. However it only removed the FP
      context saving code from the r4k_switch.S implementation of resume.
      Remove it from the r2300_switch.S implementation too in order to prevent
      attempting to save the FP context twice, which would likely lead to an
      exception from the second save because the FPU had already been disabled
      by the first save.
      
      This patch has only been build tested, using rbtx49xx_defconfig.
      
      Fixes: 1a3d5957 ("MIPS: Tidy up FPU context switching")
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: Maciej W. Rozycki <macro@linux-mips.org>
      Cc: linux-kernel@vger.kernel.org
      Cc: Manuel Lauss <manuel.lauss@gmail.com>
      Patchwork: https://patchwork.linux-mips.org/patch/11167/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      085c2f25
    • P
      MIPS: Fix octeon FP context switch handling · 0fa24340
      Paul Burton 提交于
      Commit 1a3d5957 ("MIPS: Tidy up FPU context switching") removed FP
      context saving from the asm-written resume function in favour of reusing
      existing code to perform the same task. However it only removed the FP
      context saving code from the r4k_switch.S implementation of resume.
      Octeon uses its own implementation in octeon_switch.S, so remove FP
      context saving there too in order to prevent attempting to save context
      twice. That formerly led to an exception from the second save as follows
      because the FPU had already been disabled by the first save:
      
          do_cpu invoked from kernel context![#1]:
          CPU: 0 PID: 2 Comm: kthreadd Not tainted 4.3.0-rc2-dirty #2
          task: 800000041f84a008 ti: 800000041f864000 task.ti: 800000041f864000
          $ 0   : 0000000000000000 0000000010008ce1 0000000000100000 ffffffffbfffffff
          $ 4   : 800000041f84a008 800000041f84ac08 800000041f84c000 0000000000000004
          $ 8   : 0000000000000001 0000000000000000 0000000000000000 0000000000000001
          $12   : 0000000010008ce3 0000000000119c60 0000000000000036 800000041f864000
          $16   : 800000041f84ac08 800000000792ce80 800000041f84a008 ffffffff81758b00
          $20   : 0000000000000000 ffffffff8175ae50 0000000000000000 ffffffff8176c740
          $24   : 0000000000000006 ffffffff81170300
          $28   : 800000041f864000 800000041f867d90 0000000000000000 ffffffff815f3fa0
          Hi    : 0000000000fa8257
          Lo    : ffffffffe15cfc00
          epc   : ffffffff8112821c resume+0x9c/0x200
          ra    : ffffffff815f3fa0 __schedule+0x3f0/0x7d8
          Status: 10008ce2        KX SX UX KERNEL EXL
          Cause : 1080002c (ExcCode 0b)
          PrId  : 000d0601 (Cavium Octeon+)
          Modules linked in:
          Process kthreadd (pid: 2, threadinfo=800000041f864000, task=800000041f84a008, tls=0000000000000000)
          Stack : ffffffff81604218 ffffffff815f7e08 800000041f84a008 ffffffff811681b0
                    800000041f84a008 ffffffff817e9878 0000000000000000 ffffffff81770000
                    ffffffff81768340 ffffffff81161398 0000000000000001 0000000000000000
                    0000000000000000 ffffffff815f4424 0000000000000000 ffffffff81161d68
                    ffffffff81161be8 0000000000000000 0000000000000000 0000000000000000
                    0000000000000000 0000000000000000 0000000000000000 ffffffff8111e16c
                    0000000000000000 0000000000000000 0000000000000000 0000000000000000
                    0000000000000000 0000000000000000 0000000000000000 0000000000000000
                    0000000000000000 0000000000000000 0000000000000000 0000000000000000
                    0000000000000000 0000000000000000 0000000000000000 0000000000000000
                    ...
          Call Trace:
          [<ffffffff8112821c>] resume+0x9c/0x200
          [<ffffffff815f3fa0>] __schedule+0x3f0/0x7d8
          [<ffffffff815f4424>] schedule+0x34/0x98
          [<ffffffff81161d68>] kthreadd+0x180/0x198
          [<ffffffff8111e16c>] ret_from_kernel_thread+0x14/0x1c
      
      Tested using cavium_octeon_defconfig on an EdgeRouter Lite.
      
      Fixes: 1a3d5957 ("MIPS: Tidy up FPU context switching")
      Reported-by: NAaro Koskinen <aaro.koskinen@nokia.com>
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: Aleksey Makarov <aleksey.makarov@auriga.com>
      Cc: linux-kernel@vger.kernel.org
      Cc: Chandrakala Chavva <cchavva@caviumnetworks.com>
      Cc: David Daney <david.daney@cavium.com>
      Cc: Leonid Rosenboim <lrosenboim@caviumnetworks.com>
      Patchwork: https://patchwork.linux-mips.org/patch/11166/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      0fa24340
  8. 02 10月, 2015 4 次提交
    • L
      arm64: ftrace: fix function_graph tracer panic · ee556d00
      Li Bin 提交于
      When function graph tracer is enabled, the following operation
      will trigger panic:
      
      mount -t debugfs nodev /sys/kernel
      echo next_tgid > /sys/kernel/tracing/set_ftrace_filter
      echo function_graph > /sys/kernel/tracing/current_tracer
      ls /proc/
      
      ------------[ cut here ]------------
      [  198.501417] Unable to handle kernel paging request at virtual address cb88537fdc8ba316
      [  198.506126] pgd = ffffffc008f79000
      [  198.509363] [cb88537fdc8ba316] *pgd=00000000488c6003, *pud=00000000488c6003, *pmd=0000000000000000
      [  198.517726] Internal error: Oops: 94000005 [#1] SMP
      [  198.518798] Modules linked in:
      [  198.520582] CPU: 1 PID: 1388 Comm: ls Tainted: G
      [  198.521800] Hardware name: linux,dummy-virt (DT)
      [  198.522852] task: ffffffc0fa9e8000 ti: ffffffc0f9ab0000 task.ti: ffffffc0f9ab0000
      [  198.524306] PC is at next_tgid+0x30/0x100
      [  198.525205] LR is at return_to_handler+0x0/0x20
      [  198.526090] pc : [<ffffffc0002a1070>] lr : [<ffffffc0000907c0>] pstate: 60000145
      [  198.527392] sp : ffffffc0f9ab3d40
      [  198.528084] x29: ffffffc0f9ab3d40 x28: ffffffc0f9ab0000
      [  198.529406] x27: ffffffc000d6a000 x26: ffffffc000b786e8
      [  198.530659] x25: ffffffc0002a1900 x24: ffffffc0faf16c00
      [  198.531942] x23: ffffffc0f9ab3ea0 x22: 0000000000000002
      [  198.533202] x21: ffffffc000d85050 x20: 0000000000000002
      [  198.534446] x19: 0000000000000002 x18: 0000000000000000
      [  198.535719] x17: 000000000049fa08 x16: ffffffc000242efc
      [  198.537030] x15: 0000007fa472b54c x14: ffffffffff000000
      [  198.538347] x13: ffffffc0fada84a0 x12: 0000000000000001
      [  198.539634] x11: ffffffc0f9ab3d70 x10: ffffffc0f9ab3d70
      [  198.540915] x9 : ffffffc0000907c0 x8 : ffffffc0f9ab3d40
      [  198.542215] x7 : 0000002e330f08f0 x6 : 0000000000000015
      [  198.543508] x5 : 0000000000000f08 x4 : ffffffc0f9835ec0
      [  198.544792] x3 : cb88537fdc8ba316 x2 : cb88537fdc8ba306
      [  198.546108] x1 : 0000000000000002 x0 : ffffffc000d85050
      [  198.547432]
      [  198.547920] Process ls (pid: 1388, stack limit = 0xffffffc0f9ab0020)
      [  198.549170] Stack: (0xffffffc0f9ab3d40 to 0xffffffc0f9ab4000)
      [  198.582568] Call trace:
      [  198.583313] [<ffffffc0002a1070>] next_tgid+0x30/0x100
      [  198.584359] [<ffffffc0000907bc>] ftrace_graph_caller+0x6c/0x70
      [  198.585503] [<ffffffc0000907bc>] ftrace_graph_caller+0x6c/0x70
      [  198.586574] [<ffffffc0000907bc>] ftrace_graph_caller+0x6c/0x70
      [  198.587660] [<ffffffc0000907bc>] ftrace_graph_caller+0x6c/0x70
      [  198.588896] Code: aa0003f5 2a0103f4 b4000102 91004043 (885f7c60)
      [  198.591092] ---[ end trace 6a346f8f20949ac8 ]---
      
      This is because when using function graph tracer, if the traced
      function return value is in multi regs ([x0-x7]), return_to_handler
      may corrupt them. So in return_to_handler, the parameter regs should
      be protected properly.
      
      Cc: <stable@vger.kernel.org> # 3.18+
      Signed-off-by: NLi Bin <huawei.libin@huawei.com>
      Acked-by: NAKASHI Takahiro <takahiro.akashi@linaro.org>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      ee556d00
    • R
      MIPS: BPF: Fix load delay slots. · 0c5d1878
      Ralf Baechle 提交于
      The entire bpf_jit_asm.S is written in noreorder mode because "we know
      better" according to a comment.  This also prevented the assembler from
      throwing in the required NOPs for MIPS I processors which have no
      load-use interlock, thus the load's consumer might end up using the
      old value of the register from prior to the load.
      
      Fixed by putting the assembler in reorder mode for just the affected
      load instructions.  This is not enough for gas to actually try to be
      clever by looking at the next instruction and inserting a nop only
      when needed but as the comment said "we know better", so getting gas
      to unconditionally emit a NOP is just right in this case and prevents
      adding further ifdefery.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      0c5d1878
    • B
      x86/headers/uapi: Fix __BITS_PER_LONG value for x32 builds · f4b4aae1
      Ben Hutchings 提交于
      On x32, gcc predefines __x86_64__ but long is only 32-bit.  Use
      __ILP32__ to distinguish x32.
      
      Fixes this compiler error in perf:
      
      	tools/include/asm-generic/bitops/__ffs.h: In function '__ffs':
      	tools/include/asm-generic/bitops/__ffs.h:19:8: error: right shift count >= width of type [-Werror=shift-count-overflow]
      	  word >>= 32;
      	       ^
      
      This isn't sufficient to build perf for x32, though.
      Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Link: http://lkml.kernel.org/r/1443660043.2730.15.camel@decadent.org.ukSigned-off-by: NIngo Molnar <mingo@kernel.org>
      f4b4aae1
    • S
      x86/mm: Set NX on gap between __ex_table and rodata · ab76f7b4
      Stephen Smalley 提交于
      Unused space between the end of __ex_table and the start of
      rodata can be left W+x in the kernel page tables.  Extend the
      setting of the NX bit to cover this gap by starting from
      text_end rather than rodata_start.
      
        Before:
        ---[ High Kernel Mapping ]---
        0xffffffff80000000-0xffffffff81000000          16M                               pmd
        0xffffffff81000000-0xffffffff81600000           6M     ro         PSE     GLB x  pmd
        0xffffffff81600000-0xffffffff81754000        1360K     ro                 GLB x  pte
        0xffffffff81754000-0xffffffff81800000         688K     RW                 GLB x  pte
        0xffffffff81800000-0xffffffff81a00000           2M     ro         PSE     GLB NX pmd
        0xffffffff81a00000-0xffffffff81b3b000        1260K     ro                 GLB NX pte
        0xffffffff81b3b000-0xffffffff82000000        4884K     RW                 GLB NX pte
        0xffffffff82000000-0xffffffff82200000           2M     RW         PSE     GLB NX pmd
        0xffffffff82200000-0xffffffffa0000000         478M                               pmd
      
        After:
        ---[ High Kernel Mapping ]---
        0xffffffff80000000-0xffffffff81000000          16M                               pmd
        0xffffffff81000000-0xffffffff81600000           6M     ro         PSE     GLB x  pmd
        0xffffffff81600000-0xffffffff81754000        1360K     ro                 GLB x  pte
        0xffffffff81754000-0xffffffff81800000         688K     RW                 GLB NX pte
        0xffffffff81800000-0xffffffff81a00000           2M     ro         PSE     GLB NX pmd
        0xffffffff81a00000-0xffffffff81b3b000        1260K     ro                 GLB NX pte
        0xffffffff81b3b000-0xffffffff82000000        4884K     RW                 GLB NX pte
        0xffffffff82000000-0xffffffff82200000           2M     RW         PSE     GLB NX pmd
        0xffffffff82200000-0xffffffffa0000000         478M                               pmd
      Signed-off-by: NStephen Smalley <sds@tycho.nsa.gov>
      Acked-by: NKees Cook <keescook@chromium.org>
      Cc: <stable@vger.kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Link: http://lkml.kernel.org/r/1443704662-3138-1-git-send-email-sds@tycho.nsa.govSigned-off-by: NIngo Molnar <mingo@kernel.org>
      ab76f7b4