Skip to content

L
linux
Switch branch/tag
  1. 10 Jan, 2018 2 commits
  3. 08 Jan, 2018 2 commits
    • Takashi Iwai's avatar
      ALSA: pcm: Allow aborting mutex lock at OSS read/write loops · 900498a3
      Takashi Iwai authored 
      PCM OSS read/write loops keep taking the mutex lock for the whole
read/write, and this might take very long when the exceptionally high
amount of data is given.  Also, since it invokes with mutex_lock(),
the concurrent read/write becomes unbreakable.

This patch tries to address these issues by replacing mutex_lock()
with mutex_lock_interruptible(), and also splits / re-takes the lock
at each read/write period chunk, so that it can switch the context
more finely if requested.

Cc: <stable@vger.kernel.org>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      900498a3
    • Takashi Iwai's avatar
      ALSA: pcm: Abort properly at pending signal in OSS read/write loops · 29159a4e
      Takashi Iwai authored 
      The loops for read and write in PCM OSS emulation have no proper check
of pending signals, and they keep processing even after user tries to
break.  This results in a very long delay, often seen as RCU stall
when a huge unprocessed bytes remain queued.  The bug could be easily
triggered by syzkaller.

As a simple workaround, this patch adds the proper check of pending
signals and aborts the loop appropriately.

Reported-by: syzbot+993cb4cfcbbff3947c21@syzkaller.appspotmail.com
Cc: <stable@vger.kernel.org>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      29159a4e
  5. 05 Jan, 2018 4 commits
    • Takashi Iwai's avatar
      ALSA: aloop: Fix racy hw constraints adjustment · 898dfe46
      Takashi Iwai authored 
      The aloop driver tries to update the hw constraints of the connected
target on the cable of the opened PCM substream.  This is done by
adding the extra hw constraints rules referring to the substream
runtime->hw fields, while the other substream may update the runtime
hw of another side on the fly.

This is, however, racy and may result in the inconsistent values when
both PCM streams perform the prepare concurrently.  One of the reason
is that it overwrites the other's runtime->hw field; which is not only
racy but also broken when it's called before the open of another side
finishes.  And, since the reference to runtime->hw isn't protected,
the concurrent write may give the partial value update and become
inconsistent.

This patch is an attempt to fix and clean up:
- The prepare doesn't change the runtime->hw of other side any longer,
  but only update the cable->hw that is referred commonly.
- The extra rules refer to the loopback_pcm object instead of the
  runtime->hw.  The actual hw is deduced from cable->hw.
- The extra rules take the cable_lock to protect against the race.

Fixes: b1c73fc8 ("ALSA: snd-aloop: Fix hw_params restrictions and checking")
Cc: <stable@vger.kernel.org>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      898dfe46
    • Takashi Iwai's avatar
      ALSA: aloop: Fix inconsistent format due to incomplete rule · b088b53e
      Takashi Iwai authored 
      The extra hw constraint rule for the formats the aloop driver
introduced has a slight flaw, where it doesn't return a positive value
when the mask got changed.  It came from the fact that it's basically
a copy&paste from snd_hw_constraint_mask64().  The original code is
supposed to be a single-shot and it modifies the mask bits only once
and never after, while what we need for aloop is the dynamic hw rule
that limits the mask bits.

This difference results in the inconsistent state, as the hw_refine
doesn't apply the dependencies fully.  The worse and surprisingly
result is that it causes a crash in OSS emulation when multiple
full-duplex reads/writes are performed concurrently (I leave why it
triggers Oops to readers as a homework).

For fixing this, replace a few open-codes with the standard
snd_mask_*() macros.

Reported-by: syzbot+3902b5220e8ca27889ca@syzkaller.appspotmail.com
Fixes: b1c73fc8 ("ALSA: snd-aloop: Fix hw_params restrictions and checking")
Cc: <stable@vger.kernel.org>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      b088b53e
    • Takashi Iwai's avatar
      ALSA: aloop: Release cable upon open error path · 9685347a
      Takashi Iwai authored 
      The aloop runtime object and its assignment in the cable are left even
when opening a substream fails.  This doesn't mean any memory leak,
but it still keeps the invalid pointer that may be referred by the
another side of the cable spontaneously, which is a potential Oops
cause.

Clean up the cable assignment and the empty cable upon the error path
properly.

Fixes: 597603d6 ("ALSA: introduce the snd-aloop module for the PCM loopback")
Cc: <stable@vger.kernel.org>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      9685347a
    • Takashi Iwai's avatar
      ALSA: pcm: Workaround for weird PulseAudio behavior on rewind error · fb51f1cd
      Takashi Iwai authored 
      The commit 9027c463 ("ALSA: pcm: Call ack() whenever appl_ptr is
updated") introduced the possible error code returned from the PCM
rewind ioctl.  Basically the change was for handling the indirect PCM
more correctly, but ironically, it caused rather a side-effect:
PulseAudio gets pissed off when receiving an error from rewind, throws
everything away and stops processing further, resulting in the
silence.

It's clearly a failure in the application side, so the best would be
to fix that bug in PA.  OTOH, PA is mostly the only user of the rewind
feature, so it's not good to slap the sole customer.

This patch tries to mitigate the situation: instead of returning an
error, now the rewind ioctl returns zero when the driver can't rewind.
It indicates that no rewind was performed, so the behavior is
consistent, at least.

Fixes: 9027c463 ("ALSA: pcm: Call ack() whenever appl_ptr is updated")
Cc: <stable@vger.kernel.org>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      fb51f1cd
  7. 04 Jan, 2018 1 commit
  9. 02 Jan, 2018 1 commit
    • Takashi Iwai's avatar
      ALSA: pcm: Remove incorrect snd_BUG_ON() usages · fe08f34d
      Takashi Iwai authored 
      syzkaller triggered kernel warnings through PCM OSS emulation at
closing a stream:
  WARNING: CPU: 0 PID: 3502 at sound/core/pcm_lib.c:1635
  snd_pcm_hw_param_first+0x289/0x690 sound/core/pcm_lib.c:1635
  Call Trace:
  ....
   snd_pcm_hw_param_near.constprop.27+0x78d/0x9a0 sound/core/oss/pcm_oss.c:457
   snd_pcm_oss_change_params+0x17d3/0x3720 sound/core/oss/pcm_oss.c:969
   snd_pcm_oss_make_ready+0xaa/0x130 sound/core/oss/pcm_oss.c:1128
   snd_pcm_oss_sync+0x257/0x830 sound/core/oss/pcm_oss.c:1638
   snd_pcm_oss_release+0x20b/0x280 sound/core/oss/pcm_oss.c:2431
   __fput+0x327/0x7e0 fs/file_table.c:210
   ....

This happens while it tries to open and set up the aloop device
concurrently.  The warning above (invoked from snd_BUG_ON() macro) is
to detect the unexpected logical error where snd_pcm_hw_refine() call
shouldn't fail.  The theory is true for the case where the hw_params
config rules are static.  But for an aloop device, the hw_params rule
condition does vary dynamically depending on the connected target;
when another device is opened and changes the parameters, the device
connected in another side is also affected, and it caused the error
from snd_pcm_hw_refine().

That is, the simplest "solution" for this is to remove the incorrect
assumption of static rules, and treat such an error as a normal error
path.  As there are a couple of other places using snd_BUG_ON()
incorrectly, this patch removes these spurious snd_BUG_ON() calls.

Reported-by: syzbot+6f11c7e2a1b91d466432@syzkaller.appspotmail.com
Cc: <stable@vger.kernel.org>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      fe08f34d
  11. 27 Dec, 2017 1 commit
  13. 22 Dec, 2017 4 commits
  15. 20 Dec, 2017 8 commits
  17. 19 Dec, 2017 3 commits
    • Brian Norris's avatar
      ASoC: rt5514-spi: only enable wakeup when fully initialized · 20220945
      Brian Norris authored 
      If an rt5514-spi device is probed but the platform hasn't linked it in,
we might never fully request the SPI IRQ, nor configure the rt5514 DSP,
but we still might try to enable the SPI IRQ (enable_irq_wake()). This
is bad, and among other things, can cause the interrupt to trigger every
time we try to suspend the system (e.g., because the interrupt trigger
setting was never set properly).

Instead of setting our wakeup capabilities in the SPI driver probe
routine, let's wait until we've actually requested the IRQ.

Fixes issues seen on the "kevin" Chromebook (Samsung Chromebook Plus).

Fixes: 58f1c07d ("ASoC: rt5514: Voice wakeup support.")
Signed-off-by: default avatarBrian Norris <briannorris@chromium.org>
Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      20220945
    • Abhijeet Kumar's avatar
      ASoC: nau8825: fix issue that pop noise when start capture · d070f7c7
      Abhijeet Kumar authored 
      In skylake platform, we hear a loud pop noise(0 dB) at start of
audio capture power up sequence. This patch removes the pop noise
from the recording by adding a delay before enabling ADC.
Signed-off-by: default avatarAbhijeet Kumar <abhijeet.kumar@intel.com>
Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      d070f7c7
    • Takashi Iwai's avatar
      ALSA: usb-audio: Fix the missing ctl name suffix at parsing SU · 5a15f289
      Takashi Iwai authored 
      The commit 89b89d12 ("ALSA: usb-audio: Add check return value for
usb_string()") added the check of the return value from
snd_usb_copy_string_desc(), which is correct per se, but it introduced
a regression.  In the original code, either the "Clock Source",
"Playback Source" or "Capture Source" suffix is added after the
terminal string, while the commit changed it to add the suffix only
when get_term_name() is failing.  It ended up with an incorrect ctl
name like "PCM" instead of "PCM Capture Source".

Also, even the original code has a similar bug: when the ctl name is
generated from snd_usb_copy_string_desc() for the given iSelector, it
also doesn't put the suffix.

This patch addresses these issues: the suffix is added always when no
static mapping is found.  Also the patch tries to put more comments
and cleans up the if/else block for better readability in order to
avoid the same pitfall again.

Fixes: 89b89d12 ("ALSA: usb-audio: Add check return value for usb_string()")
Reported-and-tested-by: default avatarMauro Santos <registo.mailling@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      5a15f289
  19. 18 Dec, 2017 2 commits
    • Kailang Yang's avatar
      ALSA: hda/realtek - Fix Dell AIO LineOut issue · 92266651
      Kailang Yang authored 
      Dell AIO had LineOut jack.
Add LineOut verb into this patch.

[ Additional notes:
  the ALC274 codec seems requiring the fixed pin / DAC connections for
  HP / line-out pins for enabling EQ for speakers; i.e. the HP / LO
  pins expect to be connected with NID 0x03 while keeping the speaker
  with NID 0x02.  However, by adding a new line-out pin, the
  auto-parser assigns the NID 0x02 for HP/LO pins as primary outputs.
  As an easy workaround, we provide the preferred_pairs[] to map
  forcibly for these pins. -- tiwai ]

Fixes: 75ee94b2 ("ALSA: hda - fix headset mic problem for Dell machines with alc274")
Signed-off-by: default avatarKailang Yang <kailang@realtek.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      92266651
    • Linus Torvalds's avatar
      Linux 4.15-rc4 · 1291a0d5
      Linus Torvalds authored
      1291a0d5
  21. 17 Dec, 2017 12 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7