public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: David Smith <dsmith@redhat.com>
To: systemtap@sourceware.org
Subject: Re: automated way to find functions that we might want to blacklist
Date: Tue, 17 Jan 2012 20:18:00 -0000	[thread overview]
Message-ID: <4F15D792.2050408@redhat.com> (raw)
In-Reply-To: <20120115214402.GG6309@sli.dy.fi>

On 01/15/2012 03:44 PM, Sami Liedes wrote:

> Probing any of these functions (eventually) crashes Debian testing's
> kernel 3.1.x:


A couple of these don't make any sense to me:

> * hash_64
> * hash_ptr


There is nothing that those 2 functions do that can crash the kernel.
Those functions (should be) always inlined.  I'd guess the problem isn't
those two functions, but the function that is calling them.

To test for true function calls, you *shouldn't* do:

# stap -e 'probe kernel.function("*") {}'

The above probes inlined functions and real function calls.  Instead you
should do the equivalent of:

# stap -e 'probe kernel.function("*").call {}'

Another problem I see with your testing methodology is that you are
using xen.  I don't think we've used xen in a while, but the xen kernel
always gave us different results than a regular kernel.  I'd test on
bare metal or in a kvm instance.

I'll make one final comment here.  In my mind the blacklist is a
semi-temporary thing (although we don't typically remove functions from
it).  The real fix here is to get the crashing functions marked with
'__kprobes' in the upstream kernel.  This fixes the problem for all
kprobes users, not just systemtap.

-- 

David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)

  parent reply	other threads:[~2012-01-17 20:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-22 23:33 Timo Juhani Lindfors
2011-12-24 14:27 ` Sami Liedes
2012-01-15 21:46   ` Sami Liedes
2012-01-15 22:13     ` Sami Liedes
2012-01-17 20:18     ` David Smith [this message]
2012-01-17 21:55       ` Sami Liedes
2012-01-19 13:10       ` Sami Liedes
2012-01-19 16:42         ` Josh Stone

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=4F15D792.2050408@redhat.com \
    --to=dsmith@redhat.com \
    --cc=systemtap@sourceware.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 read-only IMAP folder(s) and NNTP newsgroup(s).