Re: [BUG] pgprot_noncached() is -NOT- safe for mapping vmalloc buffers into userspace

[Takashi Iwai <tiwai@suse.de>]

At Fri, 25 Mar 2011 21:23:26 +1100,
Benjamin Herrenschmidt wrote:
> 
> On Fri, 2011-03-25 at 11:12 +0100, Takashi Iwai wrote:
> > At Fri, 25 Mar 2011 20:15:33 +1100,
> > Benjamin Herrenschmidt wrote:
> > > 
> > > > > We
> > > > > must also make sure we don't go down that path for vmalloc memory
> > > > > though.
> > > >
> > > > Yes.
> > > 
> > > I haven't actually checked, but I assume that the test
> > > 
> > > substream->dma_buffer.dev.type == SNDRV_DMA_TYPE_DEV
> > > 
> > > In snd_pcm_default_mmap() takes care of that, please correct me if
> > > I'm wrong in which case we'll need something else there.
> > 
> > Well, in the case of usb-audio, it's not handled via
> > dma_mmap_coherent(), as the page isn't allocated via
> > dma_alloc_coherent() but vmalloc().
> 
> Right, I just wanted to make sure I was right to assume that a page
> allocated by vmalloc() was going to fail the above test in 
> snd_pcm_default_mmap() and thus -not- get into dma_mmap_coherent()...
> just double checking as I'm not totally familiar with the intricacies of
> the pcm code :-)
> 
> > The bad commit was to overcome some problems on SH platform, IIRC,
> > when it's used with dmix -- i.e. concurrent accesses on the mmapped
> > buffer from multiple processes.  But, this looks obviously like a
> > wrong approach.
> 
> Is this a vivt architecture ? Maybe enforcing some restrictions on the
> virtual addresses so they hit the same cache congruence classes ?

Possibly, yes.  But we need to re-test the problem first with the
recent kernel.

> > Actually, the buffer allocated there in usb-audio is an intermediate
> > buffer, that isn't directly transferred to hardware.  We may need a
> > bit more consideration what is the best way to solve that issue (if
> > it's still really present).
> 
> Right. I wouldn't expect vmalloc stuff to hit HW in most cases anyways,
> though I do wonder why you don't pass the buffer directly to the HCD and
> avoid that intermediate step but that's a completely different
> question :-)

The direct buffer was used partly in the older versions.  But there
was a problem in the accuracy of the buffer playback position, so this
was switched to full double-buffering.


thanks,

Takashi