mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
synced 2026-11-10 20:48:12 +00:00
ALSA: seq: Use RCU for the virmidi file list
Each virmidi device keeps a list of its opened input files (filelist) protected by both an rwlock (filelist_lock) and a rw_semaphore (filelist_sem). snd_virmidi_dev_receive_event() walks the list on the sequencer event input path -- read_lock() when the event is delivered in atomic context, down_read() otherwise -- decoding each incoming event into the file's rawmidi buffer. The writers (input open/close) take both locks to add/remove entries. This is another typical dual-lock read-mostly pattern as the port subscriber list: files are opened/closed rarely while the receive callback runs per event. Let's convert the traversal to RCU and drop the rwlock; the existing filelist_sem keeps serializing the writers. The atomic input path now runs lock-free under rcu_read_lock(), and both readers share a single list_for_each_entry_rcu() (valid under the rwsem via lockdep_is_held()). The writers switch to list_add_tail_rcu() / list_del_rcu(). snd_virmidi_input_close() freed the entry (parser and struct) immediately after list_del. A concurrent lockless reader in the atomic path may still be dereferencing it, so the close path now waits for an RCU grace period after list_del_rcu() before freeing; synchronize_rcu() is used rather than kfree_rcu() because the parser must also be released after the grace period, not just the struct. Non-atomic readers are already excluded by the down_write, so only the atomic RCU readers need the grace period. Dropping write_lock_irq() from the writers is safe: no writer runs in atomic/IRQ context, and the sole atomic reader now uses RCU, which is IRQ-safe. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260810133711.42483-5-tiwai@suse.de
This commit is contained in:
parent
7a287e4615
commit
7ffa5d2462
2 changed files with 11 additions and 9 deletions
Loading…
Add table
Add a link
Reference in a new issue