On Wed, Jul 12, 2023 at 08:01:18AM -0700, Suren Baghdasaryan wrote:
> Are you suggesting to break remap_pfn_range() into two stages
> (remap_pfn_range_prepare() then remap_pfn_range())?
> If so, there are many places remap_pfn_range() is called and IIUC all
> of them would need to use that 2-stage approach (lots of code churn).
> In addition, this is an exported function, so many more drivers might
> expect the current behavior.
You do not understand correctly.
When somebody calls mmap, there are two reasonable implementations.
Here's one:
.mmap = snd_dma_iram_mmap,
static int snd_dma_iram_mmap(struct snd_dma_buffer *dmab,
struct vm_area_struct *area)
{
area->vm_page_prot = pgprot_writecombine(area->vm_page_prot);
return remap_pfn_range(area, area->vm_start,
dmab->addr >> PAGE_SHIFT,
area->vm_end - area->vm_start,
area->vm_page_prot);
}
This is _fine_. It is not called from the fault path, it is called in
process context. Few locks are held (which ones aren't even
documented!)
The other way is to set vma->vm_ops. The fault handler in vm_ops
should not be calling remap_pfn_range(). It should be calling
set_ptes(). I almost have this driver fixed up, but I have another
meeting to go to now.
