snd_seq_client_use_ptr() is supposed to return the snd_seq_client
object for the given client ID, and it tries to handle the module
auto-loading when no matching object is found. Although the module
handling is performed only conditionally with "!in_interrupt()", this
condition may be fragile, e.g. when the code is called from the ALSA
timer callback where the spinlock is temporarily disabled while the
irq is disabled. Then his doesn't fit well and spews the error about
sleep from invalid context, as complained recently by syzbot.
Also, in general, handling the module-loading at each time if no
matching object is found is really an overkill. It can be still
useful when performed at the top-level ioctl or proc reads, but it
shouldn't be done at event delivery at all.
For addressing the issues above, this patch disables the module
handling in snd_seq_client_use_ptr() in normal cases like event
deliveries, but allow only in limited and safe situations.
A new function client_load_and_use_ptr() is used for the cases where
the module loading can be done safely, instead.
Reported-by: syzbot+4cb9fad083898f54c517@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/67c272e5.050a0220.dc10f.0159.GAE@google.com
Cc: <stable@vger.kernel.org>
Link: https://patch.msgid.link/20250301114530.8975-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When a destination client is a user client in the legacy MIDI mode and
it sets the no-UMP-conversion flag, currently the all UMP events are
still passed as-is. But this may confuse the user-space, because the
event packet size is different from the legacy mode.
Since we cannot handle UMP events in user clients unless it's running
in the UMP client mode, we should filter out those events instead of
accepting blindly. This patch addresses it by slightly adjusting the
conditions for UMP event handling at the event delivery time.
Fixes: 329ffe11a0 ("ALSA: seq: Allow suppressing UMP conversions")
Link: https://lore.kernel.org/b77a2cd6-7b59-4eb0-a8db-22d507d3af5f@gmail.com
Link: https://patch.msgid.link/20250217170034.21930-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
So far we notify the sequencer client and port changes upon UMP FB
changes, but those aren't really corresponding to the UMP updates.
e.g. when a FB info gets updated, it's not notified but done only when
some of sequencer port attribute is changed. This is no ideal
behavior.
This patch adds the two new sequencer event types for notifying the
UMP EP and FB changes via the announce port. The new event takes
snd_seq_ev_ump_notify type data, which is compatible with
snd_seq_addr (where the port number is replaced with the block
number).
The events are sent when the EP and FB info gets updated explicitly
via ioctl, or the backend UMP receives the corresponding UMP
messages.
The sequencer protocol version is bumped to 1.0.5 along with it.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20250110155943.31578-9-tiwai@suse.de
Currently the system notification helper assumes only the non-atomic
delivery. For allowing an event delivery in non-atomic context, add
the atomic flag to the helper function.
This is a preliminary change for the support of UMP EP/FB
notification.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20250110155943.31578-8-tiwai@suse.de
CONFIG_SND_SEQ_UMP_CLIENT is a Kconfig for a sequencer client
corresponding to the UMP rawmidi, while we have another major knob
CONFIG_SND_SEQ_UMP that specifies whether the sequencer core supports
UMP packets or not. Strictly speaking both of them are independent,
but practically seen, it makes no sense to enable
CONFIG_SND_SEQ_UMP_CLIENT without UMP support itself.
This patch makes such an implicit dependency clearer. Now
CONFIG_SND_SEQ_UMP_CLIENT depends on both CONFIG_SND_UMP and
CONFIG_SND_SEQ_UMP. Meanwhile, CONFIG_SND_SEQ_UMP is enabled as
default when CONFIG_SND_UMP is set.
Fixes: 81fd444aa3 ("ALSA: seq: Bind UMP device")
Link: https://patch.msgid.link/20250101125548.25961-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent bug report spotted on the old OSS sequencer code that tries
to combine incoming SysEx messages to a single sequencer event. This
is good, per se, but it has more demerits:
- The sysex message delivery is delayed until the very last event
- The use of internal buffer forced the serialization
The recent fix in commit 0179488ca9 ("ALSA: seq: oss: Fix races at
processing SysEx messages") addressed the latter, but a better fix is
to handle the sysex messages immediately, i.e. just send each incoming
fragmented sysex message as is. And this patch implements that.
This resulted in a significant cleanup as well.
Note that the only caller of snd_seq_oss_synth_sysex() is
snd_seq_oss_process_event(), and all its callers dispatch the event
immediately, so we can just put the passed buffer pointer to the event
record to be handled.
Reported-and-tested-by: Kun Hu <huk23@m.fudan.edu.cn>
Link: https://lore.kernel.org/2B7E93E4-B13A-4AE4-8E87-306A8EE9BBB7@m.fudan.edu.cn
Link: https://patch.msgid.link/20241231115523.15796-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The notification via system announce port isn't a lightweight task,
hence it'd be better to skip if there is no subscription is done for
the announce port. Implement a simple counter for checking that by
hooking the subscribe and unsubscribe callbacks.
Link: https://patch.msgid.link/20241128074801.32253-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
It was supposed to be notified when a sequencer client info and a port
info has changed (via SNDRV_SEQ_EVENT_CLIENT_CHANGE and
SNDRV_SEQ_EVENT_PORT_CHANGE event, respectively), and there are
already helper functions. But those aren't really sent from the
driver so far, except for the recent support of UMP, simply due to the
lack of implementations.
This patch adds the missing notifications at updating the client and
the port info. The formerly added notification for UMP is dropped
because it's handled now in the port info side.
Reported-by: Mark Lentczner <mark@glyphic.com>
Link: https://lore.kernel.org/CAPnksqRok7xGa4bxq9WWimVV=28-7_j628OmrWLS=S0=hzaTHQ@mail.gmail.com
Link: https://patch.msgid.link/20241128074734.32165-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
update_port_infos() is called when a UMP FB Info update notification
is received, and this function is supposed to update the attributes of
the corresponding sequencer port. However, the function had a few
issues and it brought to the incorrect states. Namely:
- It tried to get a wrong sequencer info for the update without
correcting the port number with the group-offset 1
- The loop exited immediately when a sequencer port isn't present;
this ended up with the truncation if a sequencer port in the middle
goes away
This patch addresses those bugs.
Fixes: 4a16a3af05 ("ALSA: seq: ump: Handle FB info update")
Link: https://patch.msgid.link/20241128170423.23351-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
no_llseek had been defined to NULL two years ago, in commit 868941b144
("fs: remove no_llseek")
To quote that commit,
At -rc1 we'll need do a mechanical removal of no_llseek -
git grep -l -w no_llseek | grep -v porting.rst | while read i; do
sed -i '/\<no_llseek\>/d' $i
done
would do it.
Unfortunately, that hadn't been done. Linus, could you do that now, so
that we could finally put that thing to rest? All instances are of the
form
.llseek = no_llseek,
so it's obviously safe.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
All callers of get_event_dest_clienter() pass 0 to the filter
argument, and it means that the check there is utterly redundant.
Drop the superfluous filter argument and its check as a code cleanup.
Link: https://patch.msgid.link/20240819084757.11902-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent extension added a new ALSA sequencer port info flag bit
SNDRV_SEQ_PORT_FLG_IS_MIDI1, but it's not reported back when
inquired. Fix it to report properly.
Fixes: 0079c9d1e5 ("ALSA: ump: Handle MIDI 1.0 Function Block in MIDI 2.0 protocol")
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20240807092303.1935-7-tiwai@suse.de
When a sequencer port assigned to a UMP Group that is specific to MIDI
1.0 among MIDI 2.0 client, mark it explicitly in the proc output, so
that user can see it easily. This is an exceptional case where the
message isn't converted to MIDI 1.0 even if the client is running in
MIDI 2.0 mode.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20240807092303.1935-6-tiwai@suse.de
The UMP v1.1 spec says in the section 6.2.1:
"If a UMP Endpoint declares MIDI 2.0 Protocol but a Function Block
represents a MIDI 1.0 connection, then may optionally be used for
messages to/from that Function Block."
It implies that the driver can (and should) keep MIDI 1.0 CVM
exceptionally for those FBs even if UMP Endpoint is running in MIDI
2.0 protocol, and the current driver lacks of it.
This patch extends the sequencer port info to indicate a MIDI 1.0
port, and tries to send/receive MIDI 1.0 CVM as is when this port is
the source or sink. The sequencer port flag is set by the driver at
parsing FBs and GTBs although application can set it to its own
user-space clients, too.
Link: https://patch.msgid.link/20240806070024.14301-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
RPN with 127:127 is treated as a Null RPN, just to reset the
parameters, and it's not translated to MIDI2. Although the current
code can work as is in most cases, better to implement the RPN reset
explicitly for Null message.
Link: https://patch.msgid.link/20240731130528.12600-6-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
