From: cl@linux.com (Christoph Lameter)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Page fault in kernel code
Date: Thu, 11 Sep 2014 09:19:52 -0500 (CDT) [thread overview]
Message-ID: <alpine.DEB.2.11.1409110915580.16730@gentwo.org> (raw)
In-Reply-To: <CALq1K=JmTtiLSvBWJET6fGE111wPOGUOO+7+nzrEnf99c5+OWA@mail.gmail.com>
On Thu, 11 Sep 2014, Leon Romanovsky wrote:
> > Linux kernel memory is not page-able, but memory allocated through vmalloc
> > can still cause page fault. How device drivers using vmalloc handle this?
> Pages allocated via vmalloc call won't generate page-faults.
Kernel faults are used on some platforms in a very limited way but not
for swapping in or "paging in from disk". Have a look at
linux/arch/x86/mm/fault.c:
/*
* We fault-in kernel-space virtual memory on-demand. The
* 'reference' page table is init_mm.pgd.
*
* NOTE! We MUST NOT take any locks for this case. We may
* be in an interrupt or a critical region, and should
* only copy the information from the master page table,
* nothing more.
*
* This verifies that the fault happens in kernel space
* (error_code & 4) == 0, and that the fault was not a
* protection error (error_code & 9) == 0.
*/
if (unlikely(fault_in_kernel_space(address))) {
if (!(error_code & (PF_RSVD | PF_USER | PF_PROT))) {
if (vmalloc_fault(address) >= 0)
return;
if (kmemcheck_fault(regs, address, error_code))
return;
}
/* Can handle a stale RO->RW TLB: */
if (spurious_fault(error_code, address))
return;
/* kprobes don't want to hook the spurious faults: */
if (kprobes_fault(regs))
return;
/*
* Don't take the mm semaphore here. If we fixup a prefetch
* fault we could otherwise deadlock:
*/
bad_area_nosemaphore(regs, error_code, address);
return;
}
next prev parent reply other threads:[~2014-09-11 14:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAJKgH8Df51ZL-BaN_zBmtP=2tjxh5po6KWdbR1Q7LwiR2DZzTg@mail.gmail.com>
2014-09-09 13:23 ` Page fault in kernel code Manavendra Nath Manav
2014-09-09 14:25 ` Greg KH
2014-09-09 15:51 ` Valdis.Kletnieks at vt.edu
2014-09-09 16:54 ` Jeff Haran
2014-09-10 9:15 ` Manavendra Nath Manav
2014-09-10 12:54 ` Valdis.Kletnieks at vt.edu
2014-09-10 14:52 ` Manavendra Nath Manav
2014-09-11 12:03 ` Leon Romanovsky
2014-09-11 14:19 ` Christoph Lameter [this message]
2014-09-11 14:53 ` Miles MH Chen
2014-09-11 15:26 ` Leon Romanovsky
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=alpine.DEB.2.11.1409110915580.16730@gentwo.org \
--to=cl@linux.com \
--cc=kernelnewbies@lists.kernelnewbies.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;
as well as URLs for NNTP newsgroup(s).