Re: next-0519 on thinkpad x60: sound related? window manager crash
Excerpts from Takashi Iwai's message of June 9, 2020 11:12 am:
On Tue, 09 Jun 2020 13:47:33 +0200, Christoph Hellwig wrote:
Alex, can you try this patch?
Also could you check whether just papering over the memset() call alone avoids the crash like below? For PulseAudio and dmix/dsnoop, it's the only code path that accesses the vmapped buffer, I believe.
If this works more or less, I'll cook a more comprehensive fix.
thanks,
Takashi
--- a/sound/core/pcm_native.c +++ b/sound/core/pcm_native.c @@ -754,9 +754,11 @@ static int snd_pcm_hw_params(struct snd_pcm_substream *substream, while (runtime->boundary * 2 <= LONG_MAX - runtime->buffer_size) runtime->boundary *= 2;
+#if 0 /* clear the buffer for avoiding possible kernel info leaks */ if (runtime->dma_area && !substream->ops->copy_user) memset(runtime->dma_area, 0, runtime->dma_bytes); +#endif
snd_pcm_timer_resolution_change(substream); snd_pcm_set_state(substream, SNDRV_PCM_STATE_SETUP);
Sorry, this patch doesn't work for me with SME off using abfbb29297c2. David's newest submitted patch works for me, which I already replied to separately.
Thanks, Alex.
On Thu, 11 Jun 2020 16:51:55 +0200, Alex Xu (Hello71) wrote:
Excerpts from Takashi Iwai's message of June 9, 2020 11:12 am:
On Tue, 09 Jun 2020 13:47:33 +0200, Christoph Hellwig wrote:
Alex, can you try this patch?
Also could you check whether just papering over the memset() call alone avoids the crash like below? For PulseAudio and dmix/dsnoop, it's the only code path that accesses the vmapped buffer, I believe.
If this works more or less, I'll cook a more comprehensive fix.
thanks,
Takashi
--- a/sound/core/pcm_native.c +++ b/sound/core/pcm_native.c @@ -754,9 +754,11 @@ static int snd_pcm_hw_params(struct snd_pcm_substream *substream, while (runtime->boundary * 2 <= LONG_MAX - runtime->buffer_size) runtime->boundary *= 2;
+#if 0 /* clear the buffer for avoiding possible kernel info leaks */ if (runtime->dma_area && !substream->ops->copy_user) memset(runtime->dma_area, 0, runtime->dma_bytes); +#endif
snd_pcm_timer_resolution_change(substream); snd_pcm_set_state(substream, SNDRV_PCM_STATE_SETUP);
Sorry, this patch doesn't work for me with SME off using abfbb29297c2. David's newest submitted patch works for me, which I already replied to separately.
Thanks, so something still missing in the mmap handling, I guess.
I've worked on two different branches for potential fixes of your problems. Could you test topic/dma-fix and topic/dma-fix2 branches? git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git Just pull one of them onto Linus' git HEAD.
I guess we'll go with David's new patch, but still it's interesting whether my changes do anything good actually.
Takashi
Excerpts from Takashi Iwai's message of June 11, 2020 1:11 pm:
Thanks, so something still missing in the mmap handling, I guess.
I've worked on two different branches for potential fixes of your problems. Could you test topic/dma-fix and topic/dma-fix2 branches? git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git Just pull one of them onto Linus' git HEAD.
I guess we'll go with David's new patch, but still it's interesting whether my changes do anything good actually.
Takashi
On torvalds 623f6dc593, topic/dma-fix causes sound to be output as alternating half-second bursts of noise and a few seconds of silence. topic/dma-fix2 appears to work properly.
Thanks, Alex.
On Sat, 13 Jun 2020 18:25:22 +0200, Alex Xu (Hello71) wrote:
Excerpts from Takashi Iwai's message of June 11, 2020 1:11 pm:
Thanks, so something still missing in the mmap handling, I guess.
I've worked on two different branches for potential fixes of your problems. Could you test topic/dma-fix and topic/dma-fix2 branches? git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git Just pull one of them onto Linus' git HEAD.
I guess we'll go with David's new patch, but still it's interesting whether my changes do anything good actually.
Takashi
On torvalds 623f6dc593, topic/dma-fix causes sound to be output as alternating half-second bursts of noise and a few seconds of silence. topic/dma-fix2 appears to work properly.
OK, thanks for the feedback! Just to make sure, you're using PulseAudio, right? If so, it was still something wrong about mmap, and the secondary method (the fallback to the continuous page) looks like a safer approach in the end.
I suppose that David's fix will be merged sooner or later. Meanwhile I'll work on the change in the sound driver side to make things a bit more robust. They don't conflict and both good applicable.
thanks,
Takashi
Excerpts from Takashi Iwai's message of June 14, 2020 5:54 am:
On Sat, 13 Jun 2020 18:25:22 +0200, Alex Xu (Hello71) wrote:
Excerpts from Takashi Iwai's message of June 11, 2020 1:11 pm:
Thanks, so something still missing in the mmap handling, I guess.
I've worked on two different branches for potential fixes of your problems. Could you test topic/dma-fix and topic/dma-fix2 branches? git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git Just pull one of them onto Linus' git HEAD.
I guess we'll go with David's new patch, but still it's interesting whether my changes do anything good actually.
Takashi
On torvalds 623f6dc593, topic/dma-fix causes sound to be output as alternating half-second bursts of noise and a few seconds of silence. topic/dma-fix2 appears to work properly.
OK, thanks for the feedback! Just to make sure, you're using PulseAudio, right? If so, it was still something wrong about mmap, and the secondary method (the fallback to the continuous page) looks like a safer approach in the end.
I suppose that David's fix will be merged sooner or later. Meanwhile I'll work on the change in the sound driver side to make things a bit more robust. They don't conflict and both good applicable.
thanks,
Takashi
Ah, no, I think that wasn't clear. I use ALSA directly with mostly default configuration, except an asym sets separate default playback and record devices.
asound.conf:
defaults.pcm.card 1 defaults.ctl.card 1
pcm.!default { type asym playback.pcm { type plug slave.pcm "dmix" } capture.pcm { type plug slave.pcm { type dsnoop ipc_key 6793 slave.pcm "hw:U0x46d0x81d" } } }
I think I wasn't able to set defaults.pcm.dmix.card and defaults.pcm.dsnoop.card for some reason, not sure why. I can try that, but I don't think it will affect this mmap issue.
Thanks, Alex.
On Sun, 14 Jun 2020 14:07:48 +0200, Alex Xu (Hello71) wrote:
Excerpts from Takashi Iwai's message of June 14, 2020 5:54 am:
On Sat, 13 Jun 2020 18:25:22 +0200, Alex Xu (Hello71) wrote:
Excerpts from Takashi Iwai's message of June 11, 2020 1:11 pm:
Thanks, so something still missing in the mmap handling, I guess.
I've worked on two different branches for potential fixes of your problems. Could you test topic/dma-fix and topic/dma-fix2 branches? git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git Just pull one of them onto Linus' git HEAD.
I guess we'll go with David's new patch, but still it's interesting whether my changes do anything good actually.
Takashi
On torvalds 623f6dc593, topic/dma-fix causes sound to be output as alternating half-second bursts of noise and a few seconds of silence. topic/dma-fix2 appears to work properly.
OK, thanks for the feedback! Just to make sure, you're using PulseAudio, right? If so, it was still something wrong about mmap, and the secondary method (the fallback to the continuous page) looks like a safer approach in the end.
I suppose that David's fix will be merged sooner or later. Meanwhile I'll work on the change in the sound driver side to make things a bit more robust. They don't conflict and both good applicable.
thanks,
Takashi
Ah, no, I think that wasn't clear. I use ALSA directly with mostly default configuration, except an asym sets separate default playback and record devices.
asound.conf:
defaults.pcm.card 1 defaults.ctl.card 1
pcm.!default { type asym playback.pcm { type plug slave.pcm "dmix" } capture.pcm { type plug slave.pcm { type dsnoop ipc_key 6793 slave.pcm "hw:U0x46d0x81d" } } }
I think I wasn't able to set defaults.pcm.dmix.card and defaults.pcm.dsnoop.card for some reason, not sure why. I can try that, but I don't think it will affect this mmap issue.
The dmix is an implementation exclusively with mmap, so yes, it's still about the mmap. This also shows the same problem.
thanks,
Takashi
participants (2)
-
Alex Xu (Hello71) -
Takashi Iwai