Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1287579

Re: m(un)map kmalloc buffers to userspace

From Sebastian Frias <sebastian_frias@sigmadesigns.com>
Newsgroups linux.kernel
Subject Re: m(un)map kmalloc buffers to userspace
Date 2015-12-09 16:40 +0100
Message-ID <qDP0u-1Jn-29@gated-at.bofh.it> (permalink)
References (1 earlier) <qDNrI-EN-5@gated-at.bofh.it> <qDNBn-Xy-5@gated-at.bofh.it> <qDO4p-1aj-11@gated-at.bofh.it> <qDOnM-1h9-9@gated-at.bofh.it> <qDOH8-1CS-25@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

m(un)map kmalloc buffers to userspace Sebastian Frias <sebastian_frias@sigmadesigns.com> - 2015-12-08 18:40 +0100
  Re: m(un)map kmalloc buffers to userspace Michal Hocko <mhocko@kernel.org> - 2015-12-09 15:00 +0100
    Re: m(un)map kmalloc buffers to userspace Marc Gonzalez <marc_gonzalez@sigmadesigns.com> - 2015-12-09 15:10 +0100
      Re: m(un)map kmalloc buffers to userspace Michal Hocko <mhocko@kernel.org> - 2015-12-09 15:40 +0100
        Re: m(un)map kmalloc buffers to userspace Sebastian Frias <sebastian_frias@sigmadesigns.com> - 2015-12-09 16:00 +0100
          Re: m(un)map kmalloc buffers to userspace Michal Hocko <mhocko@kernel.org> - 2015-12-09 16:20 +0100
            Re: m(un)map kmalloc buffers to userspace Sebastian Frias <sebastian_frias@sigmadesigns.com> - 2015-12-09 16:40 +0100
              Re: m(un)map kmalloc buffers to userspace Michal Hocko <mhocko@kernel.org> - 2015-12-10 12:50 +0100
                Re: m(un)map kmalloc buffers to userspace Richard Weinberger <richard.weinberger@gmail.com> - 2015-12-10 13:10 +0100
                Re: m(un)map kmalloc buffers to userspace Sebastian Frias <sebastian_frias@sigmadesigns.com> - 2015-12-10 14:40 +0100
                Re: m(un)map kmalloc buffers to userspace Michal Hocko <mhocko@kernel.org> - 2015-12-10 15:10 +0100
                Re: m(un)map kmalloc buffers to userspace Sebastian Frias <sebastian_frias@sigmadesigns.com> - 2015-12-10 17:50 +0100
                Re: m(un)map kmalloc buffers to userspace Michal Hocko <mhocko@kernel.org> - 2015-12-11 10:50 +0100

csiph-web