[REGRESSION] rust midir MIDI library causes kernel oops
Hello,
I upgraded to Linux 6.5 and found that my MIDI-input application no longer works, and causes an oops when I launch it.
The application can be found at https://github.com/sersorrel/lp; `cargo run` is enough to cause the oops, though it has many undocumented dependencies, sorry (including a Novation Launchpad Mini Mk3). Once the oops occurs, it seems like it can still send MIDI to the Launchpad (i.e. display things on it), but input from the Launchpad doesn't work. I use NixOS with minimally-altered kernel configuration (blacklisted r8152 module and `amdgpu.reset_method=4` parameter), and was happily using kernel 6.4.9 or so before upgrading to 6.5.
I bisected this to:
commit f80e6d60d677be1d4dbbcdbf97379b8fbcf97ff0 Author: Takashi Iwai tiwai@suse.de 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@perex.cz Link: https://lore.kernel.org/r/20230523075358.9672-18-tiwai@suse.de Signed-off-by: Takashi Iwai tiwai@suse.de
#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.
The oops:
Sep 02 13:40:35 kernel: BUG: unable to handle page fault for address: 000055efb39dffb5 Sep 02 13:40:35 kernel: #PF: supervisor write access in kernel mode Sep 02 13:40:36 kernel: #PF: error_code(0x0003) - permissions violation Sep 02 13:40:36 kernel: PGD 1aff38067 P4D 1aff38067 PUD 1aff37067 PMD 1a975f067 PTE 80000001b315b067 Sep 02 13:40:36 kernel: Oops: 0003 [#1] PREEMPT SMP NOPTI Sep 02 13:40:36 kernel: CPU: 3 PID: 4441 Comm: midir ALSA inpu Not tainted 6.5.0 #1-NixOS Sep 02 13:40:36 kernel: Hardware name: To Be Filled By O.E.M. X570S PG Riptide/X570S PG Riptide, BIOS P5.01 01/17/2023 Sep 02 13:40:36 kernel: RIP: 0010:memset+0xf/0x20 Sep 02 13:40:36 kernel: Code: 44 88 1f e9 83 69 01 00 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 49 89 f9 40 88 f0 48 89 d1 <f3> aa 4c 89 c8 e9 57 69 01 00 0f 1f 80 00 00 00 00 90 90 90 90 90 Sep 02 13:40:36 kernel: RSP: 0018:ffffa699c3607dd0 EFLAGS: 00010202 Sep 02 13:40:36 kernel: RAX: 0000000000000000 RBX: 0000000000000009 RCX: 0000000000000013 Sep 02 13:40:36 kernel: RDX: 0000000000000013 RSI: 0000000000000000 RDI: 000055efb39dffb5 Sep 02 13:40:36 kernel: RBP: 000000000000001c R08: 0000000000000009 R09: 000055efb39dffb5 Sep 02 13:40:36 kernel: R10: ffffa699c3607e68 R11: 0000000000000000 R12: 000055efb39dffac Sep 02 13:40:36 kernel: R13: 000055efb39dff00 R14: ffff9d2a2bd671e0 R15: ffff9d2aa2b36d00 Sep 02 13:40:36 kernel: FS: 00007fe33e2d86c0(0000) GS:ffff9d38feac0000(0000) knlGS:0000000000000000 Sep 02 13:40:36 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Sep 02 13:40:36 kernel: CR2: 000055efb39dffb5 CR3: 000000018e25c000 CR4: 0000000000750ee0 Sep 02 13:40:36 kernel: PKRU: 55555554 Sep 02 13:40:36 kernel: Call Trace: Sep 02 13:40:36 kernel: <TASK> Sep 02 13:40:36 kernel: ? __die+0x23/0x70 Sep 02 13:40:36 kernel: ? page_fault_oops+0x17d/0x4b0 Sep 02 13:40:36 kernel: ? exc_page_fault+0x6d/0x150 Sep 02 13:40:36 kernel: ? asm_exc_page_fault+0x26/0x30 Sep 02 13:40:36 kernel: ? memset+0xf/0x20 Sep 02 13:40:36 kernel: snd_seq_expand_var_event+0x6b/0xa0 [snd_seq] Sep 02 13:40:36 kernel: snd_seq_read+0x1b5/0x270 [snd_seq] Sep 02 13:40:36 kernel: vfs_read+0xaf/0x350 Sep 02 13:40:36 kernel: ? srso_alias_return_thunk+0x5/0x7f Sep 02 13:40:36 kernel: ? __fget_light+0x9d/0x100 Sep 02 13:40:36 kernel: ksys_read+0xbb/0xf0 Sep 02 13:40:36 kernel: do_syscall_64+0x3e/0x90 Sep 02 13:40:36 kernel: entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Sep 02 13:40:36 kernel: RIP: 0033:0x7fe33ebf074c Sep 02 13:40:36 kernel: Code: ec 28 48 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 59 bb f8 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 34 44 89 c7 48 89 44 24 08 e8 af bb f8 ff 48 Sep 02 13:40:36 kernel: RSP: 002b:00007fe33e2d7a70 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 Sep 02 13:40:36 kernel: RAX: ffffffffffffffda RBX: 000055efb39d9440 RCX: 00007fe33ebf074c Sep 02 13:40:36 kernel: RDX: 00000000000036b0 RSI: 000055efb39dff90 RDI: 0000000000000005 Sep 02 13:40:36 kernel: RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000000020 Sep 02 13:40:36 kernel: R10: 2b7b3401fd8f65e7 R11: 0000000000000246 R12: 00007fe33e2d7d01 Sep 02 13:40:36 kernel: R13: 00007fe33e2d7b80 R14: 00007fe32c000cd0 R15: 0000000000000001 Sep 02 13:40:36 kernel: </TASK> Sep 02 13:40:36 kernel: Modules linked in: snd_hrtimer snd_seq_midi snd_seq_dummy snd_seq_midi_event snd_seq xt_MASQUERADE xt_mark nft_chain_nat nf_nat af_packet rfkill amdgpu snd_hda_codec_realtek snd_hda_codec_generic nls_iso8859_1 nls_cp437 ledtrig_audio vfat fat amdxcp snd_hda_codec_hdmi iommu_v2 drm_buddy gpu_sc> Sep 02 13:40:36 kernel: xt_tcpudp nft_compat nf_tables sch_fq_codel nfnetlink uinput i2c_piix4 i2c_dev ctr atkbd libps2 serio vivaldi_fmap loop tun tap macvlan bridge stp llc kvm_amd ccp kvm drm irqbypass fuse deflate efi_pstore backlight configfs efivarfs dmi_sysfs ip_tables x_tables autofs4 dm_crypt cbc encrypted_> Sep 02 13:40:36 kernel: CR2: 000055efb39dffb5 Sep 02 13:40:36 kernel: ---[ end trace 0000000000000000 ]---
thanks, Ash
On Mon, 04 Sep 2023 20:10:45 +0200, Ash Holland wrote:
Hello,
I upgraded to Linux 6.5 and found that my MIDI-input application no longer works, and causes an oops when I launch it.
The application can be found at https://github.com/sersorrel/lp; `cargo run` is enough to cause the oops, though it has many undocumented dependencies, sorry (including a Novation Launchpad Mini Mk3). Once the oops occurs, it seems like it can still send MIDI to the Launchpad (i.e. display things on it), but input from the Launchpad doesn't work. I use NixOS with minimally-altered kernel configuration (blacklisted r8152 module and `amdgpu.reset_method=4` parameter), and was happily using kernel 6.4.9 or so before upgrading to 6.5.
I bisected this to:
commit f80e6d60d677be1d4dbbcdbf97379b8fbcf97ff0 Author: Takashi Iwai tiwai@suse.de 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@perex.cz> Link: https://lore.kernel.org/r/20230523075358.9672-18-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>#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?
thanks,
Takashi
-- 8< -- --- a/sound/core/seq/seq_memory.c +++ b/sound/core/seq/seq_memory.c @@ -187,8 +187,12 @@ int snd_seq_expand_var_event(const struct snd_seq_event *event, int count, char err = expand_var_event(event, 0, len, buf, in_kernel); if (err < 0) return err; - if (len != newlen) - memset(buf + len, 0, newlen - len); + if (len != newlen) { + if (in_kernel) + memset(buf + len, 0, newlen - len); + else + clear_user((__force void __user *)buf + len, newlen - len); + } return newlen; } EXPORT_SYMBOL(snd_seq_expand_var_event);
On 04/09/2023 22:49, Takashi Iwai wrote:
Yes, that was a bad change. Could you try the fix below?
thanks,
Takashi
-- 8< -- --- a/sound/core/seq/seq_memory.c +++ b/sound/core/seq/seq_memory.c @@ -187,8 +187,12 @@ int snd_seq_expand_var_event(const struct snd_seq_event *event, int count, char err = expand_var_event(event, 0, len, buf, in_kernel); if (err < 0) return err;
- if (len != newlen)
memset(buf + len, 0, newlen - len);
- if (len != newlen) {
if (in_kernel)memset(buf + len, 0, newlen - len);elseclear_user((__force void __user *)buf + len, newlen - len);- } return newlen; } EXPORT_SYMBOL(snd_seq_expand_var_event);
That patch seems to work fine! Many thanks.
On Tue, 05 Sep 2023 01:00:11 +0200, Ash Holland wrote:
On 04/09/2023 22:49, Takashi Iwai wrote:
Yes, that was a bad change. Could you try the fix below?
thanks,
Takashi
-- 8< -- --- a/sound/core/seq/seq_memory.c +++ b/sound/core/seq/seq_memory.c @@ -187,8 +187,12 @@ int snd_seq_expand_var_event(const struct snd_seq_event *event, int count, char err = expand_var_event(event, 0, len, buf, in_kernel); if (err < 0) return err;
- if (len != newlen)
memset(buf + len, 0, newlen - len);
- if (len != newlen) {
if (in_kernel)memset(buf + len, 0, newlen - len);elseclear_user((__force void __user *)buf + len, newlen - len);- } return newlen; } EXPORT_SYMBOL(snd_seq_expand_var_event);
That patch seems to work fine! Many thanks.
Thanks for quick testing! I'll submit the proper patch later.
Takashi
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@suse.de 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@perex.cz> Link: https://lore.kernel.org/r/20230523075358.9672-18-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>#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.
Thanks
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@suse.de 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@perex.cz> Link: https://lore.kernel.org/r/20230523075358.9672-18-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>#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.
Takashi
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@suse.de 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@perex.cz> Link: https://lore.kernel.org/r/20230523075358.9672-18-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>#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) {
On Fri, 15 Sep 2023, Takashi Iwai wrote:
On Fri, 15 Sep 2023 19:30:51 +0200, Takashi Iwai wrote:
On Fri, 15 Sep 2023 18:04:35 +0200, Mark Hills wrote:
[...]
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?
It does! At least it passes my initial test. Reaper starts up now.
-- 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) {
On Fri, 15 Sep 2023 20:20:12 +0200, Mark Hills wrote:
On Fri, 15 Sep 2023, Takashi Iwai wrote:
On Fri, 15 Sep 2023 19:30:51 +0200, Takashi Iwai wrote:
On Fri, 15 Sep 2023 18:04:35 +0200, Mark Hills wrote:
[...]
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?
It does! At least it passes my initial test. Reaper starts up now.
Good to hear. I'll submit the proper fix patch.
thanks,
Takashi
participants (3)
-
Ash Holland -
Mark Hills -
Takashi Iwai