My client hangs on xfstests generic/074 on a krb5 mount, and I've found that the linux server is silently discarding one or more RPCs because the GSS sequence numbers are outside the sequence window. The reason is that sometimes one of the nfsd threads takes a long time between receiving the RPC and then checking if the sequence is within the window. That delay allows the other nfsd threads to quickly move the window forward out of range. If the server discards the RPC then that causes then the client to wait forever for a response or until the connection is reset. By inserting tracepoints, I think I found two sources of delay: 1) gss_svc_searchbyctx() uses dup_to_netobj() which has a kmemdup with GFP_KERNEL. It does this because presumabely it doesn't know how big the context handle should be. 2) gss_verify_mic() uses make_checksum() which eventually gets to crypto_alloc_hash() with GFP_KERNEL. For the first delay, can we assume the context handles are all going to be the same size? It looks like the handle is assigned by the server, so it seems like we should be able to know beforehand how large they are. For the second allocation -- I haven't thrown a lot of thought into what could be done to fix it.. seems a bit tricker. I'll think about both of these a bit more, but I thought in the meantime to ask if anyone has thoughts about this problem. Maybe we can to the sequence check before verify_mic -- but then a message that fails verification could flip the sequence bit.. Ben -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
