views:

106

answers:

3

The print comes when the 'current lock owner' of a kernel resource is current CPU. I don't know what could lead to this condition. Couldn't find much on the net. Anyone debugged this?

A: 

Debug? You mean, need to know where in the source?

raghava
Thanks. But I'd already 'grep'ed for it. I was looking for the reason as to what eventuality would cause this condition. Ultimately, was able to figure it out.
Harty
A: 

Ok, Got it.

This typically happens when you enter the same function twice, referencing to the same kernel resource, in a single execution context of the linux kernel (e.g. a single instance of softIRQ, etc). The way out of this is to make sure you don't re-enter the function twice in the same execution context. It's a bug in your code if this happens.

Harty
A: 

It is a diagnostic message intended to bring a possible deadlock to attention.

In this particular case there is a transmit queue that is protected by a spinlock. In addition to this lock, the transmit queue also maintains an "owner" field which contains a CPUID which is set when this spinlock is held.

As you probably know, a spinlock will always spin on a CPU if the lock requested has already been taken.

So at this location the code checks if the cpu is the same one that locked the spinlock.

If its not on the same CPU it performs the operations that might need the lock to be taken.

On the otherhand if its the same CPU, something is not right i.e. we should actually be spinning waiting for the lock. Probably we got here due to an incorrect interrupt handler/bottom half.

Since this indicates a potential deadlock a diagnostic message is printed :).

Amit Mitkar