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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox