On 5/14/2018 11:27 PM, Jason Gunthorpe wrote:
On Thu, May 03, 2018 at 04:37:03PM +0300, Leon Romanovsky wrote:
From: Matan Barak <matanb@xxxxxxxxxxxx>
Adding uverbs_copy_from_and_alloc which allocates and copies enough
space to copy the user-space attribute. This function could return a
PTR_ERR. The user is required to free the memory by using kfree().
The length of the allocated space could be queried by using
uverbs_attr_get_len.
Signed-off-by: Matan Barak <matanb@xxxxxxxxxxxx>
Signed-off-by: Leon Romanovsky <leonro@xxxxxxxxxxxx>
include/rdma/uverbs_ioctl.h | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/include/rdma/uverbs_ioctl.h b/include/rdma/uverbs_ioctl.h
index 9aa05bfc89b7..24689f3fe454 100644
+++ b/include/rdma/uverbs_ioctl.h
@@ -650,6 +650,38 @@ static inline int _uverbs_copy_from_or_zero(void *to,
return 0;
}
+static inline void *uverbs_copy_from_and_alloc(const struct uverbs_attr_bundle *attrs_bundle,
+ size_t idx, gfp_t flags)
+{
+ int len = uverbs_attr_get_len(attrs_bundle, idx);
+ void *to;
+ int ret;
+
+ if (len < 0)
+ return ERR_PTR(len);
+
+ /* It doesn't make any sense to re-allocate and copy if it was already
+ * done by the parser.
+ */
+ ret = uverbs_validate_actual_spec_debug(attrs_bundle, idx, spec,
+ spec->type == UVERBS_ATTR_TYPE_PTR_IN &&
+ spec->flags & ~UVERBS_ATTR_SPEC_F_ALLOC_AND_COPY);
+ if (ret)
+ return ERR_PTR(ret);
+
+ to = kmalloc(len, flags);
+ if (!to)
+ return ERR_PTR(-ENOMEM);
+
+ ret = _uverbs_copy_from(to, attrs_bundle, idx, len);
+ if (ret) {
+ kfree(to);
+ return ERR_PTR(ret);
+ }
+
+ return to;
+}
This is really too big to be an inline
Can we safely use kmalloc with user arguments? Eg this could be as
large as 64k which is a higher order allocation under user
control.. Should it be kvmalloc/kvfree or something?
The above API is not really used in this series, was some place holder
for future usage, won't be part of V1.
The parser code around UVERBS_ATTR_SPEC_F_ALLOC_AND_COPY will use
kvmalloc/kvfree in V1 as you pointed here, thanks.
--
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
