All of lore.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 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.