On Thu, Apr 16, 2015 at 10:02:46AM -0700, Roland Dreier wrote: > On Thu, Apr 16, 2015 at 9:44 AM, Jason Gunthorpe > <jguntho...@obsidianresearch.com> wrote: > >> We can give client->add() callback a return value and make > >> ib_register_device() return -ENOMEM when it failed, just wondering > >> why we don't do this at first, any special reason? > > > No idea, but having ib_register_device fail and unwind if a client > > fails to attach makes sense to me. > > It seems a bit unfriendly to fail an entire device if one ULP has a > problem. Let's say you have a system whose main network connection is > IPoIB. Would you want that connection to come up even if, say, the > NFS/RDMA server fails to find the memory registration type it likes?
That is true, but we also never test any of the cases where one expected ULP fails to load but another one needs it. Like IPoIB needs sa_query, for instance. I'm not saying ULPs should error for soft reasons, like your NFS example, this unwind would be for OOM, or other 'impossible' class errors. That said, the driver core does not fail a bus driver register if a client probe fails (we could copy this), but it also doesn't just silently eat the error code either. What about ib_register_client? If any add's fail should it unwind and fail upwards? Jason -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/