On Mon, Feb 19, 2018 at 05:46:43PM -0600, Steve Wise wrote: > > > > On Mon, Feb 19, 2018 at 05:17:29PM -0600, Steve Wise wrote: > > > > > > Wondering if keys should not be disclosed for security? > > > > > > > > > + RDMA_NLDEV_ATTR_RES_IOVA, /* u64 */ > > > > > > > > What is this supposed to be ? > > > > > > > > > > It is the address or 64b value used in ib_sge.addr field of SGEs. > mr.iova > > > defines the beginning address of the MR. > > > > But kernel MRs can be fragmented, and we will have fragmented user MRs > > soon too I think. > > From the perspective of the peer application targeting specific areas in the > MR, it is linear and contiguous, from mr.ivoa to mr.iova+mr.length-1. The > pages backing that mr are not necessarily contiguous. > > > > > > > We are talking about some MRs now with very complicated layouts, and > > > > support those in the kernel too. > > > > > > > > We already can't leak a kernel pointer here.. Not sure we should even > > > > talk about pointers here at all.. > > > > > > It is part of what an application provides to register a MR. It will > help > > > in debugging an application to verify that the MR registered has the > correct > > > iova. > > > > Still, worried about security, exposing pointers is frowned on these > > days. > > > > I can remove IOVA, if that is your recommendation. Or you can require some CAP_ADMIN privilege to return IOVA among other MR fields. > > > Certainly no for any kernel MR. > > > > > > > + RDMA_NLDEV_ATTR_RES_MRLEN, /* u64 */ > > > > > + RDMA_NLDEV_ATTR_RES_PGSIZE, /* u32 */ > > > > > > > > Why pgsize? > > > > > > Why dump it? Because the page size of a MR isn't necessarily the host > > page > > > size. > > > > But the page size can be variable inside a MR, seems like a weird > > thing to report. > > I don't understand. Each MR has a page_size that represents the size of > each of the entries in the page list that composes the MR. Perhaps you're > thinking about some block-list MR or some newer variant that I'm not > familiar with? All pages in a user MR have the same page size. Ditto for > REG_MRs, or at least the ones I'm familiar with (cxgb4 supported). > > What do you think _should_ be displayed for each MR that is not > provider-specific (we'll address provider-specific stuff in a subsequent > patch series)? The attribute list I have included is mainly driven off of > each structure in the kernel. In this case struct ib_mr. > > Steve >
Attachment:
signature.asc
Description: PGP signature
