freeing locks acquired by kernel thread?

freeing locks acquired by kernel thread?

[Asim]

Hi,

I have a driver thread that I kill using do_exit(SIGKILL) upon
exception. Unfortunately, I do not see it releasing all locks when it
exits and I get a lockdep trace. The exit_sem() code does not seem to
free my mutexes.

I was wondering if there is way I would make sure I have release all
locks before I issue do_exit.

I tried to walk the locks in the current thread using this piece of
code I've written:

struct task_struct *curr = get_current();
int i, depth = curr->lockdep_depth;
        for (i = 0; i < depth; i++) {
                printk("\nLock: #%d:\n ", i);

                printk("[<%p>] %pS\n", (void *) (curr->held_locks +
i)->acquire_ip, (void *) (curr->held_locks + i)->acquire_ip);

                lock_release((curr->held_locks + i)->instance, 1,
(curr->held_locks + i)->acquire_ip);
        }

I am able to print the lock correctly (address and IP). But I get "[
BUG: bad unlock balance detected! ]" and "but there are no more locks
to release!". And then when I call do_exit, I get unreleased locks
message for the same locks. This makes my module unusable, atleast the
codepaths where these locks lie (both within and outside my kernel(say
locks in sysfs)).

If anyone has had success in clearing all locks of a thread upon exit,
or has a pointer to such an existing code in kernel it would be
useful.

Thanks,
Asim

freeing locks acquired by kernel thread?

[Kristof Provost]

On 2012-04-04 10:50:23 (-0500), Asim <linkasim@gmail.com> wrote:
> Hi,
> 
> I have a driver thread that I kill using do_exit(SIGKILL) upon
> exception. Unfortunately, I do not see it releasing all locks when it
> exits and I get a lockdep trace. The exit_sem() code does not seem to
> free my mutexes.
> 
> If anyone has had success in clearing all locks of a thread upon exit,
> or has a pointer to such an existing code in kernel it would be
> useful.
> 
"Don't do that!"

You're not programming in user space. The kernel won't clean up after you.
Manage your locks yourself, don't just kill threads and expect
everything to work!
You need to signal your thread to stop and let it clean up everything
before it exists.

More abstractly: you have mutexes which implies you have shared data
structures between the thread you want to kill and some other code.
How could you ensure the data is in a consistent state if the thread can
be killed at any point?

Regards,
Kristof