kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
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;
        }

  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).