On Fri, 15 Sep 2023 19:30:51 +0200, Takashi Iwai wrote: > > On Fri, 15 Sep 2023 18:04:35 +0200, > Mark Hills wrote: > > > > On Mon, 4 Sep 2023, Takashi Iwai wrote: > > > > > On Mon, 04 Sep 2023 20:10:45 +0200, > > > Ash Holland wrote: > > > > > > I upgraded to Linux 6.5 and found that my MIDI-input application no longer > > > > works, and causes an oops when I launch it. > > [...] > > > > I bisected this to: > > > > > > > > commit f80e6d60d677be1d4dbbcdbf97379b8fbcf97ff0 > > > > Author: Takashi Iwai <tiwai@xxxxxxx> > > > > Date: 2023-05-23 09:53:38 +0200 > > > > > > > > ALSA: seq: Clear padded bytes at expanding events > > > > > > > > There can be a small memory hole that may not be cleared at expanding > > > > an event with the variable length type. Make sure to clear it. > > > > > > > > Reviewed-by: Jaroslav Kysela <perex@xxxxxxxx> > > > > Link: https://lore.kernel.org/r/20230523075358.9672-18-tiwai@xxxxxxx > > > > Signed-off-by: Takashi Iwai <tiwai@xxxxxxx> > > > > > > > > #regzbot introduced: f80e6d60d677be1d4dbbcdbf97379b8fbcf97ff0 > > > > > > > > I guess the problematic part is the `memset(buf + len, 0, newlen - len)`, which > > > > tries to memset a buffer that can be allocated in userspace. > > > > > > Yes, that was a bad change. Could you try the fix below? > > > > I think this problem is recurring -- page_fault_oops triggered via MIDI. > > But with the new fix. > > > > I upgraded from 6.1.0 to 6.5.3 and Reaper now crashes or hangs on startup > > with the trace below in dmesg. > > > > The newer kernel already includes a fix very similar to below, so I think > > an issue remains. > > > > I did not dig deeper than capturing information and finding this related > > thread. > (snip) > > [ 72.601440] BUG: kernel NULL pointer dereference, address: 0000000000000020 > (snip) > > [ 72.601455] RIP: 0010:snd_rawmidi_proc_info_read+0x35/0x220 [snd_rawmidi] > (snip) > > [ 72.601477] Call Trace: > > [ 72.601478] <TASK> > > [ 72.601479] ? __die+0x1b/0x60 > > [ 72.601482] ? page_fault_oops+0x154/0x420 > > [ 72.601485] ? mas_update_gap.part.0+0xac/0x1f0 > > [ 72.601488] ? sched_clock_cpu+0xb/0x190 > > [ 72.601491] ? __smp_call_single_queue+0x2f/0x50 > > [ 72.601493] ? exc_page_fault+0x37a/0x560 > > [ 72.601495] ? seq_open+0x4b/0x70 > > [ 72.601497] ? asm_exc_page_fault+0x22/0x30 > > [ 72.601501] ? snd_rawmidi_proc_info_read+0x35/0x220 [snd_rawmidi] > > [ 72.601505] snd_info_seq_show+0x21/0x40 [snd] > > [ 72.601511] seq_read_iter+0x105/0x4a0 > > [ 72.601514] seq_read+0x9e/0xd0 > > [ 72.601516] proc_reg_read+0x50/0xa0 > > [ 72.601518] vfs_read+0xa4/0x300 > > [ 72.601521] ? __do_sys_newfstatat+0x35/0x60 > > [ 72.601524] ksys_read+0x5a/0xe0 > > [ 72.601526] do_syscall_64+0x38/0x90 > > [ 72.601528] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 > > It must be a completely different bug. It comes from the proc fs > read, not the read over sequencer device itself. Does the change below fix the problem? thanks, Takashi -- 8< -- --- a/sound/core/rawmidi.c +++ b/sound/core/rawmidi.c @@ -1770,7 +1770,7 @@ static void snd_rawmidi_proc_info_read(struct snd_info_entry *entry, if (IS_ENABLED(CONFIG_SND_UMP)) snd_iprintf(buffer, "Type: %s\n", rawmidi_is_ump(rmidi) ? "UMP" : "Legacy"); - if (rmidi->ops->proc_read) + if (rmidi->ops && rmidi->ops->proc_read) rmidi->ops->proc_read(entry, buffer); mutex_lock(&rmidi->open_mutex); if (rmidi->info_flags & SNDRV_RAWMIDI_INFO_OUTPUT) {
