On Fri, 2009-11-20 at 17:36 -0500, J. Bruce Fields wrote: > On Fri, Nov 20, 2009 at 05:24:43PM -0500, Chuck Lever wrote: > > On Nov 20, 2009, at 5:05 PM, J. Bruce Fields wrote: > >> On Fri, Nov 20, 2009 at 04:50:34PM -0500, Chuck Lever wrote: > >>> I can't reproduce any problems with the rpcbind upcall here. Do you > >>> have anything more specific? > >> > >> Isn't there an rpc ping in rpc_bind_new_program? > > > > Hrm, I suppose there is. That's weird, clearly I didn't see the > > rpc_ping() call, even though I was looking for it when I wrote this. A > > GFP_KERNEL memory allocation can sleep too, can't it? > > Yes. I'd be really curious to know how that got through--if > CONFIG_DEBUG_SPINLOCK_SLEEP can't catch a case that cut-and-dried, then > it's totally broken.... > > --b. Furthermore, there are memory allocations galore in the call to rpc_create(). Any attempt to run that while holding a spinlock should cause CONFIG_DEBUG_SPINLOCK_SLEEP to throw a series of fits... Trond -- 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
