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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx>

Applied now.  Thanks.


Takashi



[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux