From: Thomas Schlichter <thomas.schlichter@web.de>
To: Rik van Riel <riel@conectiva.com.br>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Pinning kernel memory
Date: Thu, 12 Dec 2002 22:04:15 +0100 [thread overview]
Message-ID: <200212122204.16019.thomas.schlichter@web.de> (raw)
In-Reply-To: <Pine.LNX.4.50L.0212121814450.17748-100000@imladris.surriel.com>
Thanks, Oliver Neukum mailed me a similar answer, too.
So it looks as my problem was an other one, but setting the pages reserved
solved it.
The problem was that I remapped these kernel pages into user space and
accessing this remapped memory always leaded to a SIGBUS. And since setting
the pages reserved "pins" them, I thought they were swapped out...
I don't know if that is the correct way I do it, and if anyone can tell me how
it should be done I'll be interested...
Thomas Schlichter
P.S.: Here are some of the lines from the code I wrote that should show what I
mean... ;-)
int mem_init_module(void)
{
struct page *page;
~~~ cut ~~~
// allocate mem_size bytes of physical continuous kernel memory
page = alloc_pages( GFP_KERNEL, order );
if( !page )
{
printk( "<1>kernel_mem.o: could not get %d bytes of kernel memory\n",
mem_size );
return -ENOMEM;
}
mem_addr = page_address( page );
// pin the memory
while( page < virt_to_page(mem_addr + mem_size) )
SetPageReserved( page++ );
~~~ cut ~~~
return 0; // initialization successful
}
int mem_mmap( struct file *filp, struct vm_area_struct *vma )
{
unsigned long offset; // byte offset from start address
unsigned long physical; // physical start address
unsigned long vsize; // size in virtual address space
unsigned long psize; // size in physical address space
offset = vma->vm_pgoff << PAGE_SHIFT;
physical = virt_to_bus(mem_addr) + offset;
vsize = vma->vm_end - vma->vm_start;
psize = mem_size - offset;
printk( "<1>kernel_mem.o: mmap offset %lu, physical %#010lx, vsize %lu,
psize %lu\n", offset, physical, vsize, psize );
// virtual range is fully mapped to physical address space ?
if ( vsize > psize )
{
printk("<1>kernel_mem.o: mmap failed as vsize > psize\n");
return -EINVAL;
}
// do the remapping
remap_page_range( vma->vm_start, physical, vsize, vma->vm_page_prot );
// register memory operations to the kernel tables (like file operations)
vma->vm_ops = &mem_vm_ops;
// invoke the vma_open routine (which actually does nothing)
mem_vma_open( vma );
return 0;
}
Am Donnerstag, 12. Dezember 2002 21:15 schrieb Rik van Riel:
> On Thu, 12 Dec 2002, Thomas Schlichter wrote:
> > I want to create a big area of unswappable, physical continuous kernel
> > memory for hardware testing purposes. Currently I allocate the memory
> > using alloc_pages(GFP_KERNEL, order) and after this I pin it using
> > SetPageReserved(page) for each page.
>
> Kernel memory is never swappable, so there is no need to "pin it".
>
>
> Rik
next prev parent reply other threads:[~2002-12-12 20:56 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-12 17:00 Pinning kernel memory Thomas Schlichter
2002-12-12 20:15 ` Rik van Riel
2002-12-12 21:04 ` Thomas Schlichter [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-12-12 16:58 Thomas Schlichter
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=200212122204.16019.thomas.schlichter@web.de \
--to=thomas.schlichter@web.de \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@conectiva.com.br \
/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.