[PATCH 2/5] echoaudio: Race conditions around "opencount"

Takashi Iwai tiwai at suse.de
Thu Jul 9 13:00:21 CEST 2020


On Wed, 08 Jul 2020 12:18:45 +0200,
Mark Hills wrote:
> 
> Use of atomics does not make these statements robust:
> 
>        atomic_inc(&chip->opencount);
>        if (atomic_read(&chip->opencount) > 1 && chip->rate_set)
>                chip->can_set_rate=0;
> 
> and
> 
>        if (atomic_read(&chip->opencount)) {
>                if (chip->opencount) {
>                        changed = -EAGAIN;
>                } else {
>                        changed = set_digital_mode(chip, dmode);
> 
> It would be necessary to atomically increment or decrement the value
> and use the returned result. And yet we still need to prevent other
> threads making use of "can_set_rate" while we set it.
> 
> However in all but one case the atomic is misleading as they are already
> running with "mode_mutex" held.
> 
> Decisions are made on mode setting are often intrinsically connected
> to "opencount" because some operations are not permitted unless
> there is sole ownership.
> 
> So instead simplify this, and use "mode_mutex" as a lock for all reference
> counting and mode setting.
> 
> Signed-off-by: Mark Hills <mark at xwax.org>

Applied now.  Thanks.


Takashi


More information about the Alsa-devel mailing list