On Wed, May 06, 2015 at 07:52:03PM +0530, Devesh Sharma wrote: > >> Should we check for EBUSY explicitly? other then this is an error in > >> vendor specific ib_dealloc_pd() > > > > Any error return means ib_dealloc_pd() has failed, right? Doesn’t that > > mean the PD is still allocated, and could cause problems later? > > Yes, you are correct, I was thinking ib_dealloc_pd() has a refcount > implemented in the core layer, thus if the PD is used by any resource, > it will always fail with -EBUSY. .. and it will not be freed, which indicates a serious bug in the caller, so the caller should respond to the failure with a BUG_ON or WARN_ON. > .With emulex adapter it is possible to fail dealloc_pd with ENOMEM or > EIO in cases where device f/w is not responding etc. this situation do > not represent PD is actually in use. This is a really bad idea. If the pd was freed and from the consumer's perspective everything is sane then it should return success. If the driver detects an internal failure, then it should move the driver to a failed state (whatever that means, but at a minimum it means the firmware state and driver state must be resync'd), and still succeed the dealloc. There is absolutely nothing the caller can do about a driver level failure here, and it doesn't indicate a caller bug. Returning ENOMEM for dealloc is what we'd call an insane API. You can't have failable memory allocations in a dealloc path. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
