This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Error removing module: Device or resource busy
On 12/25/2011 03:59 PM, Chris Dunlop wrote:
>> But it seems like your stap modules are being built without
>> this machinery, so corruption ensues.
>
> By "this machinery", do you mean the ->exit callback, and if so, is this the
> ->exit callback?
>
> # grep module_exit /root/.systemtap/cache/6b/stap_6bbd9bcdc91b5b9122793a314d034588_795.c
> static void systemtap_module_exit (void) {
I meant the code involved in refcounting and module exits, basically
everything guarded by #ifdef CONFIG_MODULE_UNLOAD in struct module.
Our exit path is more involved than just systemtap_module_exit, but it
starts with cleanup_exit as is standard for all kernel modules. Then
the kernel's scripts/mod/modpost.c creates the struct module with .exit
= cleanup_module. This too is guarded by #ifdef CONFIG_MODULE_UNLOAD.
If you run a stap example with "-p4 -k", it will leave the temporary
directory around so you can examine all the build result. The struct
module is written into .mod.c. It
> Without any of the zfs modules loaded...
And a clean boot as such? Just want to make sure in case we're dealing
with corruption by zfs, that it doesn't get that chance.
> # stap -v -e 'probe begin {printf("foo\n"); exit()}'
> Pass 1: parsed user script and 78 library script(s) using 77348virt/21892res/2620shr kb, in 110usr/20sys/170real ms.
> Pass 2: analyzed script: 1 probe(s), 1 function(s), 0 embed(s), 0 global(s) using 77876virt/22684res/2852shr kb, in 0usr/0sys/3real ms.
> Pass 3: translated to C into "/tmp/stapSBQNZp/stap_6bbd9bcdc91b5b9122793a314d034588_795_src.c" using 77876virt/22768res/2924shr kb, in 0usr/0sys/1real ms.
> Pass 4: compiled C into "stap_6bbd9bcdc91b5b9122793a314d034588_795.ko" in 1120usr/160sys/1889real ms.
> Pass 5: starting run.
> foo
> Error removing module 'stap_6bbd9bcdc91b5b9122793a314d03458_5786': Device or resource busy.
> WARNING: /usr/bin/staprun exited with status: 1
> Pass 5: run completed in 20usr/0sys/423real ms.
> Pass 5: run failed. Try again with another '--vp 00001' option.
If only stap was working, so we could write some scripts to track down
why stap isn't working... :/
Something else that occurs to me - in 1.6 we added code to auto-rename
modules as they are loaded to avoid conflicts. That requires poking in
struct module, so that could be causing issues for you. This is in the
-R option to staprun, which stap always sets unless you gave your own
module name. So two ways you can test around this:
- Run stap -p4 to get the module, then staprun it without -R.
- Run stap -m NAME to assign a specific module name.
Josh