[EMAIL PROTECTED] wrote:
Garrett D'Amore wrote:
Thomas De Schampheleire wrote:
Hi,
The timeout(9F) manpage says:
"The function called by timeout() must adhere to the same
restrictions as a driver soft interrupt handler.
The function called by timeout() is run in interrupt context
and must not sleep or call other functions that might sleep."
Does this mean that a function which is called using a timeout, cannot
use mutex_enter() ?
No. But you should not call cv_wait, or its brethren.
You should not attempt to acquire a lock which will be held by other
functions calling cv_wait, or its brethren. (There are ways to do
that safely, but it requires a fair bit of effort to make sure you do
it safely.)
Maybe above statements could be added in the man page?
Since timeout is a public API, new driver developers might run into this
situation without knowing the constraint of timeout API. At least, as a
QE engineer, I have encountered this situation before. Maybe it's worth
filing a bug against man page for timeout(9F).
But it is documented in the manual page:
The timeout() function schedules the specified function to
be called after a specified time interval. The exact time
interval over which the timeout takes effect cannot be
guaranteed, but the value given is a close approximation.
The function called by timeout() must adhere to the same
restrictions as a driver soft interrupt handler.
The delay(9F) function calls timeout(). Because timeout() is
subject to priority inversion, drivers waiting on behalf of
processes with real-time constraints should use
cv_timedwait(9F) rather than delay().
There's a lot more information in the soft interrupt manual page
(ddi_add_softintr)
Sorry, maybe I misunderstand your meaning, what I thought is we should
add Garrett's statement in the timeout(9F):
You should not call cv_wait, or its brethren.
You should not attempt to acquire a lock which will be held by other
functions calling cv_wait, or its brethren. (There are ways to do
that safely, but it requires a fair bit of effort to make sure you do
it safely.)
As my understand, cv_wait and its brethren could be called from a
interrupt context, including a soft interrupt context.
For this reason, when people read the timeout(9F), he will think since
timeout handler's context is considered as a soft interrupt context, it
will be safe if we called it in the timeout handler.
But I did encounter the situation that the timeout handler attempts to
acquire a lock which held by other functions calling cv_timedwait, and
that caused the system hang.
Since it could cause a serious issue, if we can add a statement like
Garrett mentioned, it will help new developers a lot.
--
Cheers,
----------------------------------------------------------------------
Oliver Yang | [EMAIL PROTECTED] | x82229 | Work from office
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
