Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 13 5月, 2012 24 次提交
  3. 28 4月, 2012 4 次提交
    • W
      ARM: 7406/1: hotplug: copy the affinity mask when forcefully migrating IRQs · 5e7371de
      由 Will Deacon 提交于 
      When a CPU is hotplugged off, we migrate any IRQs currently affine to it
away and onto another online CPU by calling the irq_set_affinity
function of the relevant interrupt controller chip. This function
returns either IRQ_SET_MASK_OK or IRQ_SET_MASK_OK_NOCOPY, to indicate
whether irq_data.affinity was updated.

If we are forcefully migrating an interrupt (because the affinity mask
no longer identifies any online CPUs) then we should update the IRQ
affinity mask to reflect the new CPU set. Failure to do so can
potentially leave /proc/irq/n/smp_affinity identifying only offline
CPUs, which may confuse userspace IRQ balancing daemons.

This patch updates migrate_one_irq to copy the affinity mask when
the interrupt chip returns IRQ_SET_MASK_OK after forcefully changing the
affinity of an interrupt.

Cc: stable@vger.kernel.org
Reported-by: NLeif Lindholm <leif.lindholm@arm.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      5e7371de
    • W
      ARM: 7405/1: kexec: call platform_cpu_kill on the killer rather than the victim · 6fa99b7f
      由 Will Deacon 提交于 
      When performing a kexec on an SMP system, the secondary cores are stopped
by calling machine_shutdown(), which in turn issues IPIs to offline the
other CPUs. Unfortunately, this isn't enough to reboot the cores into
a new kernel (since they are just executing a cpu_relax loop somewhere
in memory) so we make use of platform_cpu_kill, part of the CPU hotplug
implementation, to place the cores somewhere safe. This function expects
to be called on the killing CPU for each core that it takes out.

This patch moves the platform_cpu_kill callback out of the IPI handler
and into smp_send_stop, therefore ensuring that it executes on the
killing CPU rather than on the victim, matching what the hotplug code
requires.

Cc: stable@vger.kernel.org
Reported-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      6fa99b7f
    • W
      ARM: 7403/1: tls: remove covert channel via TPIDRURW · 6a1c5312
      由 Will Deacon 提交于 
      TPIDRURW is a user read/write register forming part of the group of
thread registers in more recent versions of the ARM architecture (~v6+).

Currently, the kernel does not touch this register, which allows tasks
to communicate covertly by reading and writing to the register without
context-switching affecting its contents.

This patch clears TPIDRURW when TPIDRURO is updated via the set_tls
macro, which is called directly from __switch_to. Since the current
behaviour makes the register useless to userspace as far as thread
pointers are concerned, simply clearing the register (rather than saving
and restoring it) will not cause any problems to userspace.

Cc: stable@vger.kernel.org
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      6a1c5312
    • S
      ARM: 7401/1: mm: Fix section mismatches · 14904927
      由 Stephen Boyd 提交于 
      WARNING: vmlinux.o(.text+0x111b8): Section mismatch in reference
from the function arm_memory_present() to the function
.init.text:memory_present()
The function arm_memory_present() references
the function __init memory_present().
This is often because arm_memory_present lacks a __init
annotation or the annotation of memory_present is wrong.

WARNING: arch/arm/mm/built-in.o(.text+0x1edc): Section mismatch
in reference from the function alloc_init_pud() to the function
.init.text:alloc_init_section()
The function alloc_init_pud() references
the function __init alloc_init_section().
This is often because alloc_init_pud lacks a __init
annotation or the annotation of alloc_init_section is wrong.
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      14904927
  5. 27 4月, 2012 4 次提交
  7. 26 4月, 2012 1 次提交
  9. 25 4月, 2012 5 次提交
  11. 24 4月, 2012 1 次提交
  13. 23 4月, 2012 1 次提交
    • R
      ARM: OMAP: fix DMA vs memory ordering · 35453584
      由 Russell King 提交于 
      Using coherent DMA memory with the OMAP DMA engine results in
unpredictable behaviour due to memory ordering issues; as things stand,
there is no guarantee that data written to coherent DMA memory will be
visible to the DMA hardware.

This is because the OMAP dma_write() accessor contains no barriers,
necessary on ARMv6 and above.  The effect of this can be seen in comments
in the OMAP serial driver, which incorrectly talks about cache flushing
for the coherent DMA stuff.

Rather than adding barriers to the accessors, add it in the DMA support
code just before we enable DMA, and just after we disable DMA.  This
avoids having barriers for every DMA register access.
Acked-by: NTony Lindgren <tony@atomide.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      35453584