> From: linux-rdma-owner@xxxxxxxxxxxxxxx [mailto:linux-rdma- > owner@xxxxxxxxxxxxxxx] On Behalf Of Jason Gunthorpe > > I have no real problem with that, it would be nice to have an answer > to the uverbs vs ucma removal ordering question and the basic issue of > if we even want to do this so async before merging the driver patch > that enables it.. > I don't think that the order matters. When you do a surprise removal, you disconnect the application from both ucma and uverbs device references. In this state, the only thing that the application can do is close all handles. It doesn't matter if you succeed closing a resource on a device that is still accessible, or "close" an already destroyed resource... The primary reason for device surprise removal is to recover from device fatal errors or PCI errors. A quick asynchronous device recovery is exactly what we need, as there is nothing that the application can do more at this state. This is the most pressing issue that this patch-set solves. For the administrative removal use case, can consider providing applications a grace period before disconnecting them in a future patch set. Even here, however, I am not sure that if an administrator decided to remove a device while there are still active applications, we should stall his request. Anyway, let's get this patch-set done. > > The first 4 you already review and acked the fifth is in mlx4_ib and has no > > comments to fix so far - some months in the list. > > Personally, I'm not looking much at drivers.. > > 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
