Skip to content
  1. Oct 23, 2015
  3. Oct 22, 2015
  5. Oct 21, 2015
    • Paolo Bonzini's avatar
      Merge tag 'kvm-arm-for-v4.3-rc7' of... · ad355e38
      Paolo Bonzini authored 
      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
    • Bard Liao's avatar
      ASoC: rt298: fix wrong setting of gpio2_en · f8f2dc4a
      Bard Liao authored 
      

The register value to enable gpio2 was incorrect. So fix it.

Signed-off-by: default avatarBard Liao <bardliao@realtek.com>
Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      f8f2dc4a
    • Chaotian Jing's avatar
      mmc: core: Fix init_card in 52Mhz · 08b137d9
      Chaotian Jing authored 
      

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: default avatarChaotian Jing <chaotian.jing@mediatek.com>
Suggested-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
Fixes: bd11e8bd

 ("mmc: core: Flag re-tuning is needed on CRC errors")
Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      08b137d9
    • Steven Rostedt (Red Hat)'s avatar
      tracing: Do not allow stack_tracer to record stack in NMI · 1904be1b
      Steven Rostedt (Red Hat) authored 
      

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: default avatarSteven Rostedt <rostedt@goodmis.org>
      1904be1b
    • Christoffer Dall's avatar
      arm/arm64: KVM: Fix disabled distributor operation · 0d997491
      Christoffer Dall authored 
      

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: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      0d997491
    • Christoffer Dall's avatar
      arm/arm64: KVM: Clear map->active on pend/active clear · 544c572e
      Christoffer Dall authored 
      

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: default avatarEric Auger <eric.auger@linaro.org>
Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      544c572e
    • Christoffer Dall's avatar
      arm/arm64: KVM: Fix arch timer behavior for disabled interrupts · cff9211e
      Christoffer Dall authored 
      

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: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      cff9211e
    • Arnd Bergmann's avatar
      KVM: arm: use GIC support unconditionally · 4a5d69b7
      Arnd Bergmann authored 
      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: default avatarArnd Bergmann <arnd@arndb.de>
Acked-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      4a5d69b7
    • Pavel Fedin's avatar
      KVM: arm/arm64: Fix memory leak if timer initialization fails · 399ea0f6
      Pavel Fedin authored 
      

Jump to correct label and free kvm_host_cpu_state

Reviewed-by: default avatarWei Huang <wei@redhat.com>
Signed-off-by: default avatarPavel Fedin <p.fedin@samsung.com>
Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      399ea0f6
    • Pavel Fedin's avatar
      KVM: arm/arm64: Do not inject spurious interrupts · 437f9963
      Pavel Fedin authored 
      

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: default avatarPavel Fedin <p.fedin@samsung.com>
Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      437f9963
  7. Oct 20, 2015
    • Steven Rostedt (Red Hat)'s avatar
      tracing: Have stack tracer force RCU to be watching · a2d76290
      Steven Rostedt (Red Hat) authored 
      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: default avatarSteven Rostedt <rostedt@goodmis.org>
      a2d76290
    • Charles Keepax's avatar
      ASoC: wm8904: Correct number of EQ registers · 97aff2c0
      Charles Keepax authored 
      

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: default avatarCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: default avatarMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
      97aff2c0
    • Takashi Iwai's avatar
      ALSA: hda - Fix deadlock at error in building PCM · d289619a
      Takashi Iwai authored 
      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: default avatarTakashi Iwai <tiwai@suse.de>
      d289619a