Re: m(un)map kmalloc buffers to userspace

[Sebastian Frias]

On 12/09/2015 04:12 PM, Michal Hocko wrote:
> On Wed 09-12-15 15:53:22, Sebastian Frias wrote:
> [...]
> > 2) Now that VM_RESERVED was removed, is there another recommended flag to
> > replace it for the purposes above?
>
> VM_IO + potentially others depending on your usecase.
>
> > 3) Since it was working before, we suppose that something that was
> > previously done by default on the kernel it is not done anymore, could that
> > be a remap_pfn_range during mmap or kmalloc?
>
> VM_RESERVED removal was a cleanup which has removed the flag because it
> was not needed and the same effect could be implied from either VM_IO or
> VM_DONTEXPAND | VM_DONTDUMP. See 314e51b9851b ("mm: kill vma flag
> VM_RESERVED and mm->reserved_vm counter") for more detailed information.
>
> > 4) We tried using remap_pfn_range inside mmap and while it seems to work, we
> > still get occasional crashes due to corrupted memory (in this case the
> > behaviour is the same between 4.1 and 3.4 when using the same modified
> > driver), are we missing something?
>
> This is hard to tell without knowing your driver. I would just encourage
> you to look at other drivers which map kernel memory to userspace via
> mmap. There are many of them. Maybe you can find a pattern which suites
> your usecase.

Ok, thanks.
We've seen that drivers/media/pci/zoran/zoran_driver.c for example seems 
to be doing as us kmalloc+remap_pfn_range, is there any guarantee (or at 
least an advised heuristic) to determine if a driver is "current" (ie: 
uses the latest APIs and works)?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/