Re: ALSA: pcm: use dma_can_mmap() to check if a device supports dma_mmap_*

[Takashi Iwai <tiwai@suse.de>]

On Mon, 04 Nov 2019 09:49:43 +0100,
Greg Kroah-Hartman wrote:
> 
> On 11/4/19 9:32 AM, Greg Kroah-Hartman wrote:
> > On 11/4/19 9:27 AM, youling 257 wrote:
> >  > This driver
> > 
> https://android.googlesource.com/kernel/common/+/refs/heads/android-mainline/drivers/usb/gadget/function/f_audio_source.c 
> 
> >
> >  >
> >
> > The driver is broken and needs to be fixed.  Please feel free to submit
> > patches to AOSP to do so as you can trigger this easily.
> 
> Hm, maybe the driver isn't broken...

It is :)

> snd_pcm_lib_preallocate_pages_for_all() is called with
> SNDRV_DMA_TYPE_DEV set, so that should be fine,

That's the cause.  It passes NULL to the device object, which is
incorrect in anyway.  I guess this used to work casually just because
x86 accepts the NULL device object as if an ISA device.

> and the only other
> buffer I can see allocate here is with a call to
> snd_pcm_lib_alloc_vmalloc_buffer() which _should_ be ok, right?

If the driver allocates the buffer via vmalloc (and the snd_* helper),
it shouldn't do preallocate in that way.  That is, the correct fix
would  be simply to drop snd_pcm_lib_preallocate_pages_for_all() call
from the driver code.

Also, a quick skimming showed that the driver needs to set
snd_pcm_lib_get_vmalloc_page to the snd_pcm_ops.page ops.

> I don't see any buffers coming off the stack here, unless the gadget
> controller is the one creating them?

That's the code before actually allocating the buffer itself.  It
checks the availability of mmap support on the architecture, and the
helper code assumed a proper device object passed there via the
preallocation helper.


thanks,

Takashi