VFS: fix short select(2) timeouts
Some select queries require a response from device drivers. If a select call is nonblocking (with a zero timeout), the response to the caller may have to be deferred until all involved drivers have responded to the initial query. This is handled just fine. However, if the select call has a timeout that is so short that it triggers before all the involved drivers have responded, the resulting alarm would be discarded, possibly resulting in the call blocking forever. This fix changes the alarm handler such that if the alarm triggers too early, the select call is further handled as though it was nonblocking. This fix resolves a test77 deadlock on really slow systems. Change-Id: Ib487c8fe436802c3e11c57355ae0c8480721f06e
This commit is contained in:
parent
fefec20e6b
commit
de95c84d3e
1 changed files with 4 additions and 2 deletions
|
@ -755,8 +755,10 @@ void select_timeout_check(minix_timer_t *timer)
|
|||
if (se->requestor == NULL) return;
|
||||
if (se->expiry <= 0) return; /* Strange, did we even ask for a timeout? */
|
||||
se->expiry = 0;
|
||||
if (is_deferred(se)) return; /* Wait for initial replies to CDEV_SELECT */
|
||||
if (!is_deferred(se))
|
||||
select_return(se);
|
||||
else
|
||||
se->block = 0; /* timer triggered "too soon", treat as nonblocking */
|
||||
}
|
||||
|
||||
|
||||
|
|
Loading…
Reference in a new issue