I am developing a driver for a device in Linux Kernel 2.6.35.7. I create a mutex (have tried DEFINE_MUTEX() and mutex_init()), when created mutex_is_locked always returns 1. If I mutex_unlock and then check mutex_is_locked it still returns 1.

When I call mutex_trylock it returns 0 as expected because it cannot acquire the mutex but when I call mutex_lock_interruptible it returns 0 as if it has acquired the lock.

This is very frustrating as it did work on a previous kernel but since we upgraded our kernel it now is useless.

Am I missing some change to the Linux kernel mutex API? I have searched and found all the info on kernel mutexing I need but the behavior I'm seeing is not described anywhere...


EDIT: I am now noticing that when I call mutex_unlock, mutex_is_locked returns 1. If I call mutex_lock, mutex_is_locked returns 0.

What's the return code from mutex_init() ?

The mutex_init I have appears to be a macro. How do I look at the return code?

Maybe you could post a code snippet, it might be easier.

Will work on posting a snippet..

Q: Are mutexes binary or do they keep a count of requests and only block when you try to lock a mutex with a count of zero?
I've been printing out the mutex_name->count.counter value and it seems to increment and decrement like a semaphore. My code is working when I use that count for my conditional lock and unlocks.

Maybe you should use down/up for locking and unlocking then

Mutexes are binary:
http://geekswithblogs.net/shahed/arc.../09/81268.aspx

That is what I thought. This behavior would indicate a bug in the kernel I compiled I guess.

"A bug in the kernel ...?" Uhh, no.

How do I say this nicely? Well, maybe I don't have to mince too many words because after all we're talking about computer software and not about each other. It's a bug, all right, and (how do I say this?) it's in your code somewhere. Because, realistically, there is no other plausible place that it could be. Now it could obviously be many root causes and you're going to have to be very methodical (you imply that the code worked properly before, which is a very important finding), but the correct operation of the kernel is more or less something that you can take for granted.

Did not mean to offend, I meant an incompatibility with the libraries we have, they have been modified (some updated, some not) so it would be a developer created bug.

Offend? Pshaw. "Nothing personal, it's just ones and zeroes."

Definitely you're going to get your libraries ship-shape first. If you're mixing apples and oranges in the same basket then it will be pragmatically impossible to figure anything out. As of course we all know. You don't say if these are your libraries or not. If they are, then I trust that you are using version-control in which case you can look back through the source-code modifications since the "last known-good" point. Or maybe you can just start by re-building everything. Also make very sure that you know which libraries and which versions thereof are, actually being referenced by the code. (Any possible source of uncertainty you can think of ... chase it down, answer it, and prove that you have the right answer.)

We can exclude the kernel from consideration because, if mutex locking was not working properly, nothing in the system would work ... the darned thing would have crashed into a kernel-panic long before now. The semantics of the kernel do change from time to time, e.g. across major-release boundaries, but fundamental interfaces do tend to remain stable, and mutual-exclusion is just about as "fundamental" as it gets.

Therefore, it is going to be an issue with user-land application code. I'd look very closely at the guts of whatever user-land libraries are used to access your driver. Many bugs like this can masquerade as what you think they are. (For example, what if the return-code really is nonzero, but the calling-sequence is busted such that your app always sees zero? You need to be able to, among other things, prove that you know what the return-code should be (tracing the value all the way from its origin to the point where it is given to userland), and then also prove that the application-side code always comes up with the correct answer in every single case.