> From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com] > > It does if you want a planned 'gental' removal to be possible.. >
There could be a lot of design options for a 'gentle' removal, such as first sending a 'prepare' event, and only then doing the flow proposed here. I do not want to address this now. > > 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... > > Hurm. That makese sense, but that isn't entirely what this patch set > does - it is rough when facing the user, but the kernel side is > actually quite gental.. Ie the RDMA CM still sends GMPs on this > shutdown path.. Looks like the various storage ULP shutdowns are > pretty gental too. > Right. Kernel removal is always gentle, because kernel ULPs are trusted to close within a finite time. > As an example, I think it is important, if you > want to hot-unplug a storage controller the admin expects a clean > storage shutdown. I think in-kernel storage drivers do that > already. IB shouldn't really be much different. > If a storage stack has user-space components, then our future 'gentle' closing will take care of that. > > Anyway, let's get this patch-set done. > > Still needs to have the locking fixed.. As pointed out (https://www.mail-archive.com/linux-rdma@vger.kernel.org/msg27023.html), this "barrier" scheme is used in several places including in the RDMA stack. If there is no functional issue with the code, we can discuss how to address this scheme systematically later. --Liran -- 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
