Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46 |
|
#
6c0217b1 |
| 15-Aug-2023 |
Takashi Iwai <tiwai@suse.de> |
ALSA: pcm: Drop obsoleted PCM copy_user and copy_kernel ops
Finally all users have been converted to the new PCM copy ops, let's drop the obsoleted copy_kernel and copy_user ops completely.
Link: h
ALSA: pcm: Drop obsoleted PCM copy_user and copy_kernel ops
Finally all users have been converted to the new PCM copy ops, let's drop the obsoleted copy_kernel and copy_user ops completely.
Link: https://lore.kernel.org/r/20230815190136.8987-26-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
show more ...
|
#
cf393bab |
| 15-Aug-2023 |
Takashi Iwai <tiwai@suse.de> |
ALSA: pcm: Add copy ops with iov_iter
iov_iter is a universal interface to copy the data chunk from/to user-space and kernel in a unified manner. This API can fit for ALSA PCM copy ops, too; we had
ALSA: pcm: Add copy ops with iov_iter
iov_iter is a universal interface to copy the data chunk from/to user-space and kernel in a unified manner. This API can fit for ALSA PCM copy ops, too; we had to split to copy_user and copy_kernel in the past, and those can be unified to a single ops with iov_iter.
This patch adds a new PCM copy ops that passes iov_iter for copying both kernel and user-space in the same way. This patch touches only the ALSA PCM core part, and the actual users will be replaced in the following patches.
The expansion of iov_iter is done in the PCM core right before calling each copy callback. It's a bit suboptimal, but I took this now as it's the most straightforward replacement. The more conversion to iov_iter in the caller side is a TODO for future.
As of now, the old copy_user and copy_kernel ops are still kept. Once after all users are converted, we'll drop the old copy_user and copy_kernel ops, too.
Link: https://lore.kernel.org/r/20230815190136.8987-3-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
show more ...
|
Revision tags: v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30 |
|
#
1e5323bd |
| 17-May-2023 |
Oswald Buddenhagen <oswald.buddenhagen@gmx.de> |
Revert "ALSA: emu10k1 - delay the PCM interrupts (add pcm_irq_delay parameter)"
This workaround fails to address the underlying problem, which is actually wholly self-made. Subsequent patches will f
Revert "ALSA: emu10k1 - delay the PCM interrupts (add pcm_irq_delay parameter)"
This workaround fails to address the underlying problem, which is actually wholly self-made. Subsequent patches will fix it.
This reverts commit 56385a12d9bb9e173751f74b6c430742018cafc0.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230517174256.3657060-2-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
show more ...
|
Revision tags: v6.1.29, v6.1.28 |
|
#
d7f5dd97 |
| 05-May-2023 |
Jaroslav Kysela <perex@perex.cz> |
ALSA: pcm: Revert "ALSA: pcm: rewrite snd_pcm_playback_silence()"
This reverts commit 9f656705c5faa18afb26d922cfc64f9fd103c38d.
There was a regression (in the top-up mode). Unfortunately, the patch
ALSA: pcm: Revert "ALSA: pcm: rewrite snd_pcm_playback_silence()"
This reverts commit 9f656705c5faa18afb26d922cfc64f9fd103c38d.
There was a regression (in the top-up mode). Unfortunately, the patch provided from the author of this commit is not easy to review.
Keep the updated and new comments in headers. Also add a new comment that documents the missed API constraint which led to the regression.
Reported-by: Jeff Chua <jeff.chua.linux@gmail.com> Link: https://lore.kernel.org/r/CAAJw_ZsbTVd3Es373x_wTNDF7RknGhCD0r+NKUSwAO7HpLAkYA@mail.gmail.com Signed-off-by: Jaroslav Kysela <perex@perex.cz> Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230505155244.2312199-1-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
show more ...
|
Revision tags: v6.1.27, v6.1.26, v6.3 |
|
#
9f656705 |
| 20-Apr-2023 |
Oswald Buddenhagen <oswald.buddenhagen@gmx.de> |
ALSA: pcm: rewrite snd_pcm_playback_silence()
The auto-silencer supports two modes: "thresholded" to fill up "just enough", and "top-up" to fill up "as much as possible". The two modes used rather d
ALSA: pcm: rewrite snd_pcm_playback_silence()
The auto-silencer supports two modes: "thresholded" to fill up "just enough", and "top-up" to fill up "as much as possible". The two modes used rather distinct code paths, which this patch unifies. The only remaining distinction is how much we actually want to fill.
This fixes a bug in thresholded mode, where we failed to use new_hw_ptr, resulting in under-fill.
Top-up mode is now more well-behaved and much easier to understand in corner cases.
This also updates comments in the proximity of silencing-related data structures.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Reviewed-by: Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20230420113324.877164-1-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
show more ...
|
Revision tags: v6.1.25, v6.1.24, v6.1.23 |
|
#
3ed2b549 |
| 05-Apr-2023 |
Oswald Buddenhagen <oswald.buddenhagen@gmx.de> |
ALSA: pcm: fix wait_time calculations
... in wait_for_avail() and snd_pcm_drain().
t was calculated in seconds, so it would be pretty much always zero, to be subsequently de-facto ignored due to be
ALSA: pcm: fix wait_time calculations
... in wait_for_avail() and snd_pcm_drain().
t was calculated in seconds, so it would be pretty much always zero, to be subsequently de-facto ignored due to being max(t, 10)'d. And then it (i.e., 10) would be treated as secs, which doesn't seem right.
However, fixing it to properly calculate msecs would potentially cause timeouts when using twice the period size for the default timeout (which seems reasonable to me), so instead use the buffer size plus 10 percent to be on the safe side ... but that still seems insufficient, presumably because the hardware typically needs a moment to fire up. To compensate for this, we up the minimal timeout to 100ms, which is still two orders of magnitude less than the bogus minimum.
substream->wait_time was also misinterpreted as jiffies, despite being documented as being in msecs. Only the soc/sof driver sets it - to 500, which looks very much like msecs were intended.
Speaking of which, shouldn't snd_pcm_drain() also use substream-> wait_time?
As a drive-by, make the debug messages on timeout less confusing.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230405201219.2197774-1-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
show more ...
|
Revision tags: v6.1.22 |
|
#
e4d3202c |
| 28-Mar-2023 |
Jens Axboe <axboe@kernel.dk> |
ALSA: pcm: check for user backed iterator, not specific iterator type
In preparation for switching single segment iterators to using ITER_UBUF, swap the check for whether we are user backed or not.
ALSA: pcm: check for user backed iterator, not specific iterator type
In preparation for switching single segment iterators to using ITER_UBUF, swap the check for whether we are user backed or not.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
show more ...
|
#
de4f5fed |
| 29-Mar-2023 |
Jens Axboe <axboe@kernel.dk> |
iov_iter: add iter_iovec() helper
This returns a pointer to the current iovec entry in the iterator. Only useful with ITER_IOVEC right now, but it prepares us to treat ITER_UBUF and ITER_IOVEC ident
iov_iter: add iter_iovec() helper
This returns a pointer to the current iovec entry in the iterator. Only useful with ITER_IOVEC right now, but it prepares us to treat ITER_UBUF and ITER_IOVEC identically for the first segment.
Rename struct iov_iter->iov to iov_iter->__iov to find any potentially troublesome spots, and also to prevent anyone from adding new code that accesses iter->iov directly.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
show more ...
|
Revision tags: v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9 |
|
#
1c71222e |
| 26-Jan-2023 |
Suren Baghdasaryan <surenb@google.com> |
mm: replace vma->vm_flags direct modifications with modifier calls
Replace direct modifications to vma->vm_flags with calls to modifier functions to be able to track flag changes and to keep vma loc
mm: replace vma->vm_flags direct modifications with modifier calls
Replace direct modifications to vma->vm_flags with calls to modifier functions to be able to track flag changes and to keep vma locking correctness.
[akpm@linux-foundation.org: fix drivers/misc/open-dice.c, per Hyeonggon Yoo] Link: https://lkml.kernel.org/r/20230126193752.297968-5-surenb@google.com Signed-off-by: Suren Baghdasaryan <surenb@google.com> Acked-by: Michal Hocko <mhocko@suse.com> Acked-by: Mel Gorman <mgorman@techsingularity.net> Acked-by: Mike Rapoport (IBM) <rppt@kernel.org> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Liam R. Howlett <Liam.Howlett@Oracle.com> Reviewed-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arjun Roy <arjunroy@google.com> Cc: Axel Rasmussen <axelrasmussen@google.com> Cc: David Hildenbrand <david@redhat.com> Cc: David Howells <dhowells@redhat.com> Cc: Davidlohr Bueso <dave@stgolabs.net> Cc: David Rientjes <rientjes@google.com> Cc: Eric Dumazet <edumazet@google.com> Cc: Greg Thelen <gthelen@google.com> Cc: Hugh Dickins <hughd@google.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jann Horn <jannh@google.com> Cc: Joel Fernandes <joelaf@google.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Kent Overstreet <kent.overstreet@linux.dev> Cc: Laurent Dufour <ldufour@linux.ibm.com> Cc: Lorenzo Stoakes <lstoakes@gmail.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Minchan Kim <minchan@google.com> Cc: Paul E. McKenney <paulmck@kernel.org> Cc: Peter Oskolkov <posk@google.com> Cc: Peter Xu <peterx@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Punit Agrawal <punit.agrawal@bytedance.com> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: Shakeel Butt <shakeelb@google.com> Cc: Soheil Hassas Yeganeh <soheil@google.com> Cc: Song Liu <songliubraving@fb.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Will Deacon <will@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
show more ...
|
Revision tags: v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12 |
|
#
e661c488 |
| 05-Dec-2022 |
Takashi Iwai <tiwai@suse.de> |
ALSA: pcm: Handle XRUN at trigger START
When the driver returns -EPIPE for indicating an XRUN already at PCM trigger START, we should treat properly and set it to the XRUN state. Otherwise the state
ALSA: pcm: Handle XRUN at trigger START
When the driver returns -EPIPE for indicating an XRUN already at PCM trigger START, we should treat properly and set it to the XRUN state. Otherwise the state is missing and the application would try to issue trigger again without knowing that it's in an error state.
This is just for a theoretical bug, and it won't happen in most cases.
Link: https://lore.kernel.org/r/b4e71631-4a94-613-27b2-fb595792630@carlh.net Link: https://lore.kernel.org/r/20221205132124.11585-3-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
show more ...
|
#
5c8cc93b |
| 05-Dec-2022 |
Takashi Iwai <tiwai@suse.de> |
ALSA: pcm: Set missing stop_operating flag at undoing trigger start
When a PCM trigger-start fails at snd_pcm_do_start(), PCM core tries to undo the action at snd_pcm_undo_start() by issuing the tri
ALSA: pcm: Set missing stop_operating flag at undoing trigger start
When a PCM trigger-start fails at snd_pcm_do_start(), PCM core tries to undo the action at snd_pcm_undo_start() by issuing the trigger STOP manually. At that point, we forgot to set the stop_operating flag, hence the sync-stop won't be issued at the next prepare or other calls.
This patch adds the missing stop_operating flag at snd_pcm_undo_start().
Fixes: 1e850beea278 ("ALSA: pcm: Add the support for sync-stop operation") Link: https://lore.kernel.org/r/b4e71631-4a94-613-27b2-fb595792630@carlh.net Link: https://lore.kernel.org/r/20221205132124.11585-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
show more ...
|
Revision tags: v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79 |
|
#
3827597a |
| 15-Nov-2022 |
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> |
ALSA: pcm: avoid nused-but-set-variable warning
It will indicate below warning if W=1 was added and CONFIG_SND_DEBUG was not set. This patch adds __maybe_unused and avoid it.
${LINUX}/sound/core/p
ALSA: pcm: avoid nused-but-set-variable warning
It will indicate below warning if W=1 was added and CONFIG_SND_DEBUG was not set. This patch adds __maybe_unused and avoid it.
${LINUX}/sound/core/pcm_native.c: In function 'constrain_mask_params': ${LINUX}/sound/core/pcm_native.c:291:25: error: variable 'old_mask' set but not used [-Werror=unused-but-set-variable] 291 | struct snd_mask old_mask; | ^~~~~~~~ ${LINUX}/sound/core/pcm_native.c: In function 'constrain_interval_params': ${LINUX}/sound/core/pcm_native.c:327:29: error: variable 'old_interval' set but not used [-Werror=unused-but-set-variable] 327 | struct snd_interval old_interval; | ^~~~~~~~~~~~ ${LINUX}/sound/core/pcm_native.c: In function 'constrain_params_by_rules': ${LINUX}/sound/core/pcm_native.c:368:29: error: variable 'old_interval' set but not used [-Werror=unused-but-set-variable] 368 | struct snd_interval old_interval; | ^~~~~~~~~~~~ ${LINUX}/sound/core/pcm_native.c:367:25: error: variable 'old_mask' set but not used [-Werror=unused-but-set-variable] 367 | struct snd_mask old_mask; | ^~~~~~~~ ${LINUX}/sound/core/pcm_native.c: In function 'snd_pcm_hw_params_choose': ${LINUX}/sound/core/pcm_native.c:652:29: error: variable 'old_interval' set but not used [-Werror=unused-but-set-variable] 652 | struct snd_interval old_interval; | ^~~~~~~~~~~~ ${LINUX}/sound/core/pcm_native.c:651:25: error: variable 'old_mask' set but not used [-Werror=unused-but-set-variable] 651 | struct snd_mask old_mask; | ^~~~~~~~ cc1: all warnings being treated as errors make[3]: *** [${LINUX}/scripts/Makefile.build:250: sound/core/pcm_native.o] error 1
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Tested-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/874juzg3kd.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
show more ...
|
Revision tags: v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71 |
|
#
1be2143f |
| 26-Sep-2022 |
Takashi Iwai <tiwai@suse.de> |
ALSA: pcm: Make mmap status read-only
The mmap status record should be read-only. Modifying it from user-space may screw up things unexpectedly, so let's clear the write bits at exposing it.
Note
ALSA: pcm: Make mmap status read-only
The mmap status record should be read-only. Modifying it from user-space may screw up things unexpectedly, so let's clear the write bits at exposing it.
Note that alsa-lib and other known user-space apps access the mmapped status only as read-only, hence this change shouldn't break the existing applications.
Reviewed-by: Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20220926135558.26580-3-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
show more ...
|
#
f0061c18 |
| 26-Sep-2022 |
Takashi Iwai <tiwai@suse.de> |
ALSA: pcm: Avoid reference to status->state
In the PCM core and driver code, there are lots place referring to the current PCM state via runtime->status->state. This patch introduced a local PCM st
ALSA: pcm: Avoid reference to status->state
In the PCM core and driver code, there are lots place referring to the current PCM state via runtime->status->state. This patch introduced a local PCM state in runtime itself and replaces those references with runtime->state. It has improvements in two aspects:
- The reduction of a indirect access leads to more code optimization
- It avoids a possible (unexpected) modification of the state via mmap of the status record
The status->state is updated together with runtime->state, so that user-space can still read the current state via mmap like before, too.
This patch touches only the ALSA core code. The changes in each driver will follow in later patches.
Reviewed-by: Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20220926135558.26580-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
show more ...
|
Revision tags: v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58 |
|
#
96b09709 |
| 28-Jul-2022 |
Takashi Iwai <tiwai@suse.de> |
ALSA: pcm: Use deferred fasync helper
For avoiding the potential deadlock via kill_fasync() call, use the new fasync helpers to defer the invocation from timer API. Note that it's merely a workarou
ALSA: pcm: Use deferred fasync helper
For avoiding the potential deadlock via kill_fasync() call, use the new fasync helpers to defer the invocation from timer API. Note that it's merely a workaround.
Reported-by: syzbot+8285e973a41b5aa68902@syzkaller.appspotmail.com Reported-by: syzbot+669c9abf11a6a011dd09@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/20220728125945.29533-4-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
show more ...
|
Revision tags: v5.15.57, v5.15.56, v5.15.55 |
|
#
4e2b7067 |
| 13-Jul-2022 |
Takashi Iwai <tiwai@suse.de> |
ALSA: pcm: Fix missing return value comments for kernel docs
Each kernel doc comment expects the definition of the return value in a proper format. This patch adds or fixes the missing entries for
ALSA: pcm: Fix missing return value comments for kernel docs
Each kernel doc comment expects the definition of the return value in a proper format. This patch adds or fixes the missing entries for PCM API.
Link: https://lore.kernel.org/r/20220713104759.4365-3-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
show more ...
|
Revision tags: v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33 |
|
#
bc55cfd5 |
| 30-Mar-2022 |
Takashi Iwai <tiwai@suse.de> |
ALSA: pcm: Fix potential AB/BA lock with buffer_mutex and mmap_lock
syzbot caught a potential deadlock between the PCM runtime->buffer_mutex and the mm->mmap_lock. It was brought by the recent fix
ALSA: pcm: Fix potential AB/BA lock with buffer_mutex and mmap_lock
syzbot caught a potential deadlock between the PCM runtime->buffer_mutex and the mm->mmap_lock. It was brought by the recent fix to cover the racy read/write and other ioctls, and in that commit, I overlooked a (hopefully only) corner case that may take the revert lock, namely, the OSS mmap. The OSS mmap operation exceptionally allows to re-configure the parameters inside the OSS mmap syscall, where mm->mmap_mutex is already held. Meanwhile, the copy_from/to_user calls at read/write operations also take the mm->mmap_lock internally, hence it may lead to a AB/BA deadlock.
A similar problem was already seen in the past and we fixed it with a refcount (in commit b248371628aa). The former fix covered only the call paths with OSS read/write and OSS ioctls, while we need to cover the concurrent access via both ALSA and OSS APIs now.
This patch addresses the problem above by replacing the buffer_mutex lock in the read/write operations with a refcount similar as we've used for OSS. The new field, runtime->buffer_accessing, keeps the number of concurrent read/write operations. Unlike the former buffer_mutex protection, this protects only around the copy_from/to_user() calls; the other codes are basically protected by the PCM stream lock. The refcount can be a negative, meaning blocked by the ioctls. If a negative value is seen, the read/write aborts with -EBUSY. In the ioctl side, OTOH, they check this refcount, too, and set to a negative value for blocking unless it's already being accessed.
Reported-by: syzbot+6e5c88838328e99c7e1c@syzkaller.appspotmail.com Fixes: dca947d4d26d ("ALSA: pcm: Fix races among concurrent read/write and buffer changes") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/000000000000381a0d05db622a81@google.com Link: https://lore.kernel.org/r/20220330120903.4738-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
show more ...
|
Revision tags: v5.15.32, v5.15.31 |
|
#
1f68915b |
| 22-Mar-2022 |
Takashi Iwai <tiwai@suse.de> |
ALSA: pcm: Add stream lock during PCM reset ioctl operations
snd_pcm_reset() is a non-atomic operation, and it's allowed to run during the PCM stream running. It implies that the manipulation of hw
ALSA: pcm: Add stream lock during PCM reset ioctl operations
snd_pcm_reset() is a non-atomic operation, and it's allowed to run during the PCM stream running. It implies that the manipulation of hw_ptr and other parameters might be racy.
This patch adds the PCM stream lock at appropriate places in snd_pcm_*_reset() actions for covering that.
Cc: <stable@vger.kernel.org> Reviewed-by: Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20220322171325.4355-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
show more ...
|
#
3c3201f8 |
| 22-Mar-2022 |
Takashi Iwai <tiwai@suse.de> |
ALSA: pcm: Fix races among concurrent prepare and hw_params/hw_free calls
Like the previous fixes to hw_params and hw_free ioctl races, we need to paper over the concurrent prepare ioctl calls again
ALSA: pcm: Fix races among concurrent prepare and hw_params/hw_free calls
Like the previous fixes to hw_params and hw_free ioctl races, we need to paper over the concurrent prepare ioctl calls against hw_params and hw_free, too.
This patch implements the locking with the existing runtime->buffer_mutex for prepare ioctls. Unlike the previous case for snd_pcm_hw_hw_params() and snd_pcm_hw_free(), snd_pcm_prepare() is performed to the linked streams, hence the lock can't be applied simply on the top. For tracking the lock in each linked substream, we modify snd_pcm_action_group() slightly and apply the buffer_mutex for the case stream_lock=false (formerly there was no lock applied) there.
Cc: <stable@vger.kernel.org> Reviewed-by: Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20220322170720.3529-4-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
show more ...
|
#
92ee3c60 |
| 22-Mar-2022 |
Takashi Iwai <tiwai@suse.de> |
ALSA: pcm: Fix races among concurrent hw_params and hw_free calls
Currently we have neither proper check nor protection against the concurrent calls of PCM hw_params and hw_free ioctls, which may re
ALSA: pcm: Fix races among concurrent hw_params and hw_free calls
Currently we have neither proper check nor protection against the concurrent calls of PCM hw_params and hw_free ioctls, which may result in a UAF. Since the existing PCM stream lock can't be used for protecting the whole ioctl operations, we need a new mutex to protect those racy calls.
This patch introduced a new mutex, runtime->buffer_mutex, and applies it to both hw_params and hw_free ioctl code paths. Along with it, the both functions are slightly modified (the mmap_count check is moved into the state-check block) for code simplicity.
Reported-by: Hu Jiahui <kirin.say@gmail.com> Cc: <stable@vger.kernel.org> Reviewed-by: Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20220322170720.3529-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
show more ...
|
Revision tags: v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16 |
|
#
3c75c0ea |
| 19-Jan-2022 |
Takashi Iwai <tiwai@suse.de> |
ASoC: soc-pcm: Fix DPCM lockdep warning due to nested stream locks
The recent change for DPCM locking caused spurious lockdep warnings. Actually the warnings are false-positive, as those are trigger
ASoC: soc-pcm: Fix DPCM lockdep warning due to nested stream locks
The recent change for DPCM locking caused spurious lockdep warnings. Actually the warnings are false-positive, as those are triggered due to the nested stream locks for FE and BE. Since both locks belong to the same lock class, lockdep sees it as if a deadlock.
For fixing this, we need to take PCM stream locks for BE with the nested lock primitives. Since currently snd_pcm_stream_lock*() helper assumes only the top-level single locking, a new helper function snd_pcm_stream_lock_irqsave_nested() is defined for a single-depth nested lock, which is now used in the BE DAI trigger that is always performed inside a FE stream lock.
Fixes: b2ae80663008 ("ASoC: soc-pcm: serialize BE triggers") Reported-and-tested-by: Hans de Goede <hdegoede@redhat.com> Reported-and-tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/73018f3c-9769-72ea-0325-b3f8e2381e30@redhat.com Link: https://lore.kernel.org/alsa-devel/9a0abddd-49e9-872d-2f00-a1697340f786@samsung.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20220119155249.26754-2-tiwai@suse.de Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13 |
|
#
a25684a9 |
| 17-Oct-2021 |
Takashi Iwai <tiwai@suse.de> |
ALSA: memalloc: Support for non-contiguous page allocation
This patch adds the support for allocation of non-contiguous DMA pages in the common memalloc helper. It's another SG-buffer type, but unl
ALSA: memalloc: Support for non-contiguous page allocation
This patch adds the support for allocation of non-contiguous DMA pages in the common memalloc helper. It's another SG-buffer type, but unlike the existing one, this is directional and requires the explicit sync / invalidation of dirty pages on non-coherent architectures.
For this enhancement, the following points are changed: - snd_dma_device stores the DMA direction. - snd_dma_device stores need_sync flag indicating whether the explicit sync is required or not. - A new variant of helper functions, snd_dma_alloc_dir_pages() and *_all() are introduced; the old snd_dma_alloc_pages() and *_all() kept as just wrappers with DMA_BIDIRECTIONAL. - A new helper snd_dma_buffer_sync() is introduced; this gets called in the appropriate places. - A new allocation type, SNDRV_DMA_TYPE_NONCONTIG, is introduced.
When the driver allocates pages with this new type, and it may require the SNDRV_PCM_INFO_EXPLICIT_SYNC flag set to the PCM hardware.info for taking the full control of PCM applptr and hwptr changes (that implies disabling the mmap of control/status data). When the buffer allocation is managed by snd_pcm_set_managed_buffer(), this flag is automatically set depending on the result of dma_need_sync() internally. Otherwise, if the buffer is managed manually, the driver has to set the flag explicitly, too.
The explicit sync between CPU and device for non-coherent memory is performed at the points before and after read/write transfer as well as the applptr/hwptr syncptr ioctl. In the case of mmap mode, user-space is supposed to call the syncptr ioctl with the hwptr flag to update and fetch the status at first; this corresponds to CPU-sync. Then user-space advances the applptr via syncptr ioctl again with applptr flag, and this corresponds to the device sync with flushing.
Other than the DMA direction and the explicit sync, the usage of this new buffer type is almost equivalent with the existing SNDRV_DMA_TYPE_DEV_SG; you can get the page and the address via snd_sgbuf_get_page() and snd_sgbuf_get_addr(), also calculate the continuous pages via snd_sgbuf_get_chunk_size().
For those SG-page handling, the non-contig type shares the same ops with the vmalloc handler. As we do always vmap the SG pages at first, the actual address can be deduced from the vmapped address easily without iterating the SG-list.
Link: https://lore.kernel.org/r/20211017074859.24112-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
show more ...
|
#
c18c4966 |
| 14-Oct-2021 |
Takashi Iwai <tiwai@suse.de> |
ALSA: pcm: Unify snd_pcm_delay() and snd_pcm_hwsync()
Both snd_pcm_delay() and snd_pcm_hwsync() do the almost same thing. The only difference is that the former calculate the delay, so unify them as
ALSA: pcm: Unify snd_pcm_delay() and snd_pcm_hwsync()
Both snd_pcm_delay() and snd_pcm_hwsync() do the almost same thing. The only difference is that the former calculate the delay, so unify them as a code cleanup, and treat NULL delay argument only for hwsync operation.
Also, the patch does a slight code refactoring in snd_pcm_delay(). The initialization of the delay value is done in the caller side now.
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20211014145323.26506-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
show more ...
|
Revision tags: v5.14.12, v5.14.11, v5.14.10 |
|
#
36df2427 |
| 06-Oct-2021 |
Takashi Iwai <tiwai@suse.de> |
ALSA: pcm: Add more disconnection checks at file ops
In the case of hot-disconnection of a PCM device, all file operations except for close should be rejected. This patch adds more sanity checks in
ALSA: pcm: Add more disconnection checks at file ops
In the case of hot-disconnection of a PCM device, all file operations except for close should be rejected. This patch adds more sanity checks in the file operation code paths.
Link: https://lore.kernel.org/r/20211006142214.3089-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
show more ...
|
#
7777744e |
| 30-Mar-2022 |
Takashi Iwai <tiwai@suse.de> |
ALSA: pcm: Fix potential AB/BA lock with buffer_mutex and mmap_lock
commit bc55cfd5718c7c23e5524582e9fa70b4d10f2433 upstream.
syzbot caught a potential deadlock between the PCM runtime->buffer_mute
ALSA: pcm: Fix potential AB/BA lock with buffer_mutex and mmap_lock
commit bc55cfd5718c7c23e5524582e9fa70b4d10f2433 upstream.
syzbot caught a potential deadlock between the PCM runtime->buffer_mutex and the mm->mmap_lock. It was brought by the recent fix to cover the racy read/write and other ioctls, and in that commit, I overlooked a (hopefully only) corner case that may take the revert lock, namely, the OSS mmap. The OSS mmap operation exceptionally allows to re-configure the parameters inside the OSS mmap syscall, where mm->mmap_mutex is already held. Meanwhile, the copy_from/to_user calls at read/write operations also take the mm->mmap_lock internally, hence it may lead to a AB/BA deadlock.
A similar problem was already seen in the past and we fixed it with a refcount (in commit b248371628aa). The former fix covered only the call paths with OSS read/write and OSS ioctls, while we need to cover the concurrent access via both ALSA and OSS APIs now.
This patch addresses the problem above by replacing the buffer_mutex lock in the read/write operations with a refcount similar as we've used for OSS. The new field, runtime->buffer_accessing, keeps the number of concurrent read/write operations. Unlike the former buffer_mutex protection, this protects only around the copy_from/to_user() calls; the other codes are basically protected by the PCM stream lock. The refcount can be a negative, meaning blocked by the ioctls. If a negative value is seen, the read/write aborts with -EBUSY. In the ioctl side, OTOH, they check this refcount, too, and set to a negative value for blocking unless it's already being accessed.
Reported-by: syzbot+6e5c88838328e99c7e1c@syzkaller.appspotmail.com Fixes: dca947d4d26d ("ALSA: pcm: Fix races among concurrent read/write and buffer changes") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/000000000000381a0d05db622a81@google.com Link: https://lore.kernel.org/r/20220330120903.4738-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|