On Wed, 2010-12-08 at 11:23 -0700, Jason Gunthorpe wrote: > > Sorry, I still need some clarifications... > > When you say deadlocks, do you mean when calling malloc with a lock or > > when overflowing a socket receive buffer? > > For the second case, when we use netlink_unicast, the skbuff is sent and > > freed. It is transferred to the userspace's socket using netlink_sendskb > > and accumulated in its recv buff. > > > > Are you referring to a deadlock there? I still fail to see the issue. > > Why would the kernel socket recv buff reach a limit? Could you please > > elaborate? > > Netlink is all driven from user space syscalls.. so it looks like > > sendmsg() > [..] > ibnl_rcv_msg > cma_get_stats > [..] > ibnl_unicast > [..] > netlink_attachskb > (now we block on the socket recv queue once it fills) > > The deadlock is that userspace is sitting in sendmsg() while the > kernel is sleeping in netlink_attachskb waiting for the recvbuf to > empty. > > User space cannot call recvmsg() while it is in blocked in sendmsg() > so it all goes boom. >
Oh, now I see what you mean. I thought you meant the recv buffer in the netlink socket... But I'm using MSG_DONTWAIT when calling netlink_unicast, so attachskb shouldn't block. I also tested that. I do agree that freeing the skb and simply giving up is not the best we can do, so we can try and send as much as we can instead, but either way, a deadlock shouldn't occur. Nir -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
