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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>