On Mon, Mar 12, 2018 at 5:49 PM, Ruhl, Michael J <michael.j.ruhl@xxxxxxxxx> wrote: >> -----Original Message----- >> From: linux-rdma-owner@xxxxxxxxxxxxxxx [mailto:linux-rdma- >> owner@xxxxxxxxxxxxxxx] On Behalf Of Leon Romanovsky >> Sent: Thursday, March 8, 2018 12:19 PM >> To: Doug Ledford <dledford@xxxxxxxxxx>; Jason Gunthorpe >> <jgg@xxxxxxxxxxxx> >> Cc: Leon Romanovsky <leonro@xxxxxxxxxxxx>; RDMA mailing list <linux- >> rdma@xxxxxxxxxxxxxxx>; Aviad Yehezkel <aviadye@xxxxxxxxxxxx>; Boris >> Pismenny <borisp@xxxxxxxxxxxx>; Matan Barak <matanb@xxxxxxxxxxxx>; >> Yishai Hadas <yishaih@xxxxxxxxxxxx> >> Subject: [PATCH rdma-next 02/12] IB/uverbs: Move to new headers and >> make naming consistent >> >> From: Matan Barak <matanb@xxxxxxxxxxxx> >> >> Use macros to make names consistent in ioctl() uAPI: >> The ioctl() uAPI works with object-method hierarchy. The method part >> also states which handler should be executed when this method is called >> from user-space. Therefore, we need to tie method, method's id, method's >> handler and the object owning this method together. >> Previously, this was done through explicit developer chosen names. >> This makes grepping the code harder. Changing the method's name, >> method's handler and object's name to be automatically generated based >> on the ids. >> >> The headers are split in a way so they be included and used by >> user-space. One header strictly contains structures that are used >> directly by user-space applications, where another header is used for >> internal library (i.e. libibverbs) to form the ioctl() commands. >> Other header simply contains the required general command structure. >> >> Reviewed-by: Yishai Hadas <yishaih@xxxxxxxxxxxx> >> Signed-off-by: Matan Barak <matanb@xxxxxxxxxxxx> >> Signed-off-by: Leon Romanovsky <leonro@xxxxxxxxxxxx> >> --- >> diff --git a/drivers/infiniband/core/uverbs_std_types.c >> b/drivers/infiniband/core/uverbs_std_types.c >> index df1360e6774f..99f971b6cc67 100644 >> --- a/drivers/infiniband/core/uverbs_std_types.c >> +++ b/drivers/infiniband/core/uverbs_std_types.c >> @@ -210,15 +210,24 @@ static int >> uverbs_hot_unplug_completion_event_file(struct ib_uobject_file *uobj_ >> return 0; >> }; >> >> >> @@ -298,7 +311,8 @@ static int uverbs_create_cq_handler(struct ib_device >> *ib_dev, >> goto err_event_file; >> } >> >> - obj = container_of(uverbs_attr_get(attrs, CREATE_CQ_HANDLE)- >> >obj_attr.uobject, >> + obj = container_of(uverbs_attr_get(attrs, >> + > > uverbs_attr_get() can return ERR_PTR(-ENOENT). > > Is this a concern for the use of the container_of() and the obj? > If that's a MANDATORY attribute, you don't need to check. The parser has validated that this object indeed exist and that it's of the right type. > Thanks, > > Mike > Regards, Matan > > -- > 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
