All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: David Rientjes <rientjes@google.com>
Cc: alsa-devel@alsa-project.org, x86@kernel.org, tiwai@suse.com,
	linux-kernel@vger.kernel.org,
	"Alex Xu \(Hello71\)" <alex_y_xu@yahoo.ca>,
	hch@infradead.org, mingo@redhat.com, bp@alien8.de,
	Pavel Machek <pavel@ucw.cz>,
	hpa@zytor.com, tglx@linutronix.de, Christoph Hellwig <hch@lst.de>
Subject: Re: next-0519 on thinkpad x60: sound related? window manager crash
Date: Tue, 9 Jun 2020 07:43:06 +0200	[thread overview]
Message-ID: <20200609054306.GA9606@lst.de> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2006081928070.148886@chino.kir.corp.google.com>

On Mon, Jun 08, 2020 at 07:31:47PM -0700, David Rientjes wrote:
> On Mon, 8 Jun 2020, Alex Xu (Hello71) wrote:
> 
> > Excerpts from Christoph Hellwig's message of June 8, 2020 2:19 am:
> > > Can you do a listing using gdb where this happens?
> > > 
> > > gdb vmlinux
> > > 
> > > l *(snd_pcm_hw_params+0x3f3)
> > > 
> > > ?
> > > 
> > 
> > (gdb) l *(snd_pcm_hw_params+0x3f3)
> > 0xffffffff817efc85 is in snd_pcm_hw_params (.../linux/sound/core/pcm_native.c:749).
> > 744             while (runtime->boundary * 2 <= LONG_MAX - runtime->buffer_size)
> > 745                     runtime->boundary *= 2;
> > 746
> > 747             /* clear the buffer for avoiding possible kernel info leaks */
> > 748             if (runtime->dma_area && !substream->ops->copy_user)
> > 749                     memset(runtime->dma_area, 0, runtime->dma_bytes);
> > 750
> > 751             snd_pcm_timer_resolution_change(substream);
> > 752             snd_pcm_set_state(substream, SNDRV_PCM_STATE_SETUP);
> > 753
> > 
> 
> Working theory is that CONFIG_DMA_NONCOHERENT_MMAP getting set is causing 
> the error_code in the page fault path.  Debugging with Alex off-thread we 
> found that dma_{alloc,free}_from_pool() are not getting called from the 
> new code in dma_direct_{alloc,free}_pages() and he has not enabled 
> mem_encrypt.

While DMA_COHERENT_POOL absolutely should not select DMA_NONCOHERENT_MMAP
(and you should send your patch either way), I don't think it is going
to make a difference here, as DMA_NONCOHERENT_MMAP just means we
allows mmaps even for non-coherent devices, and we do not support
non-coherent devices on x86.

From the disassembly it seems like a vmalloc allocation is NULL, which
seems really weird as this patch shouldn't make a difference for them,
and I also only see a single places that allocates the field, and that
checks for an allocation failure.  But the sound code is a little
hard to unwind sometimes.

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: David Rientjes <rientjes@google.com>
Cc: "Alex Xu (Hello71)" <alex_y_xu@yahoo.ca>,
	Christoph Hellwig <hch@lst.de>,
	alsa-devel@alsa-project.org, bp@alien8.de, hch@infradead.org,
	hpa@zytor.com, linux-kernel@vger.kernel.org, mingo@redhat.com,
	Pavel Machek <pavel@ucw.cz>,
	perex@perex.cz, tglx@linutronix.de, tiwai@suse.com,
	x86@kernel.org
Subject: Re: next-0519 on thinkpad x60: sound related? window manager crash
Date: Tue, 9 Jun 2020 07:43:06 +0200	[thread overview]
Message-ID: <20200609054306.GA9606@lst.de> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2006081928070.148886@chino.kir.corp.google.com>

On Mon, Jun 08, 2020 at 07:31:47PM -0700, David Rientjes wrote:
> On Mon, 8 Jun 2020, Alex Xu (Hello71) wrote:
> 
> > Excerpts from Christoph Hellwig's message of June 8, 2020 2:19 am:
> > > Can you do a listing using gdb where this happens?
> > > 
> > > gdb vmlinux
> > > 
> > > l *(snd_pcm_hw_params+0x3f3)
> > > 
> > > ?
> > > 
> > 
> > (gdb) l *(snd_pcm_hw_params+0x3f3)
> > 0xffffffff817efc85 is in snd_pcm_hw_params (.../linux/sound/core/pcm_native.c:749).
> > 744             while (runtime->boundary * 2 <= LONG_MAX - runtime->buffer_size)
> > 745                     runtime->boundary *= 2;
> > 746
> > 747             /* clear the buffer for avoiding possible kernel info leaks */
> > 748             if (runtime->dma_area && !substream->ops->copy_user)
> > 749                     memset(runtime->dma_area, 0, runtime->dma_bytes);
> > 750
> > 751             snd_pcm_timer_resolution_change(substream);
> > 752             snd_pcm_set_state(substream, SNDRV_PCM_STATE_SETUP);
> > 753
> > 
> 
> Working theory is that CONFIG_DMA_NONCOHERENT_MMAP getting set is causing 
> the error_code in the page fault path.  Debugging with Alex off-thread we 
> found that dma_{alloc,free}_from_pool() are not getting called from the 
> new code in dma_direct_{alloc,free}_pages() and he has not enabled 
> mem_encrypt.

While DMA_COHERENT_POOL absolutely should not select DMA_NONCOHERENT_MMAP
(and you should send your patch either way), I don't think it is going
to make a difference here, as DMA_NONCOHERENT_MMAP just means we
allows mmaps even for non-coherent devices, and we do not support
non-coherent devices on x86.

From the disassembly it seems like a vmalloc allocation is NULL, which
seems really weird as this patch shouldn't make a difference for them,
and I also only see a single places that allocates the field, and that
checks for an allocation failure.  But the sound code is a little
hard to unwind sometimes.

  reply	other threads:[~2020-06-09  5:44 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-20 11:11 next-0519 on thinkpad x60: sound related? window manager crash Pavel Machek
2020-05-20 11:37 ` Takashi Iwai
2020-05-20 11:37   ` Takashi Iwai
2020-05-20 11:39   ` Pavel Machek
2020-05-20 11:39     ` Pavel Machek
2020-05-20 11:43     ` Takashi Iwai
2020-05-20 11:43       ` Takashi Iwai
2020-06-07 15:58 ` Alex Xu (Hello71)
2020-06-07 16:38   ` 82fef0ad811f "x86/mm: unencrypted non-blocking DMA allocations use coherent pools" was " Pavel Machek
2020-06-07 16:38     ` Pavel Machek
2020-06-07 19:41     ` David Rientjes
2020-06-07 19:41       ` David Rientjes
2020-06-07 22:53       ` Alex Xu (Hello71)
2020-06-07 22:53         ` Alex Xu (Hello71)
2020-06-08  0:57         ` David Rientjes
2020-06-08  0:57           ` David Rientjes
2020-06-08  2:13           ` Alex Xu (Hello71)
2020-06-08  2:13             ` Alex Xu (Hello71)
2020-06-08  6:19   ` Christoph Hellwig
2020-06-08  6:19     ` Christoph Hellwig
2020-06-08 13:53     ` Alex Xu (Hello71)
2020-06-08 13:53       ` Alex Xu (Hello71)
2020-06-09  2:31       ` David Rientjes
2020-06-09  2:31         ` David Rientjes
2020-06-09  5:43         ` Christoph Hellwig [this message]
2020-06-09  5:43           ` Christoph Hellwig
2020-06-09  8:05           ` Takashi Iwai
2020-06-09  8:05             ` Takashi Iwai
2020-06-09  8:43             ` Christoph Hellwig
2020-06-09  8:43               ` Christoph Hellwig
2020-06-09  9:09               ` Takashi Iwai
2020-06-09  9:09                 ` Takashi Iwai
2020-06-09  9:17                 ` Christoph Hellwig
2020-06-09  9:17                   ` Christoph Hellwig
2020-06-09  9:31                   ` Takashi Iwai
2020-06-09  9:31                     ` Takashi Iwai
2020-06-09 11:02                     ` Takashi Iwai
2020-06-09 11:02                       ` Takashi Iwai
2020-06-09 11:31                     ` Christoph Hellwig
2020-06-09 11:31                       ` Christoph Hellwig
2020-06-09 11:38                       ` Takashi Iwai
2020-06-09 11:38                         ` Takashi Iwai
2020-06-09 11:40                         ` Christoph Hellwig
2020-06-09 11:40                           ` Christoph Hellwig
2020-06-09 11:45                           ` Takashi Iwai
2020-06-09 11:45                             ` Takashi Iwai
2020-06-09 11:49                             ` Christoph Hellwig
2020-06-09 11:49                               ` Christoph Hellwig
2020-06-09 13:16                               ` Jaroslav Kysela
2020-06-09 13:16                                 ` Jaroslav Kysela
2020-06-10  5:26           ` David Rientjes
2020-06-10  5:26             ` David Rientjes
2020-06-10  7:14             ` Christoph Hellwig
2020-06-10  7:14               ` Christoph Hellwig
2020-06-09 11:47       ` Christoph Hellwig
2020-06-09 11:47         ` Christoph Hellwig
2020-06-09 15:12         ` Takashi Iwai
2020-06-09 15:12           ` Takashi Iwai
     [not found]           ` <<s5hr1uogtna.wl-tiwai@suse.de>
2020-06-11 14:51             ` Alex Xu (Hello71)
2020-06-11 14:51               ` Alex Xu (Hello71)
2020-06-11 17:11               ` Takashi Iwai
2020-06-11 17:11                 ` Takashi Iwai
2020-06-13 16:25                 ` Alex Xu (Hello71)
2020-06-13 16:25                   ` Alex Xu (Hello71)
2020-06-14  9:54                   ` Takashi Iwai
2020-06-14  9:54                     ` Takashi Iwai
2020-06-14 12:07                     ` Alex Xu (Hello71)
2020-06-14 12:07                       ` Alex Xu (Hello71)
2020-06-14 15:40                       ` Takashi Iwai
2020-06-14 15:40                         ` Takashi Iwai
2020-06-11 14:51         ` Alex Xu (Hello71)
2020-06-11 14:51           ` Alex Xu (Hello71)
     [not found] <20200520110900.GA8203@amd>
2020-05-21  7:41 ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200609054306.GA9606@lst.de \
    --to=hch@lst.de \
    --cc=alex_y_xu@yahoo.ca \
    --cc=alsa-devel@alsa-project.org \
    --cc=bp@alien8.de \
    --cc=hch@infradead.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pavel@ucw.cz \
    --cc=rientjes@google.com \
    --cc=tglx@linutronix.de \
    --cc=tiwai@suse.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.