Not quite.
Scenario which breaks this:
nfsd/lockd checks the redo list, it's empty.
nfsd/lockd enters svc_recv()
exp_addclient moves a request onto the redo list.
We need some way of waking up the nfsd/lockd thread when this happens. I
thought about pushing the received rqstp back up the pipeline so it 'comes out
of svc_recv()' again, but that doesn't seem feasible, especially in the case of
TCP.
The signal handling in there frightens me, but sending a signal is the best way
to do it, because the only alternative seems to be reducing the timeout in
svc_recv from MAX_SCHEDULE_TIMEOUT to something small, and repeatedly polling
the redo lists.
I'll investigate sending SIGIO to a process in svc_recv to make it check its
redo list again.
My brain hurts...
---- ---- ----
David Woodhouse David.Woodhouse@mvhi.com Office: (+44) 1223 810302
Project Leader, Process Information Systems Mobile: (+44) 976 658355
Axiom (Cambridge) Ltd., Swaffham Bulbeck, Cambridge, CB5 0NA, UK.
finger dwmw2@ferret.lmh.ox.ac.uk for PGP key.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/