On Tue, Aug 01, 2017 at 03:38:15PM -0500, Chien Tin Tung wrote: > > Presumably the iwpmd kernel side is designed to handle the locking > > right to avoid deadlocks. > > Please stop using the word deadlock in relation to usage of 1-shot > retry in ibnl_unicast. It does not and will not cause deadlock period. > It will wait for a buffer within timeout value but that's it. I think you are arguing semantics here. My understanding with netlink (and it has been years since I've looked) is that there is way for netlink callbacks to be run within the context of the user thread calling send(). In this case calling blocking netlink_unicast within such a callback will 'deadlock', as netlink_unicast waits for the current thread to call recv(), which can never happen. We still call this a deadlock even though the sndtimer rescues the overall system, as the system was in a deadlocked state for a time. > > Leon is also right that every other user of netlink_unicast in rdma > > should be using the non-blocking version. > > In Mustafa's patch, there are calls to both versions of ibnl_unicast. > There are situations where the retry version of ibnl_unicast > is not desirable, note I didn't say wrong. I haven't studied closely, but if any of those blocking netlink_unicasts are in netlink callbacks, it would need very careful inspection to determine if that is OK. > buffers available. If a buffer does not become available within > timeout parameter, you have bigger problems. Well.. It is problematic to create that situation in the first place. Usually you would never run unsolicited netlink traffic and request/response traffic over the same socket. Having the kernel randomly drop responses because the sndbuf is full of unsolicited traffic is really problematic. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
