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