From: Fawad Lateef <fawadlateef@gmail.com>
To: Mishael A Sibiryakov <death@junki.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Lock page with HIGHMEM
Date: Fri, 28 Oct 2005 06:43:17 +0500 [thread overview]
Message-ID: <1e62d1370510271843y18fbeca9o52606b0c684c9884@mail.gmail.com> (raw)
In-Reply-To: <1130457144.23846.40.camel@me.home>
On 10/28/05, Mishael A Sibiryakov <death@junki.org> wrote:
>
> I have "little" troubles with HIGHMEM.
>
> The situation:
> I have a some pages which allocated via kmalloc(), after this pages is
> locked by get_page(). This pages is used in interrupt context, also in
> #PF too. When this code working on kernel without HIGHMEM support, then
> everything is fine. But when kernel with HIGHMEM then pages will be
> unmapped from linear space (i think) and i have a triple exception and
> you know that happens further :)
> I've try lock pages via get_user_pages, w/wo vma, by set
> SetPageReserved , Locked and etc. But nothing.
>
Here you mean that you allocated memory from kmalloc which corresponds
to some pages and then you are dealing with those pages ! right ? Then
you can use alloc_page/pages to get the page directly or there is some
reason for not to use them ?
AFAIK kernel keeps the seperate virtual addresses range for mapping
HIGHMEM to ZONE_NORMAL (PKMAP_BASE to PKMAP_BASE + LAST_PKMAP) which
is from the area called as VMALLOC_RESERVE used for holding temporary
mappings and kmalloc like rountines returned memory will never be
unmapped or at-least I havn't saw this behaviour.
> How i can avoid this problem ? E.g. how i can lock page in kernel and be
> assured about that that it will not be unmapped, and can be accessed via
> linear address every time ?
>
If you got page/memory from the kernel functions like
alloc_page/kmalloc then they are not unmapped and if they unmapped in
any case (which I think won't) then kernel is responsible to mapping
them back when ever you will be going to use it !
--
Fawad Lateef
prev parent reply other threads:[~2005-10-28 1:43 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-27 23:52 Mishael A Sibiryakov
2005-10-28 1:43 ` Fawad Lateef [this message]
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=1e62d1370510271843y18fbeca9o52606b0c684c9884@mail.gmail.com \
--to=fawadlateef@gmail.com \
--cc=death@junki.org \
--cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®