Re: unable to "rmmod" the module

[Mark]

Following up with my initial question -- the daemon opens 3 netlink sockets
in to the kernel module and polls one of it. The main problem here is that
the number of references to the module, i.e. how many processes are using
the module (the 3rd field of /proc/net/modules), isn't zero and thus the
module can't be unloaded.

Here is interesting part: before running the damon, the reference counter is
rightfuly 0, after the daemon has been launched, the counter goes up to 6,
although I'd expect just 3 given that it opens three sockets. So, after
killing the damon, the counter goes down to 3, and thus the module can't be
unloaded.

Are there any ways to catch what other descriptors etc. being kept open?

Thanks !


"Mark" <mark_cruz...@hotmail.com> wrote in message
news:kaamnd$6id$1...@speranza.aioe.org...
> Hello,
>
> I'm working with a large embedded software (ARM processor, embedded linux
> 2.6.31, busybox) involving both kernel and user space code. There's a
> kernel module normally loaded first, and daemon establishing netlink
> socket with the module.
>
> The issue here is that after killing the daemon, I'm no longer able to
> unload the module from the memory:
>
> % rmmod _module.ko
> % rmmod: _module.ko: Resource temporarily unavailable
> Analysis has shown that error (return value is -11, i.e. EAGAIN ?) is
> returned by try_stop_module() invoked in syscall delete_module()
> definition in kernel/module.c. Function try_stop_module() in turn calls
> stop_machine() and this is where I've stuck, as I'm not sure what's
> exactly happening there. I think the root cause is somewhere in the daemon
> that opens connections to the module and obviously something else and
> doesn't correctly close/clean-up on exit (apparently some references/locks
> are not released?)

Mark