On Tue, 09 Jun 2020 11:31:20 +0200, Takashi Iwai wrote:
On Tue, 09 Jun 2020 11:17:27 +0200, Christoph Hellwig wrote:
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.
And that's the missing piece right now... :-<
BTW, this kind of usage is not specific to sound, but also V4L also does vmap() over SG pages from dma_alloc_coherent(). It seems done only on selected devices, though.
Takashi