public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: Tom Zanussi <zanussi@us.ibm.com>
To: fche@redhat.com (Frank Ch. Eigler)
Cc: Tom Zanussi <zanussi@us.ibm.com>,
	ltt-dev@shafik.org,         systemtap@sources.redhat.com
Subject: Re: double fault -> PAGE_KERNEL flagged memory
Date: Wed, 23 Nov 2005 22:18:00 -0000	[thread overview]
Message-ID: <17284.60038.184453.258672@tut.ibm.com> (raw)
In-Reply-To: <y0mek57f5bs.fsf@tooth.toronto.redhat.com>

Frank Ch. Eigler writes:
 > 
 > zanussi wrote:
 > 
 > > [...]  What would cause a double fault would be if the vmalloc_fault
 > > tried logging before the page table was updated, which would cause
 > > the same vmalloc fault.
 > 
 > Then this is analogous to the problem of calling printk from within an
 > inconveniently placed kprobe.  What can we do to eliminate this
 > vulnerability?  Can we somehow arrange to "fault in" all probe-related
 > kernel-space vmalloc areas into new process' address spaces, so we don't
 > encounter this unintentional and undesirable reentrancy?
 > 

I'll think about it, but it doesn't sound like fun.  It sounds like it
might be one of those cases where you only allow a tapset to
instrument a certain area, in this case a page fault tapset to
instrument the page fault path.  I can't remember, how is the
possibility of a printk() in a problematic function currently handled
in systemtap?

Tom


  parent reply	other threads:[~2005-11-23 22:18 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 ` double fault -> PAGE_KERNEL flagged memory Mathieu Desnoyers
2005-11-22 15:12   ` 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 [this message]
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=17284.60038.184453.258672@tut.ibm.com \
    --to=zanussi@us.ibm.com \
    --cc=fche@redhat.com \
    --cc=ltt-dev@shafik.org \
    --cc=systemtap@sources.redhat.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).