Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 21 8月, 2013 4 次提交
  3. 16 8月, 2013 1 次提交
    • L
      Fix TLB gather virtual address range invalidation corner cases · 2b047252
      由 Linus Torvalds 提交于 
      Ben Tebulin reported:

 "Since v3.7.2 on two independent machines a very specific Git
  repository fails in 9/10 cases on git-fsck due to an SHA1/memory
  failures.  This only occurs on a very specific repository and can be
  reproduced stably on two independent laptops.  Git mailing list ran
  out of ideas and for me this looks like some very exotic kernel issue"

and bisected the failure to the backport of commit 53a59fc6 ("mm:
limit mmu_gather batching to fix soft lockups on !CONFIG_PREEMPT").

That commit itself is not actually buggy, but what it does is to make it
much more likely to hit the partial TLB invalidation case, since it
introduces a new case in tlb_next_batch() that previously only ever
happened when running out of memory.

The real bug is that the TLB gather virtual memory range setup is subtly
buggered.  It was introduced in commit 597e1c35 ("mm/mmu_gather:
enable tlb flush range in generic mmu_gather"), and the range handling
was already fixed at least once in commit e6c495a9 ("mm: fix the TLB
range flushed when __tlb_remove_page() runs out of slots"), but that fix
was not complete.

The problem with the TLB gather virtual address range is that it isn't
set up by the initial tlb_gather_mmu() initialization (which didn't get
the TLB range information), but it is set up ad-hoc later by the
functions that actually flush the TLB.  And so any such case that forgot
to update the TLB range entries would potentially miss TLB invalidates.

Rather than try to figure out exactly which particular ad-hoc range
setup was missing (I personally suspect it's the hugetlb case in
zap_huge_pmd(), which didn't have the same logic as zap_pte_range()
did), this patch just gets rid of the problem at the source: make the
TLB range information available to tlb_gather_mmu(), and initialize it
when initializing all the other tlb gather fields.

This makes the patch larger, but conceptually much simpler.  And the end
result is much more understandable; even if you want to play games with
partial ranges when invalidating the TLB contents in chunks, now the
range information is always there, and anybody who doesn't want to
bother with it won't introduce subtle bugs.

Ben verified that this fixes his problem.
Reported-bisected-and-tested-by: NBen Tebulin <tebulin@googlemail.com>
Build-testing-by: NStephen Rothwell <sfr@canb.auug.org.au>
Build-testing-by: NRichard Weinberger <richard.weinberger@gmail.com>
Reviewed-by: NMichal Hocko <mhocko@suse.cz>
Acked-by: NPeter Zijlstra <peterz@infradead.org>
Cc: stable@vger.kernel.org
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2b047252
  5. 14 8月, 2013 6 次提交
  7. 13 8月, 2013 1 次提交
    • O
      sched: fix the theoretical signal_wake_up() vs schedule() race · e0acd0a6
      由 Oleg Nesterov 提交于 
      This is only theoretical, but after try_to_wake_up(p) was changed
to check p->state under p->pi_lock the code like

	__set_current_state(TASK_INTERRUPTIBLE);
	schedule();

can miss a signal. This is the special case of wait-for-condition,
it relies on try_to_wake_up/schedule interaction and thus it does
not need mb() between __set_current_state() and if(signal_pending).

However, this __set_current_state() can move into the critical
section protected by rq->lock, now that try_to_wake_up() takes
another lock we need to ensure that it can't be reordered with
"if (signal_pending(current))" check inside that section.

The patch is actually one-liner, it simply adds smp_wmb() before
spin_lock_irq(rq->lock). This is what try_to_wake_up() already
does by the same reason.

We turn this wmb() into the new helper, smp_mb__before_spinlock(),
for better documentation and to allow the architectures to change
the default implementation.

While at it, kill smp_mb__after_lock(), it has no callers.

Perhaps we can also add smp_mb__before/after_spinunlock() for
prepare_to_wait().
Signed-off-by: NOleg Nesterov <oleg@redhat.com>
Acked-by: NPeter Zijlstra <peterz@infradead.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e0acd0a6
  9. 12 8月, 2013 1 次提交
  11. 09 8月, 2013 11 次提交
  13. 08 8月, 2013 1 次提交
  15. 05 8月, 2013 7 次提交
    • F
      MIPS: BMIPS: fix hardware interrupt routing for boot CPU != 0 · fcfa66de
      由 Florian Fainelli 提交于 
      The hardware interrupt routing for boot CPU != 0 is wrong because it
will route all the hardware interrupts to TP0 which is not the one we
booted from. Fix this by properly checking which boot CPU we are booting
from and updating the right interrupt mask for the boot CPU. This fixes
booting on BCM3368 with bmips_smp_emabled = 0.
Signed-off-by: NFlorian Fainelli <florian@openwrt.org>
Cc: linux-mips@linux-mips.org
Cc: blogic@openwrt.org
Cc: jogo@openwrt.org
Cc: cernekee@gmail.com
Patchwork: https://patchwork.linux-mips.org/patch/5650/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      fcfa66de
    • R
      MIPS: oprofile: Fix BUG due to smp_processor_id() in preemptible code. · cf5b2d23
      由 Ralf Baechle 提交于 
      current_cpu_type() is not preemption-safe.
If CONFIG_PREEMPT is enabled then mipsxx_reg_setup() can be called from preemptible state.
Added get_cpu()/put_cpu() pair to make it preemption-safe.

This was found while testing oprofile with CONFIG_DEBUG_PREEMPT enable.

/usr/zntestsuite # opcontrol --init
/usr/zntestsuite # opcontrol --setup --event=L2_CACHE_ACCESSES:500 --event=L2_CACHE_MISSES:500 --no-vmlinux
/usr/zntestsuite # opcontrol --start
Using 2.6+ OProfile kernel interface.
BUG: using smp_processor_id() in preemptible [00000000] code: oprofiled/1362
caller is mipsxx_reg_setup+0x11c/0x164
CPU: 0 PID: 1362 Comm: oprofiled Not tainted 3.10.4 #18
Stack : 00000006 70757465 00000000 00000000 00000000 00000000 80b173f6 00000037
          80b10000 00000000 80b21614 88f5a220 00000000 00000000 00000000 00000000
          00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
          00000000 00000000 00000000 89c49c00 89c49c2c 80721254 807b7927 8012c1d0
          80b10000 80721254 00000000 00000552 88f5a220 80b1335c 807b78e6 89c49ba8
          ...
Call Trace:
[<801099a4>] show_stack+0x64/0x7c
[<80665520>] dump_stack+0x20/0x2c
[<803a2250>] debug_smp_processor_id+0xe0/0xf0
[<8052df24>] mipsxx_reg_setup+0x11c/0x164
[<8052cd70>] op_mips_setup+0x24/0x4c
[<80529cfc>] oprofile_setup+0x5c/0x12c
[<8052b9f8>] event_buffer_open+0x78/0xf8
[<801c3150>] do_dentry_open.isra.15+0x2b8/0x3b0
[<801c3270>] finish_open+0x28/0x4c
[<801d49b8>] do_last.isra.41+0x2cc/0xd00
[<801d54a0>] path_openat+0xb4/0x4c4
[<801d5c44>] do_filp_open+0x3c/0xac
[<801c4744>] do_sys_open+0x110/0x1f4
[<8010f47c>] stack_done+0x20/0x44

Bug reported and original patch by Jerin Jacob <jerinjacobk@gmail.com>.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
Acked-by: NJerin Jacob <jerinjacobk@gmail.com>
      cf5b2d23
    • M
      MIPS: PNX833x: PNX8335_PCI_ETHERNET_INT depends on CONFIG_SOC_PNX8335 · 3ac3bcb9
      由 Markos Chandras 提交于 
      The PNX8335_PCI_ETHERNET_INT macro is defined in
arch/mips/include/asm/mach-pnx833x/irq-mapping.h
only if CONFIG_SOC_PNX8335 is selected.

Fixes the following randconfig problem:
arch/mips/pnx833x/common/platform.c:210:12:
error: 'PNX8335_PIC_ETHERNET_INT' undeclared here
(not in a function)
Signed-off-by: NMarkos Chandras <markos.chandras@imgtec.com>
Acked-by: NSteven J. Hill <Steven.Hill@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5585/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      3ac3bcb9
    • V
      perf/x86: Fix intel QPI uncore event definitions · c9601247
      由 Vince Weaver 提交于 
      John McCalpin reports that the "drs_data" and "ncb_data" QPI
uncore events are missing the "extra bit" and always return zero
values unless the bit is properly set.

More details from him:

 According to the Xeon E5-2600 Product Family Uncore Performance
 Monitoring Guide, Table 2-94, about 1/2 of the QPI Link Layer events
 (including the ones that "perf" calls "drs_data" and "ncb_data") require
 that the "extra bit" be set.

 This was confusing for a while -- a note at the bottom of page 94 says
 that the "extra bit" is bit 16 of the control register.
 Unfortunately, Table 2-86 clearly says that bit 16 is reserved and must
 be zero.  Looking around a bit, I found that bit 21 appears to be the
 correct "extra bit", and further investigation shows that "perf" actually
 agrees with me:
	[root@c560-003.stampede]# cat /sys/bus/event_source/devices/uncore_qpi_0/format/event
	config:0-7,21

 So the command
	# perf -e "uncore_qpi_0/event=drs_data/"
 Is the same as
	# perf -e "uncore_qpi_0/event=0x02,umask=0x08/"
 While it should be
	# perf -e "uncore_qpi_0/event=0x102,umask=0x08/"

 I confirmed that this last version gives results that agree with the
 amount of data that I expected the STREAM benchmark to move across the QPI
 link in the second (cross-chip) test of the original script.
Reported-by: NJohn McCalpin <mccalpin@tacc.utexas.edu>
Signed-off-by: NVince Weaver <vincent.weaver@maine.edu>
Cc: zheng.z.yan@intel.com
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Cc: Paul Mackerras <paulus@samba.org>
Cc: <stable@kernel.org>
Link: http://lkml.kernel.org/r/alpine.DEB.2.10.1308021037280.26119@vincent-weaver-1.um.maine.eduSigned-off-by: NIngo Molnar <mingo@kernel.org>
      c9601247
    • L
      ARM: tegra: enable ULPI phy on Colibri T20 · a1632ad3
      由 Lucas Stach 提交于 
      This was missed when splitting out the phy from the controller node in
commit 9dffe3be (ARM: tegra: modify ULPI reset GPIO properties).
Signed-off-by: NLucas Stach <dev@lynxeye.de>
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>
      a1632ad3
    • S
      ARM: STi: remove sti_secondary_start from INIT section. · d6f67eb7
      由 Srinivas Kandagatla 提交于 
      This patch removes sti_secondary_start from _INIT section, there are 2
reason for this removal.
 1. discarding such a small code does not save much, given the RAM
sizes.
 2. Having this code discarded, creates corruption issue when we boot
smp-kernel with nrcpus=1 or with single cpu node in DT.
Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@st.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>
      d6f67eb7
    • S
      ARM: STi: Fix cpu nodes with correct device_type. · 95e8ce69
      由 Srinivas Kandagatla 提交于 
      This patch fixes cpu nodes with device_type = "cpu". This change was not
necessary before 3.10-rc7.
Without this patch STi SOCs does not boot as SMP.
Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@st.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>
      95e8ce69
  17. 03 8月, 2013 2 次提交
  19. 02 8月, 2013 4 次提交
  21. 01 8月, 2013 2 次提交