Calculated for data transfer, the local variable appl_ptr is reused,
changed and written back later, though the lock was not held during
the transfer earlier. Admitted, destiny of the lock is not obvious
at all, but this looks much like a race condition candidate, so make
sure to have some original appl_ptr value to work on.

Two occurences.

Signed-off-by: Oskar Schirmer <os...@scara.com>
---
 sound/core/pcm_lib.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c
index 6e03b46..47e836a 100644
--- a/sound/core/pcm_lib.c
+++ b/sound/core/pcm_lib.c
@@ -2051,6 +2051,7 @@ static snd_pcm_sframes_t snd_pcm_lib_write1(struct 
snd_pcm_substream *substream,
                default:
                        break;
                }
+               appl_ptr = runtime->control->appl_ptr;
                appl_ptr += frames;
                if (appl_ptr >= runtime->boundary)
                        appl_ptr -= runtime->boundary;
@@ -2283,6 +2284,7 @@ static snd_pcm_sframes_t snd_pcm_lib_read1(struct 
snd_pcm_substream *substream,
                default:
                        break;
                }
+               appl_ptr = runtime->control->appl_ptr;
                appl_ptr += frames;
                if (appl_ptr >= runtime->boundary)
                        appl_ptr -= runtime->boundary;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to