Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 23 10月, 2015 19 次提交
  3. 22 10月, 2015 8 次提交
  5. 21 10月, 2015 10 次提交
    • P
      Merge tag 'kvm-arm-for-v4.3-rc7' of... · ad355e38
      由 Paolo Bonzini 提交于 
      Merge tag 'kvm-arm-for-v4.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into kvm-master

A late round of KVM/ARM fixes for v4.3-rc7, fixing:
 - A bug where level-triggered interrupts lowered from userspace
   are still routed to the guest
 - A memory leak an a failed initialization path
 - A build error under certain configurations
 - Several timer bugs introduced with moving the timer to the active
   state handling instead of the masking trick.
      ad355e38
    • B
      ASoC: rt298: fix wrong setting of gpio2_en · f8f2dc4a
      由 Bard Liao 提交于 
      The register value to enable gpio2 was incorrect. So fix it.
Signed-off-by: NBard Liao <bardliao@realtek.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
      f8f2dc4a
    • C
      mmc: core: Fix init_card in 52Mhz · 08b137d9
      由 Chaotian Jing 提交于 
      Suppose that we got a data crc error, and it triggers the mmc_reset.
mmc_reset will call mmc_send_status to see if HW reset was supported.
before issue CMD13, it will do retune, and if EMMC was in HS400 mode,
it will reduce frequency to 52Mhz firstly, then results in card init
was doing at 52Mhz.
The mmc_send_status was originally only done for mmc_test, should drop
it. And, rename the "eMMC hardware reset" to "Reset test", as we would
also be able to use the test for SD-cards.
Signed-off-by: NChaotian Jing <chaotian.jing@mediatek.com>
Suggested-by: NAdrian Hunter <adrian.hunter@intel.com>
Fixes: bd11e8bd ("mmc: core: Flag re-tuning is needed on CRC errors")
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      08b137d9
    • S
      tracing: Do not allow stack_tracer to record stack in NMI · 1904be1b
      由 Steven Rostedt (Red Hat) 提交于 
      The code in stack tracer should not be executed within an NMI as it grabs
spinlocks and stack tracing an NMI gives the possibility of causing a
deadlock. Although this is safe on x86_64, because it does not perform stack
traces when the task struct stack is not in use (interrupts and NMIs), it
may be an issue for NMIs on i386 and other archs that use the same stack as
the NMI.
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      1904be1b
    • C
      arm/arm64: KVM: Fix disabled distributor operation · 0d997491
      由 Christoffer Dall 提交于 
      We currently do a single update of the vgic state when the distributor
enable/disable control register is accessed and then bypass updating the
state for as long as the distributor remains disabled.

This is incorrect, because updating the state does not consider the
distributor enable bit, and this you can end up in a situation where an
interrupt is marked as pending on the CPU interface, but not pending on
the distributor, which is an impossible state to be in, and triggers a
warning.  Consider for example the following sequence of events:

1. An interrupt is marked as pending on the distributor
   - the interrupt is also forwarded to the CPU interface
2. The guest turns off the distributor (it's about to do a reboot)
   - we stop updating the CPU interface state from now on
3. The guest disables the pending interrupt
   - we remove the pending state from the distributor, but don't touch
     the CPU interface, see point 2.

Since the distributor disable bit really means that no interrupts should
be forwarded to the CPU interface, we modify the code to keep updating
the internal VGIC state, but always set the CPU interface pending bits
to zero when the distributor is disabled.
Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
      0d997491
    • C
      arm/arm64: KVM: Clear map->active on pend/active clear · 544c572e
      由 Christoffer Dall 提交于 
      When a guest reboots or offlines/onlines CPUs, it is not uncommon for it
to clear the pending and active states of an interrupt through the
emulated VGIC distributor.  However, since the architected timers are
defined by the architecture to be level triggered and the guest
rightfully expects them to be that, but we emulate them as
edge-triggered, we have to mimic level-triggered behavior for an
edge-triggered virtual implementation.

We currently do not signal the VGIC when the map->active field is true,
because it indicates that the guest has already been signalled of the
interrupt as required.  Normally this field is set to false when the
guest deactivates the virtual interrupt through the sync path.

We also need to catch the case where the guest deactivates the interrupt
through the emulated distributor, again allowing guests to boot even if
the original virtual timer signal hit before the guest's GIC
initialization sequence is run.
Reviewed-by: NEric Auger <eric.auger@linaro.org>
Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
      544c572e
    • C
      arm/arm64: KVM: Fix arch timer behavior for disabled interrupts · cff9211e
      由 Christoffer Dall 提交于 
      We have an interesting issue when the guest disables the timer interrupt
on the VGIC, which happens when turning VCPUs off using PSCI, for
example.

The problem is that because the guest disables the virtual interrupt at
the VGIC level, we never inject interrupts to the guest and therefore
never mark the interrupt as active on the physical distributor.  The
host also never takes the timer interrupt (we only use the timer device
to trigger a guest exit and everything else is done in software), so the
interrupt does not become active through normal means.

The result is that we keep entering the guest with a programmed timer
that will always fire as soon as we context switch the hardware timer
state and run the guest, preventing forward progress for the VCPU.

Since the active state on the physical distributor is really part of the
timer logic, it is the job of our virtual arch timer driver to manage
this state.

The timer->map->active boolean field indicates whether we have signalled
this interrupt to the vgic and if that interrupt is still pending or
active.  As long as that is the case, the hardware doesn't have to
generate physical interrupts and therefore we mark the interrupt as
active on the physical distributor.

We also have to restore the pending state of an interrupt that was
queued to an LR but was retired from the LR for some reason, while
remaining pending in the LR.

Cc: Marc Zyngier <marc.zyngier@arm.com>
Reported-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
      cff9211e
    • A
      KVM: arm: use GIC support unconditionally · 4a5d69b7
      由 Arnd Bergmann 提交于 
      The vgic code on ARM is built for all configurations that enable KVM,
but the parent_data field that it references is only present when
CONFIG_IRQ_DOMAIN_HIERARCHY is set:

virt/kvm/arm/vgic.c: In function 'kvm_vgic_map_phys_irq':
virt/kvm/arm/vgic.c:1781:13: error: 'struct irq_data' has no member named 'parent_data'

This flag is implied by the GIC driver, and indeed the VGIC code only
makes sense if a GIC is present. This changes the CONFIG_KVM symbol
to always select GIC, which avoids the issue.

Fixes: 662d9715 ("arm/arm64: KVM: Kill CONFIG_KVM_ARM_{VGIC,TIMER}")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
      4a5d69b7
    • P
      KVM: arm/arm64: Fix memory leak if timer initialization fails · 399ea0f6
      由 Pavel Fedin 提交于 
      Jump to correct label and free kvm_host_cpu_state
Reviewed-by: NWei Huang <wei@redhat.com>
Signed-off-by: NPavel Fedin <p.fedin@samsung.com>
Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
      399ea0f6
    • P
      KVM: arm/arm64: Do not inject spurious interrupts · 437f9963
      由 Pavel Fedin 提交于 
      When lowering a level-triggered line from userspace, we forgot to lower
the pending bit on the emulated CPU interface and we also did not
re-compute the pending_on_cpu bitmap for the CPU affected by the change.

Update vgic_update_irq_pending() to fix the two issues above and also
raise a warning in vgic_quue_irq_to_lr if we encounter an interrupt
pending on a CPU which is neither marked active nor pending.

  [ Commit text reworked completely - Christoffer ]
Signed-off-by: NPavel Fedin <p.fedin@samsung.com>
Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
      437f9963
  7. 20 10月, 2015 3 次提交
    • S
      tracing: Have stack tracer force RCU to be watching · a2d76290
      由 Steven Rostedt (Red Hat) 提交于 
      The stack tracer was triggering the WARN_ON() in module.c:

 static void module_assert_mutex_or_preempt(void)
 {
 #ifdef CONFIG_LOCKDEP
	if (unlikely(!debug_locks))
		return;

	WARN_ON(!rcu_read_lock_sched_held() &&
		!lockdep_is_held(&module_mutex));
 #endif
 }

The reason is that the stack tracer traces all function calls, and some of
those calls happen while exiting or entering user space and idle. Some of
these functions are called after RCU had already stopped watching, as RCU
does not watch userspace or idle CPUs.

If a max stack is hit, then the save_stack_trace() is called, which will
check module addresses and call module_assert_mutex_or_preempt(), and then
trigger the warning. Sad part is, the warning itself will also do a stack
trace and tigger the same warning. That probably should be fixed.

The warning was added by 0be964be "module: Sanitize RCU usage and
locking" but this bug has probably been around longer. But it's unlikely to
cause much harm, but the new warning causes the system to lock up.

Cc: stable@vger.kernel.org # 4.2+
Cc: Peter Zijlstra <peterz@infradead.org>
Cc:"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      a2d76290
    • C
      ASoC: wm8904: Correct number of EQ registers · 97aff2c0
      由 Charles Keepax 提交于 
      There are 24 EQ registers not 25, I suspect this bug came about because
the registers start at EQ1 not zero. The bug is relatively harmless as
the extra register written is an unused one.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
      97aff2c0
    • T
      ALSA: hda - Fix deadlock at error in building PCM · d289619a
      由 Takashi Iwai 提交于 
      The HDA codec driver issues snd_hda_codec_reset() at the error path of
PCM build.  This was needed in the earlier code base, but the recent
rewrite to use the standard bus binding made this a deadlock:
 modprobe        D 0000000000000005     0   720    716 0x00000080
 Call Trace:
  [<ffffffff816a5dbe>] schedule+0x3e/0x90
  [<ffffffff816a61a5>] schedule_preempt_disabled+0x15/0x20
  [<ffffffff816a7ae5>] __mutex_lock_slowpath+0xb5/0x120
  [<ffffffff816a7b6b>] mutex_lock+0x1b/0x30
  [<ffffffff8148656b>] device_release_driver+0x1b/0x30
  [<ffffffff81485c15>] bus_remove_device+0x105/0x180
  [<ffffffff814822b9>] device_del+0x139/0x260
  [<ffffffffa05e0ec5>] snd_hdac_device_unregister+0x25/0x30 [snd_hda_core]
  [<ffffffffa074fa6a>] snd_hda_codec_reset+0x2a/0x70 [snd_hda_codec]
  [<ffffffffa075007b>] snd_hda_codec_build_pcms+0x18b/0x1b0 [snd_hda_codec]
  [<ffffffffa074a44e>] hda_codec_driver_probe+0xbe/0x140 [snd_hda_codec]
  [<ffffffff81486ac4>] driver_probe_device+0x1f4/0x460
  [<ffffffff81486dc0>] __driver_attach+0x90/0xa0
  [<ffffffff81484844>] bus_for_each_dev+0x64/0xa0
  [<ffffffff814862de>] driver_attach+0x1e/0x20
  [<ffffffff81485e7b>] bus_add_driver+0x1eb/0x280
  [<ffffffff81487680>] driver_register+0x60/0xe0
  [<ffffffffa074a0da>] __hda_codec_driver_register+0x5a/0x60 [snd_hda_codec]
  [<ffffffffa070a01e>] realtek_driver_init+0x1e/0x1000 [snd_hda_codec_realtek]
  [<ffffffff810002f3>] do_one_initcall+0xb3/0x200
  [<ffffffff816a1fc5>] do_init_module+0x60/0x1f8
  [<ffffffff810ee5c3>] load_module+0x1653/0x1bd0
  [<ffffffff810eed48>] SYSC_finit_module+0x98/0xc0
  [<ffffffff810eed8e>] SyS_finit_module+0xe/0x10
  [<ffffffff816aa032>] entry_SYSCALL_64_fastpath+0x16/0x75

The simple fix is just to remove this call, since we don't need to
think about unbinding at there any longer.

Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=948758
Cc: <stable@vger.kernel.org> # v4.1+
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      d289619a