public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <compudj@krystal.dyndns.org>
To: "Stone, Joshua I" <joshua.i.stone@intel.com>,
	  Tom Zanussi <zanussi@us.ibm.com>,
	michel.dagenais@polymtl.ca
Cc: systemtap@sources.redhat.com
Subject: Re: double fault -> PAGE_KERNEL flagged memory
Date: Tue, 22 Nov 2005 14:00:00 -0000	[thread overview]
Message-ID: <20051122140021.GA3907@Krystal> (raw)
In-Reply-To: <CBDB88BFD06F7F408399DBCF8776B3DC05A8FB95@scsmsx403.amr.corp.intel.com>

I suspect that your double fault may come from the systemTAP logging code. Do
you have an instrumentation point in any fault handler ?

For Tom : can you flag the RelayFS buffer memory PAGE_KERNEL instead of
GFP_KERNEL ? Otherwise, it leads to page faults when accessing those pages when
accessed for the first time (seen with LTTng).

For instance, if you log an event for the page fault handler, and this logging
code does generate a page fault itself, then you get a double fault.

The same could apply to unaligned memory access.

Make sure that the SystemTAP code is _always_ in contiguous memory non
swappable to disk :

The Linux kernel module loading does make sure that all module code is memory
locked (see module.c) by first loading the whole module in a vmap area (which
is swappable) and then copying the code in a region of memory flagged
PAGE_KERNEL_EXEC (see vmalloc.c:vmalloc_exec()).

Furthermore, make sure that each data memory regions are also non swappable.
That means the RelayFS buffer too.

So :

- memory in which the SystemTAP code is loaded should be allocated with
  vmalloc_exec() (or with the GFP_KERNEL | __GFP_HIGHMEM, PAGE_KERNEL_EXEC
  flags).
- SystemTAP global data structures should be in memory protected from swap out,
  with a flag like PAGE_KERNEL.
- RelayFS buffers should be PAGE_KERNEL too (not GFP_KERNEL).


Mathieu


* Stone, Joshua I (joshua.i.stone@intel.com) wrote:
> I am seeing sporadic double-faults when running tests on systemtap.  I
> am trying to run systemtap.base/lt.exp, though others fail as well.  It
> doesn't always fail, but if I run it four or five times in succession
> that's usually enough to trigger the fault.  Below are manual copies of
> a couple of the faults dumped to the console:
> 
> double fault, gdt at c0358000 [255 bytes]
> double fault, tss at c03dc000
> eip = ffffffff, esp = f4b6500c
> eax = ffffffff, ebx = ffffffff, ecx = 0000007b, edx = f4b65018
> esi = ffffffff, edi = ffffffff, ebp = 00000000
>  
> double fault, gdt at c0358000 [255 bytes]
> double fault, tss at c03dc000
> eip = c011a799, esp = f5bd4f98
> eax = f959a380, ebx = f5bd5170, ecx = 0000007b, edx = f4bd505c
> esi = 00000000, edi = c011a785, ebp = 00000000
> 
> The first dump doesn't tell much, but the edi and eip values in the
> second dump are interesting.  'c011a785' is the beginning of
> do_page_fault, and the instruction at 'c011a799' is a read from the
> stack.  Methinks the stack runneth over?
> 
> This is on RHEL4 U2, i686, kernel 2.6.9-22.EL.  I verified this crash on
> two different machines with this kernel: an IBM T42 laptop (1.7GHz
> Pentium M, 1GB RAM), and a desktop (3.6GHz Pentium 4 HT/EM64T, 2GB RAM).
> I couldn't reproduce the problem with the 2.6.9-22.ELsmp kernel.  I also
> tried the desktop in x86_64 mode, and could not reproduce the problem
> with the UP kernel nor the SMP kernel.
> 
> Please let me know if there's any other information I can provide to
> help track this down...
> 
> Thanks,
> 
> Josh Stone
> 
OpenPGP public key:              http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint:     8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68 

  parent reply	other threads:[~2005-11-22 14:00 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-22  1:12 double fault Stone, Joshua I
2005-11-22  1:25 ` Roland McGrath
2005-11-22  9:29 ` Richard J Moore
2005-11-22 14:00 ` Mathieu Desnoyers [this message]
2005-11-22 15:12   ` double fault -> PAGE_KERNEL flagged memory Tom Zanussi
2005-11-22 15:24     ` Mathieu Desnoyers
2005-11-22 16:52       ` Tom Zanussi
2005-11-22 18:59         ` Mathieu Desnoyers
2005-11-23 15:13           ` Tom Zanussi
2005-11-23 17:53             ` Mathieu Desnoyers
2005-11-23 20:16               ` Tom Zanussi
2005-11-23 21:00                 ` Frank Ch. Eigler
2005-11-23 21:51                   ` Roland McGrath
2005-11-23 21:56                     ` Mathieu Desnoyers
2005-11-23 22:34                       ` Roland McGrath
2005-11-23 22:44                         ` Mathieu Desnoyers
2005-11-23 23:20                         ` Tom Zanussi
2005-11-24 18:10                         ` Frank Ch. Eigler
2005-11-24 22:09                           ` Roland McGrath
2005-11-23 22:18                   ` Tom Zanussi
2005-11-23 22:25                     ` Frank Ch. Eigler
2005-11-23 23:21                 ` Mathieu Desnoyers
2005-11-22 15:17   ` Mathieu Desnoyers
2005-11-22 15:42   ` Frank Ch. Eigler
2005-11-22 16:01     ` Mathieu Desnoyers
2005-11-23  8:34 ` double fault Martin Hunt
2005-11-23 17:21   ` Mathieu Desnoyers
2005-11-23 17:54     ` Martin Hunt
2005-11-23 18:09       ` Mathieu Desnoyers

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=20051122140021.GA3907@Krystal \
    --to=compudj@krystal.dyndns.org \
    --cc=joshua.i.stone@intel.com \
    --cc=michel.dagenais@polymtl.ca \
    --cc=systemtap@sources.redhat.com \
    --cc=zanussi@us.ibm.com \
    /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 read-only IMAP folder(s) and NNTP newsgroup(s).