From: Yann Droneaud <ydroneaud-RlY5vtjFyJ3QT0dZR+AlfA@public.gmane.org>
To: Sagi Grimberg <sagig-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>,
Shachar Raindel <raindel-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>,
Eli Cohen <eli-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>,
Haggai Eran <haggaie-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>,
Roland Dreier <roland-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Yann Droneaud <ydroneaud-RlY5vtjFyJ3QT0dZR+AlfA@public.gmane.org>,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: [PATCH v1 0/5] IB/core: extended query device caps cleanup for v3.19
Date: Thu, 29 Jan 2015 18:59:57 +0100 [thread overview]
Message-ID: <cover.1422553023.git.ydroneaud@opteya.com> (raw)
Hi,
Following discussions in thread "[PATCH v3 06/17] IB/core: Add support
for extended query device caps" [1] and further comments on previous
patch in "[PATCH 3/4] IB/uverbs: ex_query_device: check request's
comp_mask" thread [2], I'm proposing an updated patchset to implement
a slighly different behavior to handle the request parameters in
ib_uverbs_ex_query_device() in order to restore the current behavior
of ib_copy_to_udata().
I think we found an agreement on the scheme to be implemented in
Haggai Eran's response [3]:
- input's comp_mask is currently not used, so it must be 0;
- the response buffer size is checked so that the base answer
can be returned without being truncated;
- the extended feature (odp) information are returned
if, and only if, there's enough space in the response buffer,
allowing older programs to get only the features they would
expect. Newer programs are expected to provide more space,
but as the response's comp_mask will describe only the available
fields, newer program cannot be surprized to not get information
when run on older kernel (if we want to support this use case).
I feel even more confident this behavior would allow a better
maintainability. Additionally, it's still looking more like the
behavior already implemented by other InfiniBand/RDMA kernel <->
userspace interfaces.
I hope this would go in v3.19 before its release so that the extended
QUERY_DEVICE uverbs won't hurt us being part of an official release:
in it's current shape it won't be easy to support it.
Regards.
Changes from v0 [4]
- don't use input's comp_mask to conditionnaly build the response
- ensure input's comp_mask is set 0
[1] http://mid.gmane.org/1418733236.2779.26.camel-RlY5vtjFyJ3QT0dZR+AlfA@public.gmane.org
[2] http://mid.gmane.org/063956366559d6919693aabb324bab83d676bc28.1421931555.git.ydroneaud-RlY5vtjFyJ3QT0dZR+AlfA@public.gmane.org
[3] http://mid.gmane.org/54C902E4.5010600-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org
[4] http://mid.gmane.org/cover.1421931555.git.ydroneaud-RlY5vtjFyJ3QT0dZR+AlfA@public.gmane.org
Yann Droneaud (5):
IB/uverbs: ex_query_device: answer must not depend on request's
comp_mask
IB/uverbs: ex_query_device: check request's comp_mask
IB/uverbs: ex_query_device: answer must depend on response buffer's
size
IB/uverbs: ex_query_device: no need to clear the whole structure
IB/core: ib_copy_to_udata(): don't silently truncate response
drivers/infiniband/core/uverbs_cmd.c | 39 +++++++++++++++++++++++++-----------
include/rdma/ib_verbs.h | 5 +----
2 files changed, 28 insertions(+), 16 deletions(-)
--
2.1.0
next reply other threads:[~2015-01-29 17:59 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-29 17:59 Yann Droneaud [this message]
[not found] ` <cover.1422553023.git.ydroneaud-RlY5vtjFyJ3QT0dZR+AlfA@public.gmane.org>
2015-01-29 17:59 ` [PATCH v1 1/5] IB/uverbs: ex_query_device: answer must not depend on request's comp_mask Yann Droneaud
[not found] ` <24ceb1fc5b2b6563532e5776b1b2320b1ae37543.1422553023.git.ydroneaud-RlY5vtjFyJ3QT0dZR+AlfA@public.gmane.org>
2015-01-29 18:28 ` Jason Gunthorpe
[not found] ` <20150129182800.GH11842-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2015-01-29 18:43 ` Yann Droneaud
[not found] ` <1422557009.3133.172.camel-RlY5vtjFyJ3QT0dZR+AlfA@public.gmane.org>
2015-01-29 19:18 ` Jason Gunthorpe
[not found] ` <20150129191801.GM11842-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2015-01-29 20:50 ` Yann Droneaud
[not found] ` <1422564638.3133.198.camel-RlY5vtjFyJ3QT0dZR+AlfA@public.gmane.org>
2015-01-29 21:12 ` Jason Gunthorpe
[not found] ` <20150129211256.GA22099-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2015-02-05 2:54 ` Weiny, Ira
[not found] ` <2807E5FD2F6FDA4886F6618EAC48510E0CC12C30-8k97q/ur5Z2krb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
2015-02-05 8:26 ` Haggai Eran
[not found] ` <54D32933.8080307-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2015-02-07 0:52 ` Weiny, Ira
[not found] ` <2807E5FD2F6FDA4886F6618EAC48510E0CC201F7-8k97q/ur5Z2krb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
2015-02-08 7:27 ` Haggai Eran
2015-01-29 20:42 ` Yann Droneaud
2015-01-29 21:59 ` Yann Droneaud
[not found] ` <1422568741.3133.247.camel-RlY5vtjFyJ3QT0dZR+AlfA@public.gmane.org>
2015-01-29 23:17 ` Roland Dreier
[not found] ` <CAG4TOxN4DpTMMsCM-1oe6-w+5xYR4YHdJeL7p2nQpUy9gYCSjA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-01-30 17:26 ` Yann Droneaud
[not found] ` <1422638760.3133.260.camel-RlY5vtjFyJ3QT0dZR+AlfA@public.gmane.org>
2015-01-31 20:09 ` Or Gerlitz
[not found] ` <CAJ3xEMhDtD7MpJ+1Y3z2yMpTrb9C5SaUa94E8xpVLHN4pHe3fw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-03-02 14:08 ` Yann Droneaud
2015-02-01 11:25 ` Haggai Eran
2015-02-01 8:04 ` Haggai Eran
2015-02-01 7:39 ` Haggai Eran
2015-01-29 17:59 ` [PATCH v1 2/5] IB/uverbs: ex_query_device: check " Yann Droneaud
[not found] ` <335da45738872e446f63db338ca766a34608c90a.1422553023.git.ydroneaud-RlY5vtjFyJ3QT0dZR+AlfA@public.gmane.org>
2015-01-29 18:36 ` Jason Gunthorpe
[not found] ` <20150129183648.GI11842-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2015-01-29 19:22 ` Yann Droneaud
2015-01-29 20:24 ` Jason Gunthorpe
2015-02-01 8:12 ` Haggai Eran
[not found] ` <54CDDFE4.7030003-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2015-02-01 11:55 ` Yann Droneaud
2015-01-29 18:00 ` [PATCH v1 3/5] IB/uverbs: ex_query_device: answer must depend on response buffer's size Yann Droneaud
[not found] ` <a7b2b5adb3b207ec2a4330067a03ce7e4c2225aa.1422553023.git.ydroneaud-RlY5vtjFyJ3QT0dZR+AlfA@public.gmane.org>
2015-01-29 18:38 ` Jason Gunthorpe
[not found] ` <20150129183839.GJ11842-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2015-01-29 19:25 ` Yann Droneaud
2015-02-01 8:38 ` Haggai Eran
2015-01-29 18:00 ` [PATCH v1 4/5] IB/uverbs: ex_query_device: no need to clear the whole structure Yann Droneaud
[not found] ` <0b646f62e9272bc962a1ff6ff03ad9523b454dfe.1422553023.git.ydroneaud-RlY5vtjFyJ3QT0dZR+AlfA@public.gmane.org>
2015-01-29 18:39 ` Jason Gunthorpe
2015-02-01 8:45 ` Haggai Eran
2015-01-29 18:00 ` [PATCH v1 5/5] IB/core: ib_copy_to_udata(): don't silently truncate response Yann Droneaud
[not found] ` <c69af8952bf25fdbcdfc527b0636bc3177798b95.1422553023.git.ydroneaud-RlY5vtjFyJ3QT0dZR+AlfA@public.gmane.org>
2015-02-01 8:47 ` Haggai Eran
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1422553023.git.ydroneaud@opteya.com \
--to=ydroneaud-rly5vtjfyj3qt0dzr+alfa@public.gmane.org \
--cc=eli-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org \
--cc=haggaie-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org \
--cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=raindel-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org \
--cc=roland-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=sagig-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).