Skip to content

cloud-kernel
cloud-kernel

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

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 15 4月, 2016 2 次提交
    • T
      ALSA: lx646es: Fix possible uninitialized variable reference · a19c921f
      由 Takashi Iwai 提交于 
      lx_pipe_state() checks the return value from lx_message_send_atomic()
and breaks the loop only when it's a negative value.  However,
lx_message_send_atomic() may return a positive error code (as the
return code from the hardware), and then lx_pipe_state() tries to
compare the uninitialized current_state variable.

Fix this behavior by checking the positive non-zero error code as
well.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      a19c921f
    • T
      ALSA: pcm : Call kill_fasync() in stream lock · 3aa02cb6
      由 Takashi Iwai 提交于 
      Currently kill_fasync() is called outside the stream lock in
snd_pcm_period_elapsed().  This is potentially racy, since the stream
may get released even during the irq handler is running.  Although
snd_pcm_release_substream() calls snd_pcm_drop(), this doesn't
guarantee that the irq handler finishes, thus the kill_fasync() call
outside the stream spin lock may be invoked after the substream is
detached, as recently reported by KASAN.

As a quick workaround, move kill_fasync() call inside the stream
lock.  The fasync is rarely used interface, so this shouldn't have a
big impact from the performance POV.

Ideally, we should implement some sync mechanism for the proper finish
of stream and irq handler.  But this oneliner should suffice for most
cases, so far.
Reported-by: NBaozeng Ding <sploving1@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      3aa02cb6
  3. 12 4月, 2016 2 次提交
  5. 09 4月, 2016 3 次提交
  7. 08 4月, 2016 1 次提交
  9. 06 4月, 2016 1 次提交
    • T
      ALSA: intel8x0: Drop superfluous VM checks · 4926c804
      由 Takashi Iwai 提交于 
      intel8x0 driver has the inside_vm check for skipping a buggy hardware
workaround in the PCM pointer callback in the commit [228cf793:
ALSA: intel8x0: Improve performance in virtual environment].  This was
originally applied to all devices on known VMs, but the code was
switched to use the PCI  ID matching for applying to only known
devices (KVM and Parallels), in order to avoid applying wrongly to
VT-d and other such cases, in the commit [7fb4f392: ALSA:
intel8x0: improve virtual environment detection].

Meanwhile, the original VM check was kept even after switching to the
PCI ID matching.  It was partly because we weren't 100% sure whether
we had covered all well, and partly because this would help
identifying the issue once when a user of another VM hit the same
problem or a regression.  Currently the VM check is used only for
showing the kernel message that the VM-optimization isn't applied, and
the VM check itself doesn't change the actual driver behavior at all.

Despite the relatively safe driver behavior, the code caught attention
of developers badly and brought many confusion / misunderstanding.
Since we've got neither regression nor enhancement report for other
VMs for five years long, it's likely safe to drop this superfluous VM
check now.

The module option is still kept, so if a user still needs to adjust,
it can be applied as was.
Acked-by: NKonstantin Ozerkov <kozerkov@parallels.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      4926c804
  11. 04 4月, 2016 4 次提交
  13. 03 4月, 2016 9 次提交
  15. 02 4月, 2016 18 次提交