On Mon, Oct 28, 2019 at 10:43:51AM -0300, Jason Gunthorpe wrote: > On Mon, Oct 28, 2019 at 03:19:17PM +0200, Leon Romanovsky wrote: > > On Mon, Oct 28, 2019 at 10:13:19AM -0300, Jason Gunthorpe wrote: > > > On Sun, Oct 20, 2019 at 10:15:59AM +0300, Leon Romanovsky wrote: > > > > diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c b/drivers/infiniband/ulp/srpt/ib_srpt.c > > > > index daf811abf40a..e66366de11e9 100644 > > > > +++ b/drivers/infiniband/ulp/srpt/ib_srpt.c > > > > @@ -2609,7 +2609,7 @@ static int srpt_cm_handler(struct ib_cm_id *cm_id, > > > > case IB_CM_REJ_RECEIVED: > > > > srpt_cm_rej_recv(ch, event->param.rej_rcvd.reason, > > > > event->private_data, > > > > - IB_CM_REJ_PRIVATE_DATA_SIZE); > > > > + event->private_data_len); > > > > > > So, I took a look and found a heck of a lot more places assuming the > > > size of private data that really should be checked if we are going to > > > introduce a buffer length here. > > > > But we are not interested to make it dynamic, "private_data_len" has > > constant size according to IBTA spec, I just don't want users to be > > aware of this. > > > > Why should we add the below checks if it wasn't before? > > Why are we doing any of this then? The final goal will be to present all CM messages as binary blobs with access through specific GET/SET helpers, those including access to private data. It is needed to completely eliminate be32 madness in IB/core code. Thanks > > Jason
