On Wed, Mar 28, 2018 at 09:34:21PM +0300, Leon Romanovsky wrote: > On Wed, Mar 28, 2018 at 12:29:54PM -0600, Jason Gunthorpe wrote: > > On Wed, Mar 28, 2018 at 09:22:25PM +0300, Leon Romanovsky wrote: > > > > > > rdma_addr_size(&ctx->cm_id->route.addr.dst_addr) is not user > > > > input, it is part of the kernel state at this point. Right? > > > > > > > > Can rdma_addr_size even return 0 at this point? > > > > > > > > If yes, then we should return EINVAL, but that is to make the API sane > > > > for the user not to protect the kernel. > > > > > > I'm not near code now, but from what I remember, the user can call to > > > rdma_create_id(), it will create new ctx->cm_id but with addr zeroed, > > > because ucma_alloc_ctx() uses kzalloc. > > > > > > After that this user will call it ucma_query() and will hit this flow. > > > > Okay, sure, but the memcpy(a,b,0) isn't going to trigger KASN.. > > I disagree with you, but it doesn't matter here. What do you mean disagree? Do actually know this triggers KASN or are you just guessing? Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
