On Tue, Mar 13, 2018 at 3:09 PM, Ruhl, Michael J <michael.j.ruhl@xxxxxxxxx> wrote: >> -----Original Message----- >> From: linux-rdma-owner@xxxxxxxxxxxxxxx [mailto:linux-rdma- >> owner@xxxxxxxxxxxxxxx] On Behalf Of Jason Gunthorpe >> Sent: Monday, March 12, 2018 4:37 PM >> To: Ruhl, Michael J <michael.j.ruhl@xxxxxxxxx> >> Cc: Doug Ledford <dledford@xxxxxxxxxx>; Leon Romanovsky >> <leonro@xxxxxxxxxxxx>; RDMA mailing list <linux-rdma@xxxxxxxxxxxxxxx>; >> Matan Barak <matanb@xxxxxxxxxxxx> >> Subject: Re: [PATCH rdma-next 05/12] IB/uverbs: Safely extend existing >> attributes >> >> On Mon, Mar 12, 2018 at 08:34:11PM +0000, Ruhl, Michael J wrote: >> >> > I still think that this flag should be split into two pieces, so I can avoid the >> > ib_is_buffer_cleared() if I don't need it. >> >> You always need it. >> >> It is part of ABI compatability, if you declare that a struct can be >> extended then you have to check that someone isn't using a new >> extension with an old kernel. > > Ok, I think I misunderstood what this is being used for. I was thinking > that it was just part of testing the size of the data structure being used. > > From what you are saying this is for specific instances of variably sized > (extended) data structures? > This is used when a data structure could be extended in the future. Therefore, the kernel needs to make sure it understands all the relevant information. Similarly to the previous comp_mask approach, we assume that all unknown data should be zeroed. >> Globally we define that as meaning the unknown part of the struct is >> 0. > > So this will effectively force the caller to understand that the core doesn't > understand any of the "extra" info? > > I think I understand the difference between uverbs_copy_from_or_zero() > and uverbs_copy_from() as well. > > The or _zero() will only copy the minimum size only (spec vs. user size). > Not the minimum size, but the kernel known size. The parser makes sure the following holds: (a) The user gave at least min_size amount of data (b) If user_size > kernel_known size, all unknown size is zeroed. > So this will require extra code in the handler to make sure that it understands > that the user size may be smaller than the "expected" (spec) data size? > Nope. You need to design your data structure such that zero values (at least all fields above min_size) mean "don't care". If you do this, you just call uverbs_copy_from_or_zero and get the appropriate data to your data structure. We don't want specialized code in your handler to handle this :) >> If this is a problem for your API then you are probably not designing >> it properly for extension.. > > Since I am not fully understanding the use of this feature, I doubt it is a > problem for my API. :) > It should only be used when you want to extend a data structure in the future (rather than just add another attribute). This could be useful logically (an attribute belongs to the same structure) or for performance (more attributes == more work for the parser). >> I actually don't expect MIN_SZ to be used very often. > > I hope not. :) > > Thanks > > Mike > Regards, Matan >> 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 > -- > 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 -- 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
