All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org, x86@kernel.org, hpa@zytor.com,
	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>, David Rientjes <rientjes@google.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 11:17:27 +0200	[thread overview]
Message-ID: <20200609091727.GA23814@lst.de> (raw)
In-Reply-To: <s5hlfkwip1h.wl-tiwai@suse.de>

On Tue, Jun 09, 2020 at 11:09:14AM +0200, Takashi Iwai wrote:
> On Tue, 09 Jun 2020 10:43:05 +0200,
> Christoph Hellwig wrote:
> > 
> > On Tue, Jun 09, 2020 at 10:05:26AM +0200, Takashi Iwai wrote:
> > > > >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.
> > > 
> > > It's not clear which sound device being affected, but if it's
> > > HD-audio on x86, runtime->dma_area points to a vmapped buffer from
> > > SG-pages allocated by dma_alloc_coherent().
> > > 
> > > OTOH, if it's a USB-audio, runtime->dma_area is a buffer by
> > > vmalloc().
> > 
> > Err, you can't just vmap a buffer returned from dma_alloc_coherent,
> > dma_alloc_coherent returns values are opaque and can't be used
> > for virt_to_page.  Whatever that code did has already been broken
> > per the DMA API contract and on many architectures and just happend
> > to work on x86 by accident.
> 
> Hmm, that's bad.
> 
> How would be a proper way to get the virtually mapped SG-buffer pages
> with coherent memory?  (Also allowing user-space mmap, too)

dma_mmap_coherent / dma_mmap_attrs for userspace.  We don't really
have a good way for kernel space mappings.

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Takashi Iwai <tiwai@suse.de>
Cc: Christoph Hellwig <hch@lst.de>,
	David Rientjes <rientjes@google.com>,
	"Alex Xu (Hello71)" <alex_y_xu@yahoo.ca>,
	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 11:17:27 +0200	[thread overview]
Message-ID: <20200609091727.GA23814@lst.de> (raw)
In-Reply-To: <s5hlfkwip1h.wl-tiwai@suse.de>

On Tue, Jun 09, 2020 at 11:09:14AM +0200, Takashi Iwai wrote:
> On Tue, 09 Jun 2020 10:43:05 +0200,
> Christoph Hellwig wrote:
> > 
> > On Tue, Jun 09, 2020 at 10:05:26AM +0200, Takashi Iwai wrote:
> > > > >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.
> > > 
> > > It's not clear which sound device being affected, but if it's
> > > HD-audio on x86, runtime->dma_area points to a vmapped buffer from
> > > SG-pages allocated by dma_alloc_coherent().
> > > 
> > > OTOH, if it's a USB-audio, runtime->dma_area is a buffer by
> > > vmalloc().
> > 
> > Err, you can't just vmap a buffer returned from dma_alloc_coherent,
> > dma_alloc_coherent returns values are opaque and can't be used
> > for virt_to_page.  Whatever that code did has already been broken
> > per the DMA API contract and on many architectures and just happend
> > to work on x86 by accident.
> 
> Hmm, that's bad.
> 
> How would be a proper way to get the virtually mapped SG-buffer pages
> with coherent memory?  (Also allowing user-space mmap, too)

dma_mmap_coherent / dma_mmap_attrs for userspace.  We don't really
have a good way for kernel space mappings.

  reply	other threads:[~2020-06-09  9:18 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
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 [this message]
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=20200609091727.GA23814@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=tiwai@suse.de \
    --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.