Exactly which driver is hit? The code path is via hw_support_mmap()
and it's currently:
static bool hw_support_mmap(struct snd_pcm_substream *substream)
{
if (!(substream->runtime->hw.info & SNDRV_PCM_INFO_MMAP))
return false;
if (substream->ops->mmap ||
substream->dma_buffer.dev.type != SNDRV_DMA_TYPE_DEV)
return true;
return dma_can_mmap(substream->dma_buffer.dev.dev);
}
so at least the driver has already set the SNDRV_DMA_TYPE_DEV
explicitly (it's non-zero) and some device object, but the device
object was invalid for dma_can_mmap() call.
This smells more like a driver-side issue, not in the core side.
thanks,
Takashi
Exactly which driver is hit? The code path is via hw_support_mmap()
and it's currently:
static bool hw_support_mmap(struct snd_pcm_substream *substream)
{
if (!(substream->runtime->hw.info & SNDRV_PCM_INFO_MMAP))
return false;
if (substream->ops->mmap ||
substream->dma_buffer.dev.type != SNDRV_DMA_TYPE_DEV)
return true;
return dma_can_mmap(substream->dma_buffer.dev.dev);
}
so at least the driver has already set the SNDRV_DMA_TYPE_DEV
explicitly (it's non-zero) and some device object, but the device
object was invalid for dma_can_mmap() call.
This smells more like a driver-side issue, not in the core side.
thanks,
Takashi
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...
snd_pcm_lib_preallocate_pages_for_all() is called with
SNDRV_DMA_TYPE_DEV set, so that should be fine, 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?
I don't see any buffers coming off the stack here, unless the gadget
controller is the one creating them?
thanks,
greg k-h
>
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