On 20/05/2019 22:01, Jason Gunthorpe wrote: > On Mon, May 20, 2019 at 03:39:26PM +0300, Gal Pressman wrote: >> On 20/05/2019 9:54, Leon Romanovsky wrote: >>> From: Leon Romanovsky <leonro@xxxxxxxxxxxx> >>> >>> There are two possible execution contexts of destroy flows in EFA. >>> One is normal flow where user explicitly asked for object release >>> and another error unwinding. >>> >>> In normal scenario, RDMA/core will ensure that udata is supplied >>> according to KABI contract, for now it means no udata at all. >>> >>> In unwind flow, the EFA driver will receive uncleared udata from >>> numerous *_create_*() calls, but won't release those resources >>> due to extra checks. >> >> Thanks for the fix Leon, a few questions: >> >> Some of the unwind flows pass NULL udata and others an uncleared udata (is it >> really uncleared or is it actually the create udata?), what are we considering >> as the expected behavior? Isn't passing an uncleared udata the bug here? > > Passing a NULL udata to destroy a user object would be a core code > bug. OK, there are at least two occurrences of this (create_qp and create_cq error flows) that should be fixed. > > But, I thought we fixed the error case flows that were sending in > uninited udata already? It is not null, but it is initialized and > 'empty' We fixed the cases where calls to destroy would pass uninitialized udata, this doesn't cover the create_* error flows that call destroy, which is a bug IMO.
