1. 14 10月, 2015 20 次提交
  2. 08 10月, 2015 4 次提交
  3. 07 10月, 2015 4 次提交
    • C
      word-at-a-time.h: support zero_bytemask() on alpha and tile · c753bf34
      Chris Metcalf 提交于
      Both alpha and tile needed implementations of zero_bytemask.
      
      The alpha version is untested.
      Signed-off-by: NChris Metcalf <cmetcalf@ezchip.com>
      c753bf34
    • C
      word-at-a-time.h: fix some Kbuild files · 19c22f3a
      Chris Metcalf 提交于
      arch/tile added word-at-a-time.h after the patch that added generic-y
      entries; the generic-y entry is now stale.
      
      arch/h8300 is newer than the generic-y patch for word-at-a-time.h,
      and needs a generic-y entry.
      
      arch/powerpc seems to have gotten a generic-y entry by mistake in
      the first patch; this change removes it.
      Signed-off-by: NChris Metcalf <cmetcalf@ezchip.com>
      19c22f3a
    • Y
      arm64: replace read_lock to rcu lock in call_break_hook · 62c6c61a
      Yang Shi 提交于
      BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:917
      in_atomic(): 0, irqs_disabled(): 128, pid: 342, name: perf
      1 lock held by perf/342:
       #0:  (break_hook_lock){+.+...}, at: [<ffffffc0000851ac>] call_break_hook+0x34/0xd0
      irq event stamp: 62224
      hardirqs last  enabled at (62223): [<ffffffc00010b7bc>] __call_rcu.constprop.59+0x104/0x270
      hardirqs last disabled at (62224): [<ffffffc0000fbe20>] vprintk_emit+0x68/0x640
      softirqs last  enabled at (0): [<ffffffc000097928>] copy_process.part.8+0x428/0x17f8
      softirqs last disabled at (0): [<          (null)>]           (null)
      CPU: 0 PID: 342 Comm: perf Not tainted 4.1.6-rt5 #4
      Hardware name: linux,dummy-virt (DT)
      Call trace:
      [<ffffffc000089968>] dump_backtrace+0x0/0x128
      [<ffffffc000089ab0>] show_stack+0x20/0x30
      [<ffffffc0007030d0>] dump_stack+0x7c/0xa0
      [<ffffffc0000c878c>] ___might_sleep+0x174/0x260
      [<ffffffc000708ac8>] __rt_spin_lock+0x28/0x40
      [<ffffffc000708db0>] rt_read_lock+0x60/0x80
      [<ffffffc0000851a8>] call_break_hook+0x30/0xd0
      [<ffffffc000085a70>] brk_handler+0x30/0x98
      [<ffffffc000082248>] do_debug_exception+0x50/0xb8
      Exception stack(0xffffffc00514fe30 to 0xffffffc00514ff50)
      fe20:                                     00000000 00000000 c1594680 0000007f
      fe40: ffffffff ffffffff 92063940 0000007f 0550dcd8 ffffffc0 00000000 00000000
      fe60: 0514fe70 ffffffc0 000be1f8 ffffffc0 0514feb0 ffffffc0 0008948c ffffffc0
      fe80: 00000004 00000000 0514fed0 ffffffc0 ffffffff ffffffff 9282a948 0000007f
      fea0: 00000000 00000000 9282b708 0000007f c1592820 0000007f 00083914 ffffffc0
      fec0: 00000000 00000000 00000010 00000000 00000064 00000000 00000001 00000000
      fee0: 005101e0 00000000 c1594680 0000007f c1594740 0000007f ffffffd8 ffffff80
      ff00: 00000000 00000000 00000000 00000000 c1594770 0000007f c1594770 0000007f
      ff20: 00665e10 00000000 7f7f7f7f 7f7f7f7f 01010101 01010101 00000000 00000000
      ff40: 928e4cc0 0000007f 91ff11e8 0000007f
      
      call_break_hook is called in atomic context (hard irq disabled), so replace
      the sleepable lock to rcu lock, replace relevant list operations to rcu
      version and call synchronize_rcu() in unregister_break_hook().
      
      And, replace write lock to spinlock in {un}register_break_hook.
      Signed-off-by: NYang Shi <yang.shi@linaro.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      62c6c61a
    • M
      arm64: Don't relocate non-existent initrd · 4ca3bc86
      Mark Rutland 提交于
      When booting a kernel without an initrd, the kernel reports that it
      moves -1 bytes worth, having gone through the motions with initrd_start
      equal to initrd_end:
      
          Moving initrd from [4080000000-407fffffff] to [9fff49000-9fff48fff]
      
      Prevent this by bailing out early when the initrd size is zero (i.e. we
      have no initrd), avoiding the confusing message and other associated
      work.
      
      Fixes: 1570f0d7 ("arm64: support initrd outside kernel linear map")
      Cc: Mark Salter <msalter@redhat.com>
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      4ca3bc86
  4. 06 10月, 2015 3 次提交
    • D
      x86/xen/p2m: hint at the last populated P2M entry · 98dd166e
      David Vrabel 提交于
      With commit 633d6f17 (x86/xen: prepare
      p2m list for memory hotplug) the P2M may be sized to accomdate a much
      larger amount of memory than the domain currently has.
      
      When saving a domain, the toolstack must scan all the P2M looking for
      populated pages.  This results in a performance regression due to the
      unnecessary scanning.
      
      Instead of reporting (via shared_info) the maximum possible size of
      the P2M, hint at the last PFN which might be populated.  This hint is
      increased as new leaves are added to the P2M (in the expectation that
      they will be used for populated entries).
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      Cc: <stable@vger.kernel.org> # 4.0+
      98dd166e
    • B
      MIPS: Define ioremap_uc · da11f98f
      Ben Hutchings 提交于
      All architectures must now define ioremap_uc(), but MIPS currently
      only has ioremap_nocache().
      
      Fixes: 4c73e892 ("arch/*/io.h: Add ioremap_uc() to all architectures")
      Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
      Cc: Luis R. Rodriguez <mcgrof@suse.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/11263/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      da11f98f
    • Y
      arm64: convert patch_lock to raw lock · abffa6f3
      Yang Shi 提交于
      When running kprobe test on arm64 rt kernel, it reports the below warning:
      
      root@qemu7:~# modprobe kprobe_example
      BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:917
      in_atomic(): 0, irqs_disabled(): 128, pid: 484, name: modprobe
      CPU: 0 PID: 484 Comm: modprobe Not tainted 4.1.6-rt5 #2
      Hardware name: linux,dummy-virt (DT)
      Call trace:
      [<ffffffc0000891b8>] dump_backtrace+0x0/0x128
      [<ffffffc000089300>] show_stack+0x20/0x30
      [<ffffffc00061dae8>] dump_stack+0x1c/0x28
      [<ffffffc0000bbad0>] ___might_sleep+0x120/0x198
      [<ffffffc0006223e8>] rt_spin_lock+0x28/0x40
      [<ffffffc000622b30>] __aarch64_insn_write+0x28/0x78
      [<ffffffc000622e48>] aarch64_insn_patch_text_nosync+0x18/0x48
      [<ffffffc000622ee8>] aarch64_insn_patch_text_cb+0x70/0xa0
      [<ffffffc000622f40>] aarch64_insn_patch_text_sync+0x28/0x48
      [<ffffffc0006236e0>] arch_arm_kprobe+0x38/0x48
      [<ffffffc00010e6f4>] arm_kprobe+0x34/0x50
      [<ffffffc000110374>] register_kprobe+0x4cc/0x5b8
      [<ffffffbffc002038>] kprobe_init+0x38/0x7c [kprobe_example]
      [<ffffffc000084240>] do_one_initcall+0x90/0x1b0
      [<ffffffc00061c498>] do_init_module+0x6c/0x1cc
      [<ffffffc0000fd0c0>] load_module+0x17f8/0x1db0
      [<ffffffc0000fd8cc>] SyS_finit_module+0xb4/0xc8
      
      Convert patch_lock to raw loc kto avoid this issue.
      
      Although the problem is found on rt kernel, the fix should be applicable to
      mainline kernel too.
      Acked-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NYang Shi <yang.shi@linaro.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      abffa6f3
  5. 05 10月, 2015 4 次提交
  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 1 次提交
    • 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