mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

      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®