On 25/08/2020 1:00, Jason Gunthorpe wrote: > On Tue, Aug 25, 2020 at 01:06:23AM +0530, Selvin Xavier wrote: >> On Tue, Aug 25, 2020 at 12:31 AM Leon Romanovsky <leon@xxxxxxxxxx> wrote: >>> >>> On Mon, Aug 24, 2020 at 11:14:31AM -0700, Selvin Xavier wrote: >>>> Driver crashes when destroy_qp is re-tried because of an >>>> error returned. This is because the qp entry was removed >>>> from the qp list during the first call. >>> >>> How is it possible that destroy_qp fail? >>> >> One possibility is when the FW is in a crash state. Driver commands >> to FW fails and it reports an error status for destroy_qp verb. >> Even Though the chances of this failure is less, wanted to avoid a >> host crash seen in this scenario. > > Drivers are not allowed to fail destroy - the only exception is if a > future destroy would succeed for some reason. Why? We already have the iterative cleanup in uverbs_destroy_ufile_hw, and combined with Leon's changes it makes sense that the actual return value is returned instead of ignored. If the subsystem handles it for DEVX, why shouldn't it handle it for other drivers?
