linux-kernel - Re: [PATCH] ALSA: usb-audio: Refcount multiple accesses on the single clock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 5 Sep 2022 11:58:50 +0200
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Takashi Iwai <tiwai@...e.de>
Cc:     alsa-devel@...a-project.org, 89q1r14hd@...ay.firefox.com,
        linux-kernel@...r.kernel.org, Wim Taymans <wtaymans@...hat.com>
Subject: Re: [PATCH] ALSA: usb-audio: Refcount multiple accesses on the
 single clock

Hi Takashi,

On Mon, May 16, 2022 at 12:48:07PM +0200, Takashi Iwai wrote:
> When a clock source is connected to multiple nodes / endpoints, the
> current USB-audio driver tries to set up at each time one of them is
> configured.  Although it reads the current rate and updates only if it
> differs, some devices seem unhappy with this behavior and spew the
> errors when reading/updating the rate unnecessarily.
> 
> This patch tries to reduce the redundant clock setup by introducing a
> refcount for each clock source.  When the stream is actually running,
> a clock rate is "locked", and it bypasses the clock and/or refuse to
> change any longer.

This breaks things on 5.19+. Specifically, it causes pipewire and
pulseaudio to be stuck using 44.1khz rather than 48.0khz (or anything
else). The reason is that initially devices are started at 44.1khz, and
then the list of supported sample rates is read, and finally the best
one is chosen. With this commit, the returned list of sample rates is
locked at 44.1khz, which means pulseaudio and pipewire can't change it
to 48.0khz (or anything else).

This headscratcher is being tracked over at:
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2620
where I triaged it to this commit.

Can we revert this for the time being and backport the revert to stable?
Or might you have some other fix idea in mind?

Thanks,
Jason