public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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


  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