public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: Josh Stone <jistone@redhat.com>
To: Chris Dunlop <chris@onthe.net.au>
Cc: systemtap@sourceware.org
Subject: Re: Error removing module: Device or resource busy
Date: Fri, 23 Dec 2011 21:10:00 -0000	[thread overview]
Message-ID: <4EF4E089.6060008@redhat.com> (raw)
In-Reply-To: <20111223050020.GA11829@onthe.net.au>

On 12/22/2011 09:00 PM, Chris Dunlop wrote:
> Hi,
> 
> Linux-3.0.13, systemtap 6.1 and now HEAD(b6a3da4)

Your dump looks like x86_64 - is this on any particular distro?  Are you
building this kernel yourself?

> I've just started using systemtap to help diagnose a problem with zfsonlinux[1].

Cool!

> Whenever I run stap[2], the output ends with:
> 
>   Error removing module 'stap_fcac0085842418e34d8094455dc203e8_1_21605': Device or resource busy.
> 
> (obviously the module name changes) and the module is still loaded:
> 
>   # lsmod | grep stap
>   stap_fcac0085842418e34d8094455dc203e8_1_21605  2896285 1027571582 [permanent]

This is odd.  Reading kernel/module.c, the "[permanent]" should only
come about if the module has no ->exit callback.  And 1027571582 is the
field for the module refcount, which doesn't look plausible.

You must have CONFIG_MODULE_UNLOAD=y, or else the kernel just prints a
dummy " - -" in place of the refcount.  Though I'm not certain how lsmod
translates that, so you might check /proc/modules directly.  But it
seems like your stap modules are being built without this machinery, so
corruption ensues.  Are you sure that /lib/modules/`uname -r`/build
matches the running kernel?

> Using "rmmod -f" on that module results in a kernel NULL pointer dereference[3].

This is bound to crash, even if all else is solved.  If the module exit
routines don't work, then probes may be left installed, and will
certainly die as soon as it tries to call the handler from unloaded
memory.  So don't waste any time trying to get "rmmod -f" working.

Fedora, for instance, does not enable CONFIG_MODULE_FORCE_UNLOAD at all,
because there are very few cases where this would do anything sane.

> Any suggestions about how to avoid the unloadable module?

If you can boot without any of the zfs stuff, then I'd experiment with
that first, just to make sure stap is lined up with all the correct
kernel build infrastructure.  Try something simple, like one of the
syscall examples.

Josh

  reply	other threads:[~2011-12-23 20:12 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-23  8:21 Chris Dunlop
2011-12-23 21:10 ` Josh Stone [this message]
2011-12-26 18:33   ` Chris Dunlop
2011-12-27 22:06     ` Josh Stone
2011-12-28 17:08       ` Chris Dunlop
2012-01-21  1:18         ` Josh Stone
2012-01-21  1:36           ` Chris Dunlop
2012-01-21  2:30             ` Chris Dunlop
2012-01-21  7:27               ` Josh Stone
2012-01-23  7:25                 ` Chris Dunlop
2012-01-25 12:31                   ` Frank Ch. Eigler
2012-01-26  0:30                     ` Chris Dunlop
2012-01-26  1:34                       ` Josh Stone
2012-01-26  2:28                         ` Chris Dunlop
2012-01-26 18:47                           ` Josh Stone
2012-01-26 23:32                             ` Chris Dunlop
2012-01-21  1:40         ` Chris Dunlop

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=4EF4E089.6060008@redhat.com \
    --to=jistone@redhat.com \
    --cc=chris@onthe.net.au \
    --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).