linux-api.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

             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).