On Mon, Jul 10, 2023 at 05:05:06PM +0200, Takashi Iwai wrote:
On Mon, 10 Jul 2023 08:59:56 +0200, Oswald Buddenhagen wrote:
- // We consider this a mixer setting, so use the mixer's lock
- down_write(&emu->card->controls_rwsem);
I really don't want to see the driver touching this lock. It's basically an internal stuff of ALSA core code. And, as already discussed, the controls_rwsem wasn't intended as a lock for the mixer content protection originally. It took over the role partially, but the drivers shouldn't rely on it.
i know that this is technically true, but i think that from a pragmatic point of view it just makes no sense.
if we are pedantic about it, we need to revert my 06405d8ee8c (emu10k1: remove now superfluous mixer locking) and do the opposite change, to add the technically missing locks. that's several tens of irq-safe spinlock operations in this driver alone. which are hundreds of bytes spent entirely pointlessly, because we _know_ that the operation is already locked, because it must be.
so i think the most sensible approach is to just make it official, which is what my 37bb927d5bb (core: update comment on snd_card.controls_rwsem) actually works towards. at least i can't think of a reason not to do that, except for some puristic ideals.
if somebody actually finds a _good_ reason to change this and wants to embark on the mammoth task of proving that everything is still safe afterwards, they can just do so. adjusting this commit for the new reality wouldn't be hard or laborious.
snd_emu1010_update_clock(emu);downgrade_write(&emu->card->controls_rwsem);snd_ctl_build_ioff(&id, emu->ctl_clock_source, 0);snd_ctl_notify(emu->card, SNDRV_CTL_EVENT_MASK_VALUE, &id);up_read(&emu->card->controls_rwsem);Err, too ugly and unnecessary change. snd_ctl_notify() doesn't take the rwsem, and it can be called at any place without fiddling the rwsem. It's snd_ctl_notify_one() that needs the downgrade to read (and maybe we should rename the function to be clearer).
well, that lock is necessary exactly because we (ab-)use the rwsem as the general mixer lock, so we basically need to emulate the ioctl entry path, so a concurrent actual put ioctl doesn't blow up in our face. i actually agree that it's kinda ugly, but the argument remains the same - it just isn't worth doing it differently (we'd have to sprinkle around quite some reg_lock operations instead).
regards