[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