On Mon, Oct 25, 2010 at 01:56:31PM +0200, Menyhart Zoltan wrote: > We do not really use more advanced kernel than the 2.6.32 in a great number. > Just some test configurations up to the 2.6.36-rc6... > I have not seen this problem on recent kernels. > > I'm not sure that I can really follow your explication. Look at the callers of svc_xprt_put(). You'll see that all of them have an obvious paired svc_xprt_get(): - Any svc_xprt_put() that clears a rqstp->rq_xprt is paired with the svc_xprt_get() that originally set rqstp->rq_xprt - The svc_xprt_put() in svc_check_conn_limits() is paired with the immediately preceding svc_xprt_get() that took the xprt off the sv_tempsocks list. - Etc. *Except* for the svc_xprt_put() at the end of svc_delete_xprt(). That one you can think of as paired with the initial reference created by the kref_init() in svc_xprt_init(). So, each xprt has one special reference which keeps the xprt from being removed before svc_delete_xprt() is called. There are only two callers of svc_delete_xprt(): svc_close_xprt(), and svc_recv(). When we exit svc_xprt_enqueue(), we exit with XPT_BUSY set on the xprt in question. That flag will be cleared only by the svc_recv() call that picks up this xprt (or by svc_close_all() if nfsd shuts down before then). That prevents svc_close_xprt() from deleting the xprt, since it returns without doing anything if XPT_BUSY is already set. So the only code that could normally delete this xprt is the svc_recv() that processes the xprt. It takes the xprt off the pool->sp_sockets list before it does that. So, returning from svc_xprt_enqueue() with an xprt on ->sp_sockets that has XPT_BUSY set is safe. Think of XPT_BUSY as a kind of lock, ownership of which can pass from the svc_xprt_enqueue() that queues up an xprt to the svc_recv() that processes it, and note that an xprt can only be deleted under this XPT_BUSY lock. --b. -- 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
