From: Sebastian Frias <sebastian_frias@sigmadesigns.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>,
linux-mm <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: m(un)map kmalloc buffers to userspace
Date: Thu, 10 Dec 2015 17:48:31 +0100 [thread overview]
Message-ID: <5669ACDF.4030900@sigmadesigns.com> (raw)
In-Reply-To: <20151210140631.GO19496@dhcp22.suse.cz>
On 12/10/2015 03:06 PM, Michal Hocko wrote:
> On Thu 10-12-15 14:37:38, Sebastian Frias wrote:
>> On 12/10/2015 12:40 PM, Michal Hocko wrote:
>>> On Wed 09-12-15 16:35:53, Sebastian Frias wrote:
>>> [...]
>>>> We've seen that drivers/media/pci/zoran/zoran_driver.c for example seems to
>>>> be doing as us kmalloc+remap_pfn_range,
>>>
>>> This driver is broken - I will post a patch.
>>
>> Ok, we'll be glad to see a good example, please keep us posted.
>>
>>>
>>>> is there any guarantee (or at least an advised heuristic) to determine
>>>> if a driver is "current" (ie: uses the latest APIs and works)?
>>>
>>> OK, it seems I was overly optimistic when directing you to existing
>>> drivers. Sorry about that I wasn't aware you could find such a terrible
>>> code there. Please refer to Linux Device Drivers book which should give
>>> you a much better lead (e.g. http://www.makelinux.net/ldd3/chp-15-sect-2)
>>>
>>
>> Thank you for the link.
>> The current code of our driver was has portions written following LDD3,
>> however, we it seems that LDD3 advice is not relevant anymore.
>> Indeed, it talks about VM_RESERVED, it talks about using "nopage" and it
>> says that remap_pfn_range cannot be used for pages from get_user_page (or
>> kmalloc).
>
> Heh, it seems that we are indeed outdated there as well. The memory
> management code doesn't really require pages to be reserved and it
> allows to use get_user_page(s) memory to be mapped to user ptes.
> remap_pfn_range will set all the appropriate flags to make sure MM code
> will not stumble over those pages and let's the driver to take care of
> the memory deallocation.
Ok, just for information, do you know since when it is possible to use
remap_pfn_range on kmalloc/get_user_page memory?
>
>> It seems such assertions are valid on older kernels, because the code stops
>> working on 3.4+ if we use remap_pfn_range the same way than
>> drivers/media/pci/zoran/zoran_driver.c
>> However, kmalloc+remap_pfn_range does work on 4.1.13+
>
> As I've said nothing will guarantee that the kmalloc returned address
> will be page aligned so you might corrupt slab internal data structures.
> You might allocate a larger buffer via kmalloc and make sure it is
> aligned properly but I fail to see why should be kmalloc used in the
> first place as you need a memory in page size unnits anyway.
>
Ok, so let's say we stop using kmalloc in favor of __get_user_pages, do
you see other things that would need to be done to be compliant with
current practices?
For instance, drivers/media/pci/zoran/zoran_driver.c is doing:
for (off = 0; off < fh->buffers.buffer_size; off += PAGE_SIZE)
SetPageReserved(virt_to_page(mem + off));
on the memory allocated with kmalloc, but we are not doing any of that,
yet it was working. Would the switch to __get_user_pages require the
calls to SetPageReserved?
Thanks for your help.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Sebastian Frias <sebastian_frias@sigmadesigns.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>,
linux-mm <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: m(un)map kmalloc buffers to userspace
Date: Thu, 10 Dec 2015 17:48:31 +0100 [thread overview]
Message-ID: <5669ACDF.4030900@sigmadesigns.com> (raw)
In-Reply-To: <20151210140631.GO19496@dhcp22.suse.cz>
On 12/10/2015 03:06 PM, Michal Hocko wrote:
> On Thu 10-12-15 14:37:38, Sebastian Frias wrote:
>> On 12/10/2015 12:40 PM, Michal Hocko wrote:
>>> On Wed 09-12-15 16:35:53, Sebastian Frias wrote:
>>> [...]
>>>> We've seen that drivers/media/pci/zoran/zoran_driver.c for example seems to
>>>> be doing as us kmalloc+remap_pfn_range,
>>>
>>> This driver is broken - I will post a patch.
>>
>> Ok, we'll be glad to see a good example, please keep us posted.
>>
>>>
>>>> is there any guarantee (or at least an advised heuristic) to determine
>>>> if a driver is "current" (ie: uses the latest APIs and works)?
>>>
>>> OK, it seems I was overly optimistic when directing you to existing
>>> drivers. Sorry about that I wasn't aware you could find such a terrible
>>> code there. Please refer to Linux Device Drivers book which should give
>>> you a much better lead (e.g. http://www.makelinux.net/ldd3/chp-15-sect-2)
>>>
>>
>> Thank you for the link.
>> The current code of our driver was has portions written following LDD3,
>> however, we it seems that LDD3 advice is not relevant anymore.
>> Indeed, it talks about VM_RESERVED, it talks about using "nopage" and it
>> says that remap_pfn_range cannot be used for pages from get_user_page (or
>> kmalloc).
>
> Heh, it seems that we are indeed outdated there as well. The memory
> management code doesn't really require pages to be reserved and it
> allows to use get_user_page(s) memory to be mapped to user ptes.
> remap_pfn_range will set all the appropriate flags to make sure MM code
> will not stumble over those pages and let's the driver to take care of
> the memory deallocation.
Ok, just for information, do you know since when it is possible to use
remap_pfn_range on kmalloc/get_user_page memory?
>
>> It seems such assertions are valid on older kernels, because the code stops
>> working on 3.4+ if we use remap_pfn_range the same way than
>> drivers/media/pci/zoran/zoran_driver.c
>> However, kmalloc+remap_pfn_range does work on 4.1.13+
>
> As I've said nothing will guarantee that the kmalloc returned address
> will be page aligned so you might corrupt slab internal data structures.
> You might allocate a larger buffer via kmalloc and make sure it is
> aligned properly but I fail to see why should be kmalloc used in the
> first place as you need a memory in page size unnits anyway.
>
Ok, so let's say we stop using kmalloc in favor of __get_user_pages, do
you see other things that would need to be done to be compliant with
current practices?
For instance, drivers/media/pci/zoran/zoran_driver.c is doing:
for (off = 0; off < fh->buffers.buffer_size; off += PAGE_SIZE)
SetPageReserved(virt_to_page(mem + off));
on the memory allocated with kmalloc, but we are not doing any of that,
yet it was working. Would the switch to __get_user_pages require the
calls to SetPageReserved?
Thanks for your help.
next prev parent reply other threads:[~2015-12-10 16:48 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-08 17:25 m(un)map kmalloc buffers to userspace Sebastian Frias
2015-12-08 17:25 ` Sebastian Frias
2015-12-09 13:55 ` Michal Hocko
2015-12-09 13:55 ` Michal Hocko
2015-12-09 14:07 ` Marc Gonzalez
2015-12-09 14:07 ` Marc Gonzalez
2015-12-09 14:32 ` Michal Hocko
2015-12-09 14:32 ` Michal Hocko
2015-12-09 14:53 ` Sebastian Frias
2015-12-09 14:53 ` Sebastian Frias
2015-12-09 15:12 ` Michal Hocko
2015-12-09 15:12 ` Michal Hocko
2015-12-09 15:35 ` Sebastian Frias
2015-12-09 15:35 ` Sebastian Frias
2015-12-10 11:40 ` Michal Hocko
2015-12-10 11:40 ` Michal Hocko
2015-12-10 12:04 ` Richard Weinberger
2015-12-10 12:04 ` Richard Weinberger
2015-12-10 13:37 ` Sebastian Frias
2015-12-10 13:37 ` Sebastian Frias
2015-12-10 14:06 ` Michal Hocko
2015-12-10 14:06 ` Michal Hocko
2015-12-10 16:48 ` Sebastian Frias [this message]
2015-12-10 16:48 ` Sebastian Frias
2015-12-11 9:42 ` Michal Hocko
2015-12-11 9:42 ` Michal Hocko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5669ACDF.4030900@sigmadesigns.com \
--to=sebastian_frias@sigmadesigns.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=marc_gonzalez@sigmadesigns.com \
--cc=mhocko@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.