linux-dev/sound/core/seq, branch master

ALSA: seq: Fix data-race at module auto-loading

2022-08-24T05:59:06Z

It's been reported that there is a possible data-race accessing to the global card_requested[] array at ALSA sequencer core, which is used for determining whether to call request_module() for the card or not. This data race itself is almost harmless, as it might end up with one extra request_module() call for the already loaded module at most. But it's still better to fix. This patch addresses the possible data race of card_requested[] and client_requested[] arrays by replacing them with bitmask. It's an atomic operation and can work without locks. Reported-by: Abhishek Shah Cc: Link: https://lore.kernel.org/r/CAEHB24_ay6YzARpA1zgCsE7=H9CSJJzux618E=Ka4h0YdKn=qA@mail.gmail.com Link: https://lore.kernel.org/r/20220823072717.1706-2-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: seq: oss: Fix data-race for max_midi_devs access

2022-08-23T15:00:12Z

ALSA OSS sequencer refers to a global variable max_midi_devs at creating a new port, storing it to its own field. Meanwhile this variable may be changed by other sequencer events at snd_seq_oss_midi_check_exit_port() in parallel, which may cause a data race. OTOH, this data race itself is almost harmless, as the access to the MIDI device is done via get_mdev() and it's protected with a refcount, hence its presence is guaranteed. Though, it's sill better to address the data-race from the code sanity POV, and this patch adds the proper spinlock for the protection. Reported-by: Abhishek Shah Cc: Link: https://lore.kernel.org/r/CAEHB2493pZRXs863w58QWnUTtv3HHfg85aYhLn5HJHCwxqtHQg@mail.gmail.com Link: https://lore.kernel.org/r/20220823072717.1706-1-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: seq: replace ternary operator with max()

2022-05-17T06:49:42Z

Fix the following coccicheck warning: sound/core/seq/seq_ports.c:142:12-14: WARNING opportunity for max() Signed-off-by: Guo Zhengkui Link: https://lore.kernel.org/r/20220517062518.123292-1-guozhengkui@vivo.com Signed-off-by: Takashi Iwai

ALSA: seq: oss: fix typo

2022-03-14T06:51:22Z

Fix typo in "announcement". Reported-by: Joe Perches Signed-off-by: Julia Lawall Link: https://lore.kernel.org/r/20220313085635.102123-1-Julia.Lawall@inria.fr Signed-off-by: Takashi Iwai

ALSA: seq: oss: use kzalloc

2022-03-13T08:09:37Z

Use kzalloc instead of kmalloc + memset. The semantic patch that makes this change is: (https://coccinelle.gitlabpages.inria.fr/website/) // @@ expression res, size, flag; @@ - res = kmalloc(size, flag); + res = kzalloc(size, flag); ... - memset(res, 0, size); // Signed-off-by: Julia Lawall Link: https://lore.kernel.org/r/20220312102705.71413-4-Julia.Lawall@inria.fr Signed-off-by: Takashi Iwai

ALSA: seq: virmidi: Add a drain operation

2022-01-06T15:08:07Z

If a driver does not supply a drain operation for outputs, a default code path will execute msleep(50). Especially for a virtual midi device this severely limmits the throughput. This implementation for the virtual midi driver simply flushes the output workqueue. Signed-off-by: Stefan Sauer Link: https://lore.kernel.org/r/20220106124145.17254-1-st_kost@gmx.de Signed-off-by: Takashi Iwai

ALSA: seq: Set upper limit of processed events

2021-12-07T16:52:28Z

Currently ALSA sequencer core tries to process the queued events as much as possible when they become dispatchable. If applications try to queue too massive events to be processed at the very same timing, the sequencer core would still try to process such all events, either in the interrupt context or via some notifier; in either away, it might be a cause of RCU stall or such problems. As a potential workaround for those problems, this patch adds the upper limit of the amount of events to be processed. The remaining events are processed in the next batch, so they won't be lost. For the time being, it's limited up to 1000 events per queue, which should be high enough for any normal usages. Reported-by: Zqiang Reported-by: syzbot+bb950e68b400ab4f65f8@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/20211102033222.3849-1-qiang.zhang1211@gmail.com Link: https://lore.kernel.org/r/20211207165146.2888-1-tiwai@suse.de Signed-off-by: Takashi Iwai

Merge branch 'for-linus' into for-next

2021-08-09T05:53:22Z

ALSA: seq: Fix racy deletion of subscriber

2021-08-03T11:43:40Z

It turned out that the current implementation of the port subscription is racy. The subscription contains two linked lists, and we have to add to or delete from both lists. Since both connection and disconnection procedures perform the same order for those two lists (i.e. src list, then dest list), when a deletion happens during a connection procedure, the src list may be deleted before the dest list addition completes, and this may lead to a use-after-free or an Oops, even though the access to both lists are protected via mutex. The simple workaround for this race is to change the access order for the disconnection, namely, dest list, then src list. This assures that the connection has been established when disconnecting, and also the concurrent deletion can be avoided. Reported-and-tested-by: folkert Cc: Link: https://lore.kernel.org/r/20210801182754.GP890690@belle.intranet.vanheusden.com Link: https://lore.kernel.org/r/20210803114312.2536-1-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: seq: Fix comments of wrong client number for MIDI Passthrough

2021-07-27T10:53:00Z

MIDI Passthrough sequencer client is assigned always to the fixed number 14, while it's wrongly documented in the comments as if 62, which was an old number that was used during development. Fix all those numbers. Link: https://lore.kernel.org/r/20210727105232.7321-1-tiwai@suse.de Signed-off-by: Takashi Iwai