Re: [PATCH 1/2] Introduce mutex_lock_timeout

[Ingo Oeser <ioe-lkml@rameria.de>]

Hi Matthew,

On Saturday, 25. November 2006 04:55, Matthew Wilcox wrote:
> No comment on this?

Ok, I will comment it. But I'll NOT comment on the implementation.
I'll prove you instead, that timout based locking is non-sense.

What should the timout mutex_timeout() prevent? Usually the answer is 
"if sombody hangs on a mutex forever ...?" and people tell you "ok, that is
a deadlock -> fix your code not to deadlock instead."
Then they tell you "Ok, but if somebody takes a mutex too long?"
and people will answer "ok, then this is a livelock -> fix your code not to 
livelock."

Another answer is "I like to block until sth. happens wihin a specific time frame" 
-> fine, this is accomplished by wait_event_timout (which blocks only you and 
not every other user of the mutex).

So you see there is no real need for this and having it yould introduce an 
instrument for hiding such bugs.

When you talk with untrusted binary only code such locks with timeouts
are sometimes needed, since you don't know the locking rules within
such code.

As this is not the case for kernel code, it is simply not needed.

I know why ACPI needs it (API requirement) and I think the qla???-driver
just needs to be fixed to work without it and nobody did it yet.


Regards

Ingo Oeser, who actually IS the implementation of mutex_lock_timeout()[1]

[1] Everytime (since 2001) someone suggest it, I discuss it away :-)

Attachment: pgpU0lP4Svpjj.pgp
Description: PGP signature