From: Hans Berglund <hb@spacetec.no>
To: linux-kernel@vger.kernel.org
Subject: Kernel memory allocation and page used counter
Date: Tue, 14 Oct 2003 11:08:26 +0200 [thread overview]
Message-ID: <3F8BBD0A.50001@spacetec.no> (raw)
I have reserved a bounch of 128k sized pieces of kernel memory
using addr[i] = __get_free_pages (GFP_KERNEL, 5); repeated times.
The first time the pages are used, I can DMA to this memory,
and get the data without problems. After freeing the memory
with free_pages (addr[i], 5); and allocating next time, the
kernel crashes in different ways each time when I use the memory.
Usually an oops with the message: "Unable to handle kernel paging
request at virtual address xxxxxxxx".
I have noticed that the struct page->count.counter of the first page
of each 128k chunk is incremented, but not of the remaining pages.
Then I tried to increment the counter "manually" by using get_page()
just after allocation, and the system seemed to become stable.
Do I really have to mark the pages as used, just after allocation, and
is there a kernel call to du this in one operation?
If the pages are used by others, why does the kernel crash after the
second allocation, and not the first?
I am running kernel 2.4.19, and I use the code below to do the
mapping.
All answers are appreciated.
Hans
struct page *xxx_vma_nopage (struct vm_area_struct *vma,
unsigned long addr, int write)
{
int offset, block;
void *virt_addr;
card_t *cp;
struct page *cpage;
cp = vma->vm_private_data;
offset = addr - vma->vm_start;
if ((addr < vma->vm_start) || (addr >= vma->vm_end))
{
PWARNING ("nopage: Mapping out of range, start=0x%x, addr=0x%x,"
"end=0x%x\n",
(int)vma->vm_start, (int)addr, (int)vma->vm_end);
return (0);
}
block = offset / KM_SIZE; /* KM_SIZE = 128k */
virt_addr = cp->list[block].address + (offset % KM_SIZE);
cpage = virt_to_page (virt_addr);
get_page (cpage);
return (cpage);
}
struct vm_operations_struct xxx_vmops =
{
open: xxx_vma_open,
close: xxx_vma_close,
nopage: xxx_vma_nopage,
};
int
xxx_mmap (struct file *filp, struct vm_area_struct *vma)
{
card_t *cp = &xxxarr[MINOR(filp->f_dentry->d_inode->i_rdev)];
vma->vm_flags |= VM_RESERVED;
vma->vm_ops = &xxx_vmops;
vma->vm_private_data = cp;
xxx_vma_open(vma);
return (0);
}
reply other threads:[~2003-10-14 9:08 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=3F8BBD0A.50001@spacetec.no \
--to=hb@spacetec.no \
--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