2005-07-08 04:57:13 +04:00
|
|
|
/*
|
|
|
|
* Copyright (c) 2005 Topspin Communications. All rights reserved.
|
2006-01-31 01:29:21 +03:00
|
|
|
* Copyright (c) 2005, 2006 Cisco Systems. All rights reserved.
|
2005-08-11 10:03:10 +04:00
|
|
|
* Copyright (c) 2005 Mellanox Technologies. All rights reserved.
|
|
|
|
* Copyright (c) 2005 Voltaire, Inc. All rights reserved.
|
2005-10-15 02:26:04 +04:00
|
|
|
* Copyright (c) 2005 PathScale, Inc. All rights reserved.
|
2005-07-08 04:57:13 +04:00
|
|
|
*
|
|
|
|
* This software is available to you under a choice of one of two
|
|
|
|
* licenses. You may choose to be licensed under the terms of the GNU
|
|
|
|
* General Public License (GPL) Version 2, available from the file
|
|
|
|
* COPYING in the main directory of this source tree, or the
|
|
|
|
* OpenIB.org BSD license below:
|
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or
|
|
|
|
* without modification, are permitted provided that the following
|
|
|
|
* conditions are met:
|
|
|
|
*
|
|
|
|
* - Redistributions of source code must retain the above
|
|
|
|
* copyright notice, this list of conditions and the following
|
|
|
|
* disclaimer.
|
|
|
|
*
|
|
|
|
* - Redistributions in binary form must reproduce the above
|
|
|
|
* copyright notice, this list of conditions and the following
|
|
|
|
* disclaimer in the documentation and/or other materials
|
|
|
|
* provided with the distribution.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
|
|
|
|
* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
|
|
|
|
* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
|
|
|
|
* NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
|
|
|
|
* BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
|
|
|
|
* ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
|
|
|
|
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
|
|
* SOFTWARE.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/device.h>
|
|
|
|
#include <linux/err.h>
|
|
|
|
#include <linux/fs.h>
|
|
|
|
#include <linux/poll.h>
|
2009-10-04 16:11:37 +04:00
|
|
|
#include <linux/sched.h>
|
2005-07-08 04:57:13 +04:00
|
|
|
#include <linux/file.h>
|
2005-10-29 02:38:26 +04:00
|
|
|
#include <linux/cdev.h>
|
2010-02-25 03:51:20 +03:00
|
|
|
#include <linux/anon_inodes.h>
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 11:04:11 +03:00
|
|
|
#include <linux/slab.h>
|
2005-07-08 04:57:13 +04:00
|
|
|
|
|
|
|
#include <asm/uaccess.h>
|
|
|
|
|
|
|
|
#include "uverbs.h"
|
|
|
|
|
|
|
|
MODULE_AUTHOR("Roland Dreier");
|
|
|
|
MODULE_DESCRIPTION("InfiniBand userspace verbs access");
|
|
|
|
MODULE_LICENSE("Dual BSD/GPL");
|
|
|
|
|
|
|
|
enum {
|
|
|
|
IB_UVERBS_MAJOR = 231,
|
|
|
|
IB_UVERBS_BASE_MINOR = 192,
|
|
|
|
IB_UVERBS_MAX_DEVICES = 32
|
|
|
|
};
|
|
|
|
|
|
|
|
#define IB_UVERBS_BASE_DEV MKDEV(IB_UVERBS_MAJOR, IB_UVERBS_BASE_MINOR)
|
|
|
|
|
2005-10-29 02:38:26 +04:00
|
|
|
static struct class *uverbs_class;
|
|
|
|
|
IB/uverbs: Don't serialize with ib_uverbs_idr_mutex
Currently, all userspace verbs operations that call into the kernel
are serialized by ib_uverbs_idr_mutex. This can be a scalability
issue for some workloads, especially for devices driven by the ipath
driver, which needs to call into the kernel even for datapath
operations.
Fix this by adding reference counts to the userspace objects, and then
converting ib_uverbs_idr_mutex into a spinlock that only protects the
idrs long enough to take a reference on the object being looked up.
Because remove operations may fail, we have to do a slightly funky
two-step deletion, which is described in the comments at the top of
uverbs_cmd.c.
This also still leaves ib_uverbs_idr_lock as a single lock that is
possibly subject to contention. However, the lock hold time will only
be a single idr operation, so multiple threads should still be able to
make progress, even if ib_uverbs_idr_lock is being ping-ponged.
Surprisingly, these changes even shrink the object code:
add/remove: 23/5 grow/shrink: 4/21 up/down: 633/-693 (-60)
Signed-off-by: Roland Dreier <rolandd@cisco.com>
2006-06-18 07:44:49 +04:00
|
|
|
DEFINE_SPINLOCK(ib_uverbs_idr_lock);
|
2005-07-08 04:57:13 +04:00
|
|
|
DEFINE_IDR(ib_uverbs_pd_idr);
|
|
|
|
DEFINE_IDR(ib_uverbs_mr_idr);
|
|
|
|
DEFINE_IDR(ib_uverbs_mw_idr);
|
|
|
|
DEFINE_IDR(ib_uverbs_ah_idr);
|
|
|
|
DEFINE_IDR(ib_uverbs_cq_idr);
|
|
|
|
DEFINE_IDR(ib_uverbs_qp_idr);
|
2005-08-18 23:24:13 +04:00
|
|
|
DEFINE_IDR(ib_uverbs_srq_idr);
|
2011-05-24 19:33:46 +04:00
|
|
|
DEFINE_IDR(ib_uverbs_xrcd_idr);
|
2013-08-14 14:58:30 +04:00
|
|
|
DEFINE_IDR(ib_uverbs_rule_idr);
|
2005-07-08 04:57:13 +04:00
|
|
|
|
2009-09-06 07:24:23 +04:00
|
|
|
static DEFINE_SPINLOCK(map_lock);
|
2005-07-08 04:57:13 +04:00
|
|
|
static DECLARE_BITMAP(dev_map, IB_UVERBS_MAX_DEVICES);
|
|
|
|
|
|
|
|
static ssize_t (*uverbs_cmd_table[])(struct ib_uverbs_file *file,
|
2015-08-13 18:32:04 +03:00
|
|
|
struct ib_device *ib_dev,
|
2005-07-08 04:57:13 +04:00
|
|
|
const char __user *buf, int in_len,
|
|
|
|
int out_len) = {
|
2010-02-02 22:08:19 +03:00
|
|
|
[IB_USER_VERBS_CMD_GET_CONTEXT] = ib_uverbs_get_context,
|
|
|
|
[IB_USER_VERBS_CMD_QUERY_DEVICE] = ib_uverbs_query_device,
|
|
|
|
[IB_USER_VERBS_CMD_QUERY_PORT] = ib_uverbs_query_port,
|
|
|
|
[IB_USER_VERBS_CMD_ALLOC_PD] = ib_uverbs_alloc_pd,
|
|
|
|
[IB_USER_VERBS_CMD_DEALLOC_PD] = ib_uverbs_dealloc_pd,
|
|
|
|
[IB_USER_VERBS_CMD_REG_MR] = ib_uverbs_reg_mr,
|
2014-07-31 12:01:28 +04:00
|
|
|
[IB_USER_VERBS_CMD_REREG_MR] = ib_uverbs_rereg_mr,
|
2010-02-02 22:08:19 +03:00
|
|
|
[IB_USER_VERBS_CMD_DEREG_MR] = ib_uverbs_dereg_mr,
|
2013-02-06 20:19:13 +04:00
|
|
|
[IB_USER_VERBS_CMD_ALLOC_MW] = ib_uverbs_alloc_mw,
|
|
|
|
[IB_USER_VERBS_CMD_DEALLOC_MW] = ib_uverbs_dealloc_mw,
|
2005-09-27 00:53:25 +04:00
|
|
|
[IB_USER_VERBS_CMD_CREATE_COMP_CHANNEL] = ib_uverbs_create_comp_channel,
|
2010-02-02 22:08:19 +03:00
|
|
|
[IB_USER_VERBS_CMD_CREATE_CQ] = ib_uverbs_create_cq,
|
|
|
|
[IB_USER_VERBS_CMD_RESIZE_CQ] = ib_uverbs_resize_cq,
|
|
|
|
[IB_USER_VERBS_CMD_POLL_CQ] = ib_uverbs_poll_cq,
|
|
|
|
[IB_USER_VERBS_CMD_REQ_NOTIFY_CQ] = ib_uverbs_req_notify_cq,
|
|
|
|
[IB_USER_VERBS_CMD_DESTROY_CQ] = ib_uverbs_destroy_cq,
|
|
|
|
[IB_USER_VERBS_CMD_CREATE_QP] = ib_uverbs_create_qp,
|
|
|
|
[IB_USER_VERBS_CMD_QUERY_QP] = ib_uverbs_query_qp,
|
|
|
|
[IB_USER_VERBS_CMD_MODIFY_QP] = ib_uverbs_modify_qp,
|
|
|
|
[IB_USER_VERBS_CMD_DESTROY_QP] = ib_uverbs_destroy_qp,
|
|
|
|
[IB_USER_VERBS_CMD_POST_SEND] = ib_uverbs_post_send,
|
|
|
|
[IB_USER_VERBS_CMD_POST_RECV] = ib_uverbs_post_recv,
|
|
|
|
[IB_USER_VERBS_CMD_POST_SRQ_RECV] = ib_uverbs_post_srq_recv,
|
|
|
|
[IB_USER_VERBS_CMD_CREATE_AH] = ib_uverbs_create_ah,
|
|
|
|
[IB_USER_VERBS_CMD_DESTROY_AH] = ib_uverbs_destroy_ah,
|
|
|
|
[IB_USER_VERBS_CMD_ATTACH_MCAST] = ib_uverbs_attach_mcast,
|
|
|
|
[IB_USER_VERBS_CMD_DETACH_MCAST] = ib_uverbs_detach_mcast,
|
|
|
|
[IB_USER_VERBS_CMD_CREATE_SRQ] = ib_uverbs_create_srq,
|
|
|
|
[IB_USER_VERBS_CMD_MODIFY_SRQ] = ib_uverbs_modify_srq,
|
|
|
|
[IB_USER_VERBS_CMD_QUERY_SRQ] = ib_uverbs_query_srq,
|
|
|
|
[IB_USER_VERBS_CMD_DESTROY_SRQ] = ib_uverbs_destroy_srq,
|
2011-05-24 19:33:46 +04:00
|
|
|
[IB_USER_VERBS_CMD_OPEN_XRCD] = ib_uverbs_open_xrcd,
|
|
|
|
[IB_USER_VERBS_CMD_CLOSE_XRCD] = ib_uverbs_close_xrcd,
|
2011-08-12 00:57:43 +04:00
|
|
|
[IB_USER_VERBS_CMD_CREATE_XSRQ] = ib_uverbs_create_xsrq,
|
2013-08-14 14:58:30 +04:00
|
|
|
[IB_USER_VERBS_CMD_OPEN_QP] = ib_uverbs_open_qp,
|
IB/core: extended command: an improved infrastructure for uverbs commands
Commit 400dbc96583f ("IB/core: Infrastructure for extensible uverbs
commands") added an infrastructure for extensible uverbs commands
while later commit 436f2ad05a0b ("IB/core: Export ib_create/destroy_flow
through uverbs") exported ib_create_flow()/ib_destroy_flow() functions
using this new infrastructure.
According to the commit 400dbc96583f, the purpose of this
infrastructure is to support passing around provider (eg. hardware)
specific buffers when userspace issue commands to the kernel, so that
it would be possible to extend uverbs (eg. core) buffers independently
from the provider buffers.
But the new kernel command function prototypes were not modified to
take advantage of this extension. This issue was exposed by Roland
Dreier in a previous review[1].
So the following patch is an attempt to a revised extensible command
infrastructure.
This improved extensible command infrastructure distinguish between
core (eg. legacy)'s command/response buffers from provider
(eg. hardware)'s command/response buffers: each extended command
implementing function is given a struct ib_udata to hold core
(eg. uverbs) input and output buffers, and another struct ib_udata to
hold the hw (eg. provider) input and output buffers.
Having those buffers identified separately make it easier to increase
one buffer to support extension without having to add some code to
guess the exact size of each command/response parts: This should make
the extended functions more reliable.
Additionally, instead of relying on command identifier being greater
than IB_USER_VERBS_CMD_THRESHOLD, the proposed infrastructure rely on
unused bits in command field: on the 32 bits provided by command
field, only 6 bits are really needed to encode the identifier of
commands currently supported by the kernel. (Even using only 6 bits
leaves room for about 23 new commands).
So this patch makes use of some high order bits in command field to
store flags, leaving enough room for more command identifiers than one
will ever need (eg. 256).
The new flags are used to specify if the command should be processed
as an extended one or a legacy one. While designing the new command
format, care was taken to make usage of flags itself extensible.
Using high order bits of the commands field ensure that newer
libibverbs on older kernel will properly fail when trying to call
extended commands. On the other hand, older libibverbs on newer kernel
will never be able to issue calls to extended commands.
The extended command header includes the optional response pointer so
that output buffer length and output buffer pointer are located
together in the command, allowing proper parameters checking. This
should make implementing functions easier and safer.
Additionally the extended header ensure 64bits alignment, while making
all sizes multiple of 8 bytes, extending the maximum buffer size:
legacy extended
Maximum command buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
Maximum response buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
For the purpose of doing proper buffer size accounting, the headers
size are no more taken in account in "in_words".
One of the odds of the current extensible infrastructure, reading
twice the "legacy" command header, is fixed by removing the "legacy"
command header from the extended command header: they are processed as
two different parts of the command: memory is read once and
information are not duplicated: it's making clear that's an extended
command scheme and not a different command scheme.
The proposed scheme will format input (command) and output (response)
buffers this way:
- command:
legacy header +
extended header +
command data (core + hw):
+----------------------------------------+
| flags | 00 00 | command |
| in_words | out_words |
+----------------------------------------+
| response |
| response |
| provider_in_words | provider_out_words |
| padding |
+----------------------------------------+
| |
. <uverbs input> .
. (in_words * 8) .
| |
+----------------------------------------+
| |
. <provider input> .
. (provider_in_words * 8) .
| |
+----------------------------------------+
- response, if present:
+----------------------------------------+
| |
. <uverbs output space> .
. (out_words * 8) .
| |
+----------------------------------------+
| |
. <provider output space> .
. (provider_out_words * 8) .
| |
+----------------------------------------+
The overall design is to ensure that the extensible infrastructure is
itself extensible while begin more reliable with more input and bound
checking.
Note:
The unused field in the extended header would be perfect candidate to
hold the command "comp_mask" (eg. bit field used to handle
compatibility). This was suggested by Roland Dreier in a previous
review[2]. But "comp_mask" field is likely to be present in the uverb
input and/or provider input, likewise for the response, as noted by
Matan Barak[3], so it doesn't make sense to put "comp_mask" in the
header.
[1]:
http://marc.info/?i=CAL1RGDWxmM17W2o_era24A-TTDeKyoL6u3NRu_=t_dhV_ZA9MA@mail.gmail.com
[2]:
http://marc.info/?i=CAL1RGDXJtrc849M6_XNZT5xO1+ybKtLWGq6yg6LhoSsKpsmkYA@mail.gmail.com
[3]:
http://marc.info/?i=525C1149.6000701@mellanox.com
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Link: http://marc.info/?i=cover.1383773832.git.ydroneaud@opteya.com
[ Convert "ret ? ret : 0" to the equivalent "ret". - Roland ]
Signed-off-by: Roland Dreier <roland@purestorage.com>
2013-11-07 02:21:49 +04:00
|
|
|
};
|
|
|
|
|
|
|
|
static int (*uverbs_ex_cmd_table[])(struct ib_uverbs_file *file,
|
2015-08-13 18:32:04 +03:00
|
|
|
struct ib_device *ib_dev,
|
IB/core: extended command: an improved infrastructure for uverbs commands
Commit 400dbc96583f ("IB/core: Infrastructure for extensible uverbs
commands") added an infrastructure for extensible uverbs commands
while later commit 436f2ad05a0b ("IB/core: Export ib_create/destroy_flow
through uverbs") exported ib_create_flow()/ib_destroy_flow() functions
using this new infrastructure.
According to the commit 400dbc96583f, the purpose of this
infrastructure is to support passing around provider (eg. hardware)
specific buffers when userspace issue commands to the kernel, so that
it would be possible to extend uverbs (eg. core) buffers independently
from the provider buffers.
But the new kernel command function prototypes were not modified to
take advantage of this extension. This issue was exposed by Roland
Dreier in a previous review[1].
So the following patch is an attempt to a revised extensible command
infrastructure.
This improved extensible command infrastructure distinguish between
core (eg. legacy)'s command/response buffers from provider
(eg. hardware)'s command/response buffers: each extended command
implementing function is given a struct ib_udata to hold core
(eg. uverbs) input and output buffers, and another struct ib_udata to
hold the hw (eg. provider) input and output buffers.
Having those buffers identified separately make it easier to increase
one buffer to support extension without having to add some code to
guess the exact size of each command/response parts: This should make
the extended functions more reliable.
Additionally, instead of relying on command identifier being greater
than IB_USER_VERBS_CMD_THRESHOLD, the proposed infrastructure rely on
unused bits in command field: on the 32 bits provided by command
field, only 6 bits are really needed to encode the identifier of
commands currently supported by the kernel. (Even using only 6 bits
leaves room for about 23 new commands).
So this patch makes use of some high order bits in command field to
store flags, leaving enough room for more command identifiers than one
will ever need (eg. 256).
The new flags are used to specify if the command should be processed
as an extended one or a legacy one. While designing the new command
format, care was taken to make usage of flags itself extensible.
Using high order bits of the commands field ensure that newer
libibverbs on older kernel will properly fail when trying to call
extended commands. On the other hand, older libibverbs on newer kernel
will never be able to issue calls to extended commands.
The extended command header includes the optional response pointer so
that output buffer length and output buffer pointer are located
together in the command, allowing proper parameters checking. This
should make implementing functions easier and safer.
Additionally the extended header ensure 64bits alignment, while making
all sizes multiple of 8 bytes, extending the maximum buffer size:
legacy extended
Maximum command buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
Maximum response buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
For the purpose of doing proper buffer size accounting, the headers
size are no more taken in account in "in_words".
One of the odds of the current extensible infrastructure, reading
twice the "legacy" command header, is fixed by removing the "legacy"
command header from the extended command header: they are processed as
two different parts of the command: memory is read once and
information are not duplicated: it's making clear that's an extended
command scheme and not a different command scheme.
The proposed scheme will format input (command) and output (response)
buffers this way:
- command:
legacy header +
extended header +
command data (core + hw):
+----------------------------------------+
| flags | 00 00 | command |
| in_words | out_words |
+----------------------------------------+
| response |
| response |
| provider_in_words | provider_out_words |
| padding |
+----------------------------------------+
| |
. <uverbs input> .
. (in_words * 8) .
| |
+----------------------------------------+
| |
. <provider input> .
. (provider_in_words * 8) .
| |
+----------------------------------------+
- response, if present:
+----------------------------------------+
| |
. <uverbs output space> .
. (out_words * 8) .
| |
+----------------------------------------+
| |
. <provider output space> .
. (provider_out_words * 8) .
| |
+----------------------------------------+
The overall design is to ensure that the extensible infrastructure is
itself extensible while begin more reliable with more input and bound
checking.
Note:
The unused field in the extended header would be perfect candidate to
hold the command "comp_mask" (eg. bit field used to handle
compatibility). This was suggested by Roland Dreier in a previous
review[2]. But "comp_mask" field is likely to be present in the uverb
input and/or provider input, likewise for the response, as noted by
Matan Barak[3], so it doesn't make sense to put "comp_mask" in the
header.
[1]:
http://marc.info/?i=CAL1RGDWxmM17W2o_era24A-TTDeKyoL6u3NRu_=t_dhV_ZA9MA@mail.gmail.com
[2]:
http://marc.info/?i=CAL1RGDXJtrc849M6_XNZT5xO1+ybKtLWGq6yg6LhoSsKpsmkYA@mail.gmail.com
[3]:
http://marc.info/?i=525C1149.6000701@mellanox.com
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Link: http://marc.info/?i=cover.1383773832.git.ydroneaud@opteya.com
[ Convert "ret ? ret : 0" to the equivalent "ret". - Roland ]
Signed-off-by: Roland Dreier <roland@purestorage.com>
2013-11-07 02:21:49 +04:00
|
|
|
struct ib_udata *ucore,
|
|
|
|
struct ib_udata *uhw) = {
|
|
|
|
[IB_USER_VERBS_EX_CMD_CREATE_FLOW] = ib_uverbs_ex_create_flow,
|
2014-12-11 18:04:15 +03:00
|
|
|
[IB_USER_VERBS_EX_CMD_DESTROY_FLOW] = ib_uverbs_ex_destroy_flow,
|
2015-02-08 14:28:50 +03:00
|
|
|
[IB_USER_VERBS_EX_CMD_QUERY_DEVICE] = ib_uverbs_ex_query_device,
|
2015-06-11 16:35:23 +03:00
|
|
|
[IB_USER_VERBS_EX_CMD_CREATE_CQ] = ib_uverbs_ex_create_cq,
|
2015-10-21 17:00:42 +03:00
|
|
|
[IB_USER_VERBS_EX_CMD_CREATE_QP] = ib_uverbs_ex_create_qp,
|
2005-07-08 04:57:13 +04:00
|
|
|
};
|
|
|
|
|
|
|
|
static void ib_uverbs_add_one(struct ib_device *device);
|
2015-07-30 17:50:14 +03:00
|
|
|
static void ib_uverbs_remove_one(struct ib_device *device, void *client_data);
|
2005-07-08 04:57:13 +04:00
|
|
|
|
2015-12-23 21:12:48 +03:00
|
|
|
int uverbs_dealloc_mw(struct ib_mw *mw)
|
|
|
|
{
|
|
|
|
struct ib_pd *pd = mw->pd;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = mw->device->dealloc_mw(mw);
|
|
|
|
if (!ret)
|
|
|
|
atomic_dec(&pd->usecnt);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2015-08-13 18:32:03 +03:00
|
|
|
static void ib_uverbs_release_dev(struct kobject *kobj)
|
2005-10-29 02:38:26 +04:00
|
|
|
{
|
|
|
|
struct ib_uverbs_device *dev =
|
2015-08-13 18:32:03 +03:00
|
|
|
container_of(kobj, struct ib_uverbs_device, kobj);
|
2005-10-29 02:38:26 +04:00
|
|
|
|
2015-08-13 18:32:05 +03:00
|
|
|
cleanup_srcu_struct(&dev->disassociate_srcu);
|
2015-08-13 18:32:03 +03:00
|
|
|
kfree(dev);
|
2005-10-29 02:38:26 +04:00
|
|
|
}
|
|
|
|
|
2015-08-13 18:32:03 +03:00
|
|
|
static struct kobj_type ib_uverbs_dev_ktype = {
|
|
|
|
.release = ib_uverbs_release_dev,
|
|
|
|
};
|
|
|
|
|
2007-10-10 06:59:15 +04:00
|
|
|
static void ib_uverbs_release_event_file(struct kref *ref)
|
|
|
|
{
|
|
|
|
struct ib_uverbs_event_file *file =
|
|
|
|
container_of(ref, struct ib_uverbs_event_file, ref);
|
|
|
|
|
|
|
|
kfree(file);
|
|
|
|
}
|
|
|
|
|
2005-10-29 02:38:26 +04:00
|
|
|
void ib_uverbs_release_ucq(struct ib_uverbs_file *file,
|
|
|
|
struct ib_uverbs_event_file *ev_file,
|
|
|
|
struct ib_ucq_object *uobj)
|
|
|
|
{
|
|
|
|
struct ib_uverbs_event *evt, *tmp;
|
|
|
|
|
|
|
|
if (ev_file) {
|
|
|
|
spin_lock_irq(&ev_file->lock);
|
|
|
|
list_for_each_entry_safe(evt, tmp, &uobj->comp_list, obj_list) {
|
|
|
|
list_del(&evt->list);
|
|
|
|
kfree(evt);
|
|
|
|
}
|
|
|
|
spin_unlock_irq(&ev_file->lock);
|
|
|
|
|
|
|
|
kref_put(&ev_file->ref, ib_uverbs_release_event_file);
|
|
|
|
}
|
|
|
|
|
|
|
|
spin_lock_irq(&file->async_file->lock);
|
|
|
|
list_for_each_entry_safe(evt, tmp, &uobj->async_list, obj_list) {
|
|
|
|
list_del(&evt->list);
|
|
|
|
kfree(evt);
|
|
|
|
}
|
|
|
|
spin_unlock_irq(&file->async_file->lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
void ib_uverbs_release_uevent(struct ib_uverbs_file *file,
|
|
|
|
struct ib_uevent_object *uobj)
|
|
|
|
{
|
|
|
|
struct ib_uverbs_event *evt, *tmp;
|
|
|
|
|
|
|
|
spin_lock_irq(&file->async_file->lock);
|
|
|
|
list_for_each_entry_safe(evt, tmp, &uobj->event_list, obj_list) {
|
|
|
|
list_del(&evt->list);
|
|
|
|
kfree(evt);
|
|
|
|
}
|
|
|
|
spin_unlock_irq(&file->async_file->lock);
|
|
|
|
}
|
|
|
|
|
2005-11-30 03:57:01 +03:00
|
|
|
static void ib_uverbs_detach_umcast(struct ib_qp *qp,
|
|
|
|
struct ib_uqp_object *uobj)
|
|
|
|
{
|
|
|
|
struct ib_uverbs_mcast_entry *mcast, *tmp;
|
|
|
|
|
|
|
|
list_for_each_entry_safe(mcast, tmp, &uobj->mcast_list, list) {
|
|
|
|
ib_detach_mcast(qp, &mcast->gid, mcast->lid);
|
|
|
|
list_del(&mcast->list);
|
|
|
|
kfree(mcast);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-10-29 02:38:26 +04:00
|
|
|
static int ib_uverbs_cleanup_ucontext(struct ib_uverbs_file *file,
|
|
|
|
struct ib_ucontext *context)
|
2005-07-08 04:57:13 +04:00
|
|
|
{
|
|
|
|
struct ib_uobject *uobj, *tmp;
|
|
|
|
|
2007-03-05 03:15:11 +03:00
|
|
|
context->closing = 1;
|
|
|
|
|
2005-10-15 02:26:04 +04:00
|
|
|
list_for_each_entry_safe(uobj, tmp, &context->ah_list, list) {
|
IB/uverbs: Don't serialize with ib_uverbs_idr_mutex
Currently, all userspace verbs operations that call into the kernel
are serialized by ib_uverbs_idr_mutex. This can be a scalability
issue for some workloads, especially for devices driven by the ipath
driver, which needs to call into the kernel even for datapath
operations.
Fix this by adding reference counts to the userspace objects, and then
converting ib_uverbs_idr_mutex into a spinlock that only protects the
idrs long enough to take a reference on the object being looked up.
Because remove operations may fail, we have to do a slightly funky
two-step deletion, which is described in the comments at the top of
uverbs_cmd.c.
This also still leaves ib_uverbs_idr_lock as a single lock that is
possibly subject to contention. However, the lock hold time will only
be a single idr operation, so multiple threads should still be able to
make progress, even if ib_uverbs_idr_lock is being ping-ponged.
Surprisingly, these changes even shrink the object code:
add/remove: 23/5 grow/shrink: 4/21 up/down: 633/-693 (-60)
Signed-off-by: Roland Dreier <rolandd@cisco.com>
2006-06-18 07:44:49 +04:00
|
|
|
struct ib_ah *ah = uobj->object;
|
|
|
|
|
|
|
|
idr_remove_uobj(&ib_uverbs_ah_idr, uobj);
|
2005-10-15 02:26:04 +04:00
|
|
|
ib_destroy_ah(ah);
|
|
|
|
kfree(uobj);
|
|
|
|
}
|
2005-07-08 04:57:13 +04:00
|
|
|
|
2013-02-06 20:19:13 +04:00
|
|
|
/* Remove MWs before QPs, in order to support type 2A MWs. */
|
|
|
|
list_for_each_entry_safe(uobj, tmp, &context->mw_list, list) {
|
|
|
|
struct ib_mw *mw = uobj->object;
|
|
|
|
|
|
|
|
idr_remove_uobj(&ib_uverbs_mw_idr, uobj);
|
2015-12-23 21:12:48 +03:00
|
|
|
uverbs_dealloc_mw(mw);
|
2013-02-06 20:19:13 +04:00
|
|
|
kfree(uobj);
|
|
|
|
}
|
|
|
|
|
2013-08-14 14:58:30 +04:00
|
|
|
list_for_each_entry_safe(uobj, tmp, &context->rule_list, list) {
|
|
|
|
struct ib_flow *flow_id = uobj->object;
|
|
|
|
|
|
|
|
idr_remove_uobj(&ib_uverbs_rule_idr, uobj);
|
|
|
|
ib_destroy_flow(flow_id);
|
|
|
|
kfree(uobj);
|
|
|
|
}
|
|
|
|
|
2005-07-08 04:57:13 +04:00
|
|
|
list_for_each_entry_safe(uobj, tmp, &context->qp_list, list) {
|
IB/uverbs: Don't serialize with ib_uverbs_idr_mutex
Currently, all userspace verbs operations that call into the kernel
are serialized by ib_uverbs_idr_mutex. This can be a scalability
issue for some workloads, especially for devices driven by the ipath
driver, which needs to call into the kernel even for datapath
operations.
Fix this by adding reference counts to the userspace objects, and then
converting ib_uverbs_idr_mutex into a spinlock that only protects the
idrs long enough to take a reference on the object being looked up.
Because remove operations may fail, we have to do a slightly funky
two-step deletion, which is described in the comments at the top of
uverbs_cmd.c.
This also still leaves ib_uverbs_idr_lock as a single lock that is
possibly subject to contention. However, the lock hold time will only
be a single idr operation, so multiple threads should still be able to
make progress, even if ib_uverbs_idr_lock is being ping-ponged.
Surprisingly, these changes even shrink the object code:
add/remove: 23/5 grow/shrink: 4/21 up/down: 633/-693 (-60)
Signed-off-by: Roland Dreier <rolandd@cisco.com>
2006-06-18 07:44:49 +04:00
|
|
|
struct ib_qp *qp = uobj->object;
|
2005-11-30 03:57:01 +03:00
|
|
|
struct ib_uqp_object *uqp =
|
|
|
|
container_of(uobj, struct ib_uqp_object, uevent.uobject);
|
IB/uverbs: Don't serialize with ib_uverbs_idr_mutex
Currently, all userspace verbs operations that call into the kernel
are serialized by ib_uverbs_idr_mutex. This can be a scalability
issue for some workloads, especially for devices driven by the ipath
driver, which needs to call into the kernel even for datapath
operations.
Fix this by adding reference counts to the userspace objects, and then
converting ib_uverbs_idr_mutex into a spinlock that only protects the
idrs long enough to take a reference on the object being looked up.
Because remove operations may fail, we have to do a slightly funky
two-step deletion, which is described in the comments at the top of
uverbs_cmd.c.
This also still leaves ib_uverbs_idr_lock as a single lock that is
possibly subject to contention. However, the lock hold time will only
be a single idr operation, so multiple threads should still be able to
make progress, even if ib_uverbs_idr_lock is being ping-ponged.
Surprisingly, these changes even shrink the object code:
add/remove: 23/5 grow/shrink: 4/21 up/down: 633/-693 (-60)
Signed-off-by: Roland Dreier <rolandd@cisco.com>
2006-06-18 07:44:49 +04:00
|
|
|
|
|
|
|
idr_remove_uobj(&ib_uverbs_qp_idr, uobj);
|
2011-08-09 02:31:51 +04:00
|
|
|
if (qp != qp->real_qp) {
|
|
|
|
ib_close_qp(qp);
|
2011-05-27 11:00:12 +04:00
|
|
|
} else {
|
|
|
|
ib_uverbs_detach_umcast(qp, uqp);
|
|
|
|
ib_destroy_qp(qp);
|
|
|
|
}
|
2005-11-30 03:57:01 +03:00
|
|
|
ib_uverbs_release_uevent(file, &uqp->uevent);
|
|
|
|
kfree(uqp);
|
2005-07-08 04:57:13 +04:00
|
|
|
}
|
|
|
|
|
2015-04-09 12:13:41 +03:00
|
|
|
list_for_each_entry_safe(uobj, tmp, &context->srq_list, list) {
|
|
|
|
struct ib_srq *srq = uobj->object;
|
|
|
|
struct ib_uevent_object *uevent =
|
|
|
|
container_of(uobj, struct ib_uevent_object, uobject);
|
|
|
|
|
|
|
|
idr_remove_uobj(&ib_uverbs_srq_idr, uobj);
|
|
|
|
ib_destroy_srq(srq);
|
|
|
|
ib_uverbs_release_uevent(file, uevent);
|
|
|
|
kfree(uevent);
|
|
|
|
}
|
|
|
|
|
2005-07-08 04:57:13 +04:00
|
|
|
list_for_each_entry_safe(uobj, tmp, &context->cq_list, list) {
|
IB/uverbs: Don't serialize with ib_uverbs_idr_mutex
Currently, all userspace verbs operations that call into the kernel
are serialized by ib_uverbs_idr_mutex. This can be a scalability
issue for some workloads, especially for devices driven by the ipath
driver, which needs to call into the kernel even for datapath
operations.
Fix this by adding reference counts to the userspace objects, and then
converting ib_uverbs_idr_mutex into a spinlock that only protects the
idrs long enough to take a reference on the object being looked up.
Because remove operations may fail, we have to do a slightly funky
two-step deletion, which is described in the comments at the top of
uverbs_cmd.c.
This also still leaves ib_uverbs_idr_lock as a single lock that is
possibly subject to contention. However, the lock hold time will only
be a single idr operation, so multiple threads should still be able to
make progress, even if ib_uverbs_idr_lock is being ping-ponged.
Surprisingly, these changes even shrink the object code:
add/remove: 23/5 grow/shrink: 4/21 up/down: 633/-693 (-60)
Signed-off-by: Roland Dreier <rolandd@cisco.com>
2006-06-18 07:44:49 +04:00
|
|
|
struct ib_cq *cq = uobj->object;
|
2005-10-29 02:38:26 +04:00
|
|
|
struct ib_uverbs_event_file *ev_file = cq->cq_context;
|
|
|
|
struct ib_ucq_object *ucq =
|
|
|
|
container_of(uobj, struct ib_ucq_object, uobject);
|
IB/uverbs: Don't serialize with ib_uverbs_idr_mutex
Currently, all userspace verbs operations that call into the kernel
are serialized by ib_uverbs_idr_mutex. This can be a scalability
issue for some workloads, especially for devices driven by the ipath
driver, which needs to call into the kernel even for datapath
operations.
Fix this by adding reference counts to the userspace objects, and then
converting ib_uverbs_idr_mutex into a spinlock that only protects the
idrs long enough to take a reference on the object being looked up.
Because remove operations may fail, we have to do a slightly funky
two-step deletion, which is described in the comments at the top of
uverbs_cmd.c.
This also still leaves ib_uverbs_idr_lock as a single lock that is
possibly subject to contention. However, the lock hold time will only
be a single idr operation, so multiple threads should still be able to
make progress, even if ib_uverbs_idr_lock is being ping-ponged.
Surprisingly, these changes even shrink the object code:
add/remove: 23/5 grow/shrink: 4/21 up/down: 633/-693 (-60)
Signed-off-by: Roland Dreier <rolandd@cisco.com>
2006-06-18 07:44:49 +04:00
|
|
|
|
|
|
|
idr_remove_uobj(&ib_uverbs_cq_idr, uobj);
|
2005-07-08 04:57:13 +04:00
|
|
|
ib_destroy_cq(cq);
|
2005-10-29 02:38:26 +04:00
|
|
|
ib_uverbs_release_ucq(file, ev_file, ucq);
|
|
|
|
kfree(ucq);
|
2005-07-08 04:57:13 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
list_for_each_entry_safe(uobj, tmp, &context->mr_list, list) {
|
IB/uverbs: Don't serialize with ib_uverbs_idr_mutex
Currently, all userspace verbs operations that call into the kernel
are serialized by ib_uverbs_idr_mutex. This can be a scalability
issue for some workloads, especially for devices driven by the ipath
driver, which needs to call into the kernel even for datapath
operations.
Fix this by adding reference counts to the userspace objects, and then
converting ib_uverbs_idr_mutex into a spinlock that only protects the
idrs long enough to take a reference on the object being looked up.
Because remove operations may fail, we have to do a slightly funky
two-step deletion, which is described in the comments at the top of
uverbs_cmd.c.
This also still leaves ib_uverbs_idr_lock as a single lock that is
possibly subject to contention. However, the lock hold time will only
be a single idr operation, so multiple threads should still be able to
make progress, even if ib_uverbs_idr_lock is being ping-ponged.
Surprisingly, these changes even shrink the object code:
add/remove: 23/5 grow/shrink: 4/21 up/down: 633/-693 (-60)
Signed-off-by: Roland Dreier <rolandd@cisco.com>
2006-06-18 07:44:49 +04:00
|
|
|
struct ib_mr *mr = uobj->object;
|
2005-07-08 04:57:13 +04:00
|
|
|
|
IB/uverbs: Don't serialize with ib_uverbs_idr_mutex
Currently, all userspace verbs operations that call into the kernel
are serialized by ib_uverbs_idr_mutex. This can be a scalability
issue for some workloads, especially for devices driven by the ipath
driver, which needs to call into the kernel even for datapath
operations.
Fix this by adding reference counts to the userspace objects, and then
converting ib_uverbs_idr_mutex into a spinlock that only protects the
idrs long enough to take a reference on the object being looked up.
Because remove operations may fail, we have to do a slightly funky
two-step deletion, which is described in the comments at the top of
uverbs_cmd.c.
This also still leaves ib_uverbs_idr_lock as a single lock that is
possibly subject to contention. However, the lock hold time will only
be a single idr operation, so multiple threads should still be able to
make progress, even if ib_uverbs_idr_lock is being ping-ponged.
Surprisingly, these changes even shrink the object code:
add/remove: 23/5 grow/shrink: 4/21 up/down: 633/-693 (-60)
Signed-off-by: Roland Dreier <rolandd@cisco.com>
2006-06-18 07:44:49 +04:00
|
|
|
idr_remove_uobj(&ib_uverbs_mr_idr, uobj);
|
2005-07-08 04:57:13 +04:00
|
|
|
ib_dereg_mr(mr);
|
2007-03-05 03:15:11 +03:00
|
|
|
kfree(uobj);
|
2005-07-08 04:57:13 +04:00
|
|
|
}
|
|
|
|
|
2011-05-24 19:33:46 +04:00
|
|
|
mutex_lock(&file->device->xrcd_tree_mutex);
|
|
|
|
list_for_each_entry_safe(uobj, tmp, &context->xrcd_list, list) {
|
|
|
|
struct ib_xrcd *xrcd = uobj->object;
|
|
|
|
struct ib_uxrcd_object *uxrcd =
|
|
|
|
container_of(uobj, struct ib_uxrcd_object, uobject);
|
|
|
|
|
|
|
|
idr_remove_uobj(&ib_uverbs_xrcd_idr, uobj);
|
|
|
|
ib_uverbs_dealloc_xrcd(file->device, xrcd);
|
|
|
|
kfree(uxrcd);
|
|
|
|
}
|
|
|
|
mutex_unlock(&file->device->xrcd_tree_mutex);
|
|
|
|
|
2005-07-08 04:57:13 +04:00
|
|
|
list_for_each_entry_safe(uobj, tmp, &context->pd_list, list) {
|
IB/uverbs: Don't serialize with ib_uverbs_idr_mutex
Currently, all userspace verbs operations that call into the kernel
are serialized by ib_uverbs_idr_mutex. This can be a scalability
issue for some workloads, especially for devices driven by the ipath
driver, which needs to call into the kernel even for datapath
operations.
Fix this by adding reference counts to the userspace objects, and then
converting ib_uverbs_idr_mutex into a spinlock that only protects the
idrs long enough to take a reference on the object being looked up.
Because remove operations may fail, we have to do a slightly funky
two-step deletion, which is described in the comments at the top of
uverbs_cmd.c.
This also still leaves ib_uverbs_idr_lock as a single lock that is
possibly subject to contention. However, the lock hold time will only
be a single idr operation, so multiple threads should still be able to
make progress, even if ib_uverbs_idr_lock is being ping-ponged.
Surprisingly, these changes even shrink the object code:
add/remove: 23/5 grow/shrink: 4/21 up/down: 633/-693 (-60)
Signed-off-by: Roland Dreier <rolandd@cisco.com>
2006-06-18 07:44:49 +04:00
|
|
|
struct ib_pd *pd = uobj->object;
|
|
|
|
|
|
|
|
idr_remove_uobj(&ib_uverbs_pd_idr, uobj);
|
2005-07-08 04:57:13 +04:00
|
|
|
ib_dealloc_pd(pd);
|
|
|
|
kfree(uobj);
|
|
|
|
}
|
|
|
|
|
2014-12-11 18:04:17 +03:00
|
|
|
put_pid(context->tgid);
|
|
|
|
|
2005-07-08 04:57:13 +04:00
|
|
|
return context->device->dealloc_ucontext(context);
|
|
|
|
}
|
|
|
|
|
2015-08-13 18:32:03 +03:00
|
|
|
static void ib_uverbs_comp_dev(struct ib_uverbs_device *dev)
|
|
|
|
{
|
|
|
|
complete(&dev->comp);
|
|
|
|
}
|
|
|
|
|
2005-07-08 04:57:13 +04:00
|
|
|
static void ib_uverbs_release_file(struct kref *ref)
|
|
|
|
{
|
|
|
|
struct ib_uverbs_file *file =
|
|
|
|
container_of(ref, struct ib_uverbs_file, ref);
|
2015-08-13 18:32:05 +03:00
|
|
|
struct ib_device *ib_dev;
|
|
|
|
int srcu_key;
|
|
|
|
|
|
|
|
srcu_key = srcu_read_lock(&file->device->disassociate_srcu);
|
|
|
|
ib_dev = srcu_dereference(file->device->ib_dev,
|
|
|
|
&file->device->disassociate_srcu);
|
|
|
|
if (ib_dev && !ib_dev->disassociate_ucontext)
|
|
|
|
module_put(ib_dev->owner);
|
|
|
|
srcu_read_unlock(&file->device->disassociate_srcu, srcu_key);
|
2005-07-08 04:57:13 +04:00
|
|
|
|
2015-08-13 18:32:03 +03:00
|
|
|
if (atomic_dec_and_test(&file->device->refcount))
|
|
|
|
ib_uverbs_comp_dev(file->device);
|
2005-10-29 02:38:26 +04:00
|
|
|
|
2005-07-08 04:57:13 +04:00
|
|
|
kfree(file);
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t ib_uverbs_event_read(struct file *filp, char __user *buf,
|
|
|
|
size_t count, loff_t *pos)
|
|
|
|
{
|
|
|
|
struct ib_uverbs_event_file *file = filp->private_data;
|
2005-09-10 02:55:08 +04:00
|
|
|
struct ib_uverbs_event *event;
|
2005-07-08 04:57:13 +04:00
|
|
|
int eventsz;
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
spin_lock_irq(&file->lock);
|
|
|
|
|
2005-09-27 00:53:25 +04:00
|
|
|
while (list_empty(&file->event_list)) {
|
2005-07-08 04:57:13 +04:00
|
|
|
spin_unlock_irq(&file->lock);
|
|
|
|
|
|
|
|
if (filp->f_flags & O_NONBLOCK)
|
|
|
|
return -EAGAIN;
|
|
|
|
|
|
|
|
if (wait_event_interruptible(file->poll_wait,
|
2015-08-13 18:32:05 +03:00
|
|
|
(!list_empty(&file->event_list) ||
|
|
|
|
/* The barriers built into wait_event_interruptible()
|
|
|
|
* and wake_up() guarentee this will see the null set
|
|
|
|
* without using RCU
|
|
|
|
*/
|
|
|
|
!file->uverbs_file->device->ib_dev)))
|
2005-07-08 04:57:13 +04:00
|
|
|
return -ERESTARTSYS;
|
|
|
|
|
2015-08-13 18:32:05 +03:00
|
|
|
/* If device was disassociated and no event exists set an error */
|
|
|
|
if (list_empty(&file->event_list) &&
|
|
|
|
!file->uverbs_file->device->ib_dev)
|
|
|
|
return -EIO;
|
|
|
|
|
2005-07-08 04:57:13 +04:00
|
|
|
spin_lock_irq(&file->lock);
|
|
|
|
}
|
|
|
|
|
2005-09-10 02:55:08 +04:00
|
|
|
event = list_entry(file->event_list.next, struct ib_uverbs_event, list);
|
|
|
|
|
|
|
|
if (file->is_async)
|
2005-07-08 04:57:13 +04:00
|
|
|
eventsz = sizeof (struct ib_uverbs_async_event_desc);
|
2005-09-10 02:55:08 +04:00
|
|
|
else
|
2005-07-08 04:57:13 +04:00
|
|
|
eventsz = sizeof (struct ib_uverbs_comp_event_desc);
|
|
|
|
|
|
|
|
if (eventsz > count) {
|
|
|
|
ret = -EINVAL;
|
|
|
|
event = NULL;
|
2005-09-10 02:55:08 +04:00
|
|
|
} else {
|
2005-07-08 04:57:13 +04:00
|
|
|
list_del(file->event_list.next);
|
2005-09-10 02:55:08 +04:00
|
|
|
if (event->counter) {
|
|
|
|
++(*event->counter);
|
|
|
|
list_del(&event->obj_list);
|
|
|
|
}
|
|
|
|
}
|
2005-07-08 04:57:13 +04:00
|
|
|
|
|
|
|
spin_unlock_irq(&file->lock);
|
|
|
|
|
|
|
|
if (event) {
|
|
|
|
if (copy_to_user(buf, event, eventsz))
|
|
|
|
ret = -EFAULT;
|
|
|
|
else
|
|
|
|
ret = eventsz;
|
|
|
|
}
|
|
|
|
|
|
|
|
kfree(event);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static unsigned int ib_uverbs_event_poll(struct file *filp,
|
|
|
|
struct poll_table_struct *wait)
|
|
|
|
{
|
|
|
|
unsigned int pollflags = 0;
|
|
|
|
struct ib_uverbs_event_file *file = filp->private_data;
|
|
|
|
|
|
|
|
poll_wait(filp, &file->poll_wait, wait);
|
|
|
|
|
|
|
|
spin_lock_irq(&file->lock);
|
2005-09-27 00:53:25 +04:00
|
|
|
if (!list_empty(&file->event_list))
|
2005-07-08 04:57:13 +04:00
|
|
|
pollflags = POLLIN | POLLRDNORM;
|
|
|
|
spin_unlock_irq(&file->lock);
|
|
|
|
|
|
|
|
return pollflags;
|
|
|
|
}
|
|
|
|
|
2005-07-28 01:40:00 +04:00
|
|
|
static int ib_uverbs_event_fasync(int fd, struct file *filp, int on)
|
|
|
|
{
|
|
|
|
struct ib_uverbs_event_file *file = filp->private_data;
|
|
|
|
|
|
|
|
return fasync_helper(fd, filp, on, &file->async_queue);
|
|
|
|
}
|
|
|
|
|
2005-07-08 04:57:13 +04:00
|
|
|
static int ib_uverbs_event_close(struct inode *inode, struct file *filp)
|
|
|
|
{
|
|
|
|
struct ib_uverbs_event_file *file = filp->private_data;
|
2005-09-27 00:53:25 +04:00
|
|
|
struct ib_uverbs_event *entry, *tmp;
|
2015-08-13 18:32:05 +03:00
|
|
|
int closed_already = 0;
|
2005-09-27 00:53:25 +04:00
|
|
|
|
2015-08-13 18:32:05 +03:00
|
|
|
mutex_lock(&file->uverbs_file->device->lists_mutex);
|
2005-09-27 00:53:25 +04:00
|
|
|
spin_lock_irq(&file->lock);
|
2015-08-13 18:32:05 +03:00
|
|
|
closed_already = file->is_closed;
|
2008-04-17 08:01:08 +04:00
|
|
|
file->is_closed = 1;
|
2005-09-27 00:53:25 +04:00
|
|
|
list_for_each_entry_safe(entry, tmp, &file->event_list, list) {
|
|
|
|
if (entry->counter)
|
|
|
|
list_del(&entry->obj_list);
|
|
|
|
kfree(entry);
|
|
|
|
}
|
|
|
|
spin_unlock_irq(&file->lock);
|
2015-08-13 18:32:05 +03:00
|
|
|
if (!closed_already) {
|
|
|
|
list_del(&file->list);
|
|
|
|
if (file->is_async)
|
|
|
|
ib_unregister_event_handler(&file->uverbs_file->
|
|
|
|
event_handler);
|
|
|
|
}
|
|
|
|
mutex_unlock(&file->uverbs_file->device->lists_mutex);
|
2005-07-08 04:57:13 +04:00
|
|
|
|
2015-08-13 18:32:02 +03:00
|
|
|
kref_put(&file->uverbs_file->ref, ib_uverbs_release_file);
|
2005-09-27 00:53:25 +04:00
|
|
|
kref_put(&file->ref, ib_uverbs_release_event_file);
|
2005-07-08 04:57:13 +04:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2007-02-12 11:55:32 +03:00
|
|
|
static const struct file_operations uverbs_event_fops = {
|
2005-09-27 00:53:25 +04:00
|
|
|
.owner = THIS_MODULE,
|
2010-02-02 22:08:19 +03:00
|
|
|
.read = ib_uverbs_event_read,
|
2005-07-08 04:57:13 +04:00
|
|
|
.poll = ib_uverbs_event_poll,
|
2005-07-28 01:40:00 +04:00
|
|
|
.release = ib_uverbs_event_close,
|
2010-04-10 04:13:50 +04:00
|
|
|
.fasync = ib_uverbs_event_fasync,
|
|
|
|
.llseek = no_llseek,
|
2005-07-08 04:57:13 +04:00
|
|
|
};
|
|
|
|
|
|
|
|
void ib_uverbs_comp_handler(struct ib_cq *cq, void *cq_context)
|
|
|
|
{
|
2005-09-27 00:53:25 +04:00
|
|
|
struct ib_uverbs_event_file *file = cq_context;
|
|
|
|
struct ib_ucq_object *uobj;
|
|
|
|
struct ib_uverbs_event *entry;
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
if (!file)
|
|
|
|
return;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&file->lock, flags);
|
2008-04-17 08:01:08 +04:00
|
|
|
if (file->is_closed) {
|
2005-09-27 00:53:25 +04:00
|
|
|
spin_unlock_irqrestore(&file->lock, flags);
|
|
|
|
return;
|
|
|
|
}
|
2005-07-08 04:57:13 +04:00
|
|
|
|
|
|
|
entry = kmalloc(sizeof *entry, GFP_ATOMIC);
|
2005-10-12 02:39:38 +04:00
|
|
|
if (!entry) {
|
|
|
|
spin_unlock_irqrestore(&file->lock, flags);
|
2005-07-08 04:57:13 +04:00
|
|
|
return;
|
2005-10-12 02:39:38 +04:00
|
|
|
}
|
2005-07-08 04:57:13 +04:00
|
|
|
|
2005-09-10 02:55:08 +04:00
|
|
|
uobj = container_of(cq->uobject, struct ib_ucq_object, uobject);
|
|
|
|
|
|
|
|
entry->desc.comp.cq_handle = cq->uobject->user_handle;
|
|
|
|
entry->counter = &uobj->comp_events_reported;
|
2005-07-08 04:57:13 +04:00
|
|
|
|
2005-09-27 00:53:25 +04:00
|
|
|
list_add_tail(&entry->list, &file->event_list);
|
2005-09-10 02:55:08 +04:00
|
|
|
list_add_tail(&entry->obj_list, &uobj->comp_list);
|
2005-09-27 00:53:25 +04:00
|
|
|
spin_unlock_irqrestore(&file->lock, flags);
|
2005-07-08 04:57:13 +04:00
|
|
|
|
2005-09-27 00:53:25 +04:00
|
|
|
wake_up_interruptible(&file->poll_wait);
|
|
|
|
kill_fasync(&file->async_queue, SIGIO, POLL_IN);
|
2005-07-08 04:57:13 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
static void ib_uverbs_async_handler(struct ib_uverbs_file *file,
|
2005-09-10 02:55:08 +04:00
|
|
|
__u64 element, __u64 event,
|
|
|
|
struct list_head *obj_list,
|
|
|
|
u32 *counter)
|
2005-07-08 04:57:13 +04:00
|
|
|
{
|
2005-09-10 02:55:08 +04:00
|
|
|
struct ib_uverbs_event *entry;
|
2005-07-08 04:57:13 +04:00
|
|
|
unsigned long flags;
|
|
|
|
|
2005-09-27 00:53:25 +04:00
|
|
|
spin_lock_irqsave(&file->async_file->lock, flags);
|
2008-06-19 02:36:38 +04:00
|
|
|
if (file->async_file->is_closed) {
|
2005-09-27 00:53:25 +04:00
|
|
|
spin_unlock_irqrestore(&file->async_file->lock, flags);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2005-07-08 04:57:13 +04:00
|
|
|
entry = kmalloc(sizeof *entry, GFP_ATOMIC);
|
2005-10-12 02:39:38 +04:00
|
|
|
if (!entry) {
|
|
|
|
spin_unlock_irqrestore(&file->async_file->lock, flags);
|
2005-07-08 04:57:13 +04:00
|
|
|
return;
|
2005-10-12 02:39:38 +04:00
|
|
|
}
|
2005-07-08 04:57:13 +04:00
|
|
|
|
2005-09-10 02:55:08 +04:00
|
|
|
entry->desc.async.element = element;
|
|
|
|
entry->desc.async.event_type = event;
|
2014-09-14 17:47:52 +04:00
|
|
|
entry->desc.async.reserved = 0;
|
2005-09-10 02:55:08 +04:00
|
|
|
entry->counter = counter;
|
2005-07-08 04:57:13 +04:00
|
|
|
|
2005-09-27 00:53:25 +04:00
|
|
|
list_add_tail(&entry->list, &file->async_file->event_list);
|
2005-09-10 02:55:08 +04:00
|
|
|
if (obj_list)
|
|
|
|
list_add_tail(&entry->obj_list, obj_list);
|
2005-09-27 00:53:25 +04:00
|
|
|
spin_unlock_irqrestore(&file->async_file->lock, flags);
|
2005-07-08 04:57:13 +04:00
|
|
|
|
2005-09-27 00:53:25 +04:00
|
|
|
wake_up_interruptible(&file->async_file->poll_wait);
|
|
|
|
kill_fasync(&file->async_file->async_queue, SIGIO, POLL_IN);
|
2005-07-08 04:57:13 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
void ib_uverbs_cq_event_handler(struct ib_event *event, void *context_ptr)
|
|
|
|
{
|
2005-10-30 20:50:04 +03:00
|
|
|
struct ib_ucq_object *uobj = container_of(event->element.cq->uobject,
|
|
|
|
struct ib_ucq_object, uobject);
|
2005-09-10 02:55:08 +04:00
|
|
|
|
2005-10-30 20:50:04 +03:00
|
|
|
ib_uverbs_async_handler(uobj->uverbs_file, uobj->uobject.user_handle,
|
2005-09-10 02:55:08 +04:00
|
|
|
event->event, &uobj->async_list,
|
|
|
|
&uobj->async_events_reported);
|
2005-07-08 04:57:13 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
void ib_uverbs_qp_event_handler(struct ib_event *event, void *context_ptr)
|
|
|
|
{
|
2005-09-10 02:55:08 +04:00
|
|
|
struct ib_uevent_object *uobj;
|
|
|
|
|
IB/core: Fix XRC race condition in ib_uverbs_open_qp
In ib_uverbs_open_qp, the sharable xrc target qp is created as a
"pseudo" qp and added to a list of qp's sharing the same physical
QP. This is done before the "pseudo" qp is assigned a uobject.
There is a race condition here if an async event arrives at the
physical qp. If the event is handled after the pseudo qp is added to
the list, but before it is assigned a uobject, the kernel crashes in
ib_uverbs_qp_event_handler, due to trying to dereference a NULL
uobject pointer.
Note that simply checking for non-NULL is not enough, due to error
flows in ib_uverbs_open_qp. If the failure is after assigning the
uobject, but before the qp has fully been created, we still have a
problem.
Thus, in ib_uverbs_qp_event_handler, we test that the uobject is
present, and also that it is live.
Reported-by: Matthew Finlay <matt@mellanox.com>
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
2014-09-23 13:38:26 +04:00
|
|
|
/* for XRC target qp's, check that qp is live */
|
|
|
|
if (!event->element.qp->uobject || !event->element.qp->uobject->live)
|
|
|
|
return;
|
|
|
|
|
2005-09-10 02:55:08 +04:00
|
|
|
uobj = container_of(event->element.qp->uobject,
|
|
|
|
struct ib_uevent_object, uobject);
|
|
|
|
|
|
|
|
ib_uverbs_async_handler(context_ptr, uobj->uobject.user_handle,
|
|
|
|
event->event, &uobj->event_list,
|
|
|
|
&uobj->events_reported);
|
2005-07-08 04:57:13 +04:00
|
|
|
}
|
|
|
|
|
2005-08-18 23:24:13 +04:00
|
|
|
void ib_uverbs_srq_event_handler(struct ib_event *event, void *context_ptr)
|
|
|
|
{
|
2005-09-10 02:55:08 +04:00
|
|
|
struct ib_uevent_object *uobj;
|
|
|
|
|
|
|
|
uobj = container_of(event->element.srq->uobject,
|
|
|
|
struct ib_uevent_object, uobject);
|
|
|
|
|
|
|
|
ib_uverbs_async_handler(context_ptr, uobj->uobject.user_handle,
|
|
|
|
event->event, &uobj->event_list,
|
|
|
|
&uobj->events_reported);
|
2005-08-18 23:24:13 +04:00
|
|
|
}
|
|
|
|
|
2005-09-27 00:53:25 +04:00
|
|
|
void ib_uverbs_event_handler(struct ib_event_handler *handler,
|
|
|
|
struct ib_event *event)
|
2005-07-08 04:57:13 +04:00
|
|
|
{
|
|
|
|
struct ib_uverbs_file *file =
|
|
|
|
container_of(handler, struct ib_uverbs_file, event_handler);
|
|
|
|
|
2005-09-10 02:55:08 +04:00
|
|
|
ib_uverbs_async_handler(file, event->element.port_num, event->event,
|
|
|
|
NULL, NULL);
|
2005-07-08 04:57:13 +04:00
|
|
|
}
|
|
|
|
|
2015-08-13 18:32:02 +03:00
|
|
|
void ib_uverbs_free_async_event_file(struct ib_uverbs_file *file)
|
|
|
|
{
|
|
|
|
kref_put(&file->async_file->ref, ib_uverbs_release_event_file);
|
|
|
|
file->async_file = NULL;
|
|
|
|
}
|
|
|
|
|
2005-09-27 00:53:25 +04:00
|
|
|
struct file *ib_uverbs_alloc_event_file(struct ib_uverbs_file *uverbs_file,
|
2015-08-13 18:32:04 +03:00
|
|
|
struct ib_device *ib_dev,
|
2010-01-18 09:38:00 +03:00
|
|
|
int is_async)
|
2005-07-08 04:57:13 +04:00
|
|
|
{
|
2005-09-27 00:53:25 +04:00
|
|
|
struct ib_uverbs_event_file *ev_file;
|
2005-07-08 04:57:13 +04:00
|
|
|
struct file *filp;
|
2015-08-13 18:32:02 +03:00
|
|
|
int ret;
|
2005-07-08 04:57:13 +04:00
|
|
|
|
2015-08-13 18:32:02 +03:00
|
|
|
ev_file = kzalloc(sizeof(*ev_file), GFP_KERNEL);
|
2005-09-27 00:53:25 +04:00
|
|
|
if (!ev_file)
|
|
|
|
return ERR_PTR(-ENOMEM);
|
|
|
|
|
|
|
|
kref_init(&ev_file->ref);
|
|
|
|
spin_lock_init(&ev_file->lock);
|
|
|
|
INIT_LIST_HEAD(&ev_file->event_list);
|
|
|
|
init_waitqueue_head(&ev_file->poll_wait);
|
|
|
|
ev_file->uverbs_file = uverbs_file;
|
2015-08-13 18:32:02 +03:00
|
|
|
kref_get(&ev_file->uverbs_file->ref);
|
2005-09-27 00:53:25 +04:00
|
|
|
ev_file->async_queue = NULL;
|
2008-04-17 08:01:08 +04:00
|
|
|
ev_file->is_closed = 0;
|
2005-09-27 00:53:25 +04:00
|
|
|
|
2010-01-18 09:38:00 +03:00
|
|
|
filp = anon_inode_getfile("[infinibandevent]", &uverbs_event_fops,
|
2010-02-25 03:51:20 +03:00
|
|
|
ev_file, O_RDONLY);
|
2010-01-18 09:38:00 +03:00
|
|
|
if (IS_ERR(filp))
|
2015-08-13 18:32:02 +03:00
|
|
|
goto err_put_refs;
|
|
|
|
|
2015-08-13 18:32:05 +03:00
|
|
|
mutex_lock(&uverbs_file->device->lists_mutex);
|
|
|
|
list_add_tail(&ev_file->list,
|
|
|
|
&uverbs_file->device->uverbs_events_file_list);
|
|
|
|
mutex_unlock(&uverbs_file->device->lists_mutex);
|
|
|
|
|
2015-08-13 18:32:02 +03:00
|
|
|
if (is_async) {
|
|
|
|
WARN_ON(uverbs_file->async_file);
|
|
|
|
uverbs_file->async_file = ev_file;
|
|
|
|
kref_get(&uverbs_file->async_file->ref);
|
|
|
|
INIT_IB_EVENT_HANDLER(&uverbs_file->event_handler,
|
2015-08-13 18:32:04 +03:00
|
|
|
ib_dev,
|
2015-08-13 18:32:02 +03:00
|
|
|
ib_uverbs_event_handler);
|
|
|
|
ret = ib_register_event_handler(&uverbs_file->event_handler);
|
|
|
|
if (ret)
|
|
|
|
goto err_put_file;
|
|
|
|
|
|
|
|
/* At that point async file stuff was fully set */
|
|
|
|
ev_file->is_async = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return filp;
|
|
|
|
|
|
|
|
err_put_file:
|
|
|
|
fput(filp);
|
|
|
|
kref_put(&uverbs_file->async_file->ref, ib_uverbs_release_event_file);
|
|
|
|
uverbs_file->async_file = NULL;
|
|
|
|
return ERR_PTR(ret);
|
2008-04-17 08:01:08 +04:00
|
|
|
|
2015-08-13 18:32:02 +03:00
|
|
|
err_put_refs:
|
|
|
|
kref_put(&ev_file->uverbs_file->ref, ib_uverbs_release_file);
|
|
|
|
kref_put(&ev_file->ref, ib_uverbs_release_event_file);
|
2005-09-27 00:53:25 +04:00
|
|
|
return filp;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Look up a completion event file by FD. If lookup is successful,
|
|
|
|
* takes a ref to the event file struct that it returns; if
|
|
|
|
* unsuccessful, returns NULL.
|
|
|
|
*/
|
|
|
|
struct ib_uverbs_event_file *ib_uverbs_lookup_comp_file(int fd)
|
|
|
|
{
|
|
|
|
struct ib_uverbs_event_file *ev_file = NULL;
|
2012-08-28 20:52:22 +04:00
|
|
|
struct fd f = fdget(fd);
|
2005-09-27 00:53:25 +04:00
|
|
|
|
2012-08-28 20:52:22 +04:00
|
|
|
if (!f.file)
|
2005-09-27 00:53:25 +04:00
|
|
|
return NULL;
|
|
|
|
|
2012-08-28 20:52:22 +04:00
|
|
|
if (f.file->f_op != &uverbs_event_fops)
|
2005-09-27 00:53:25 +04:00
|
|
|
goto out;
|
|
|
|
|
2012-08-28 20:52:22 +04:00
|
|
|
ev_file = f.file->private_data;
|
2005-09-27 00:53:25 +04:00
|
|
|
if (ev_file->is_async) {
|
|
|
|
ev_file = NULL;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
kref_get(&ev_file->ref);
|
|
|
|
|
|
|
|
out:
|
2012-08-28 20:52:22 +04:00
|
|
|
fdput(f);
|
2005-09-27 00:53:25 +04:00
|
|
|
return ev_file;
|
2005-07-08 04:57:13 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t ib_uverbs_write(struct file *filp, const char __user *buf,
|
|
|
|
size_t count, loff_t *pos)
|
|
|
|
{
|
|
|
|
struct ib_uverbs_file *file = filp->private_data;
|
2015-08-13 18:32:05 +03:00
|
|
|
struct ib_device *ib_dev;
|
2005-07-08 04:57:13 +04:00
|
|
|
struct ib_uverbs_cmd_hdr hdr;
|
IB/core: extended command: an improved infrastructure for uverbs commands
Commit 400dbc96583f ("IB/core: Infrastructure for extensible uverbs
commands") added an infrastructure for extensible uverbs commands
while later commit 436f2ad05a0b ("IB/core: Export ib_create/destroy_flow
through uverbs") exported ib_create_flow()/ib_destroy_flow() functions
using this new infrastructure.
According to the commit 400dbc96583f, the purpose of this
infrastructure is to support passing around provider (eg. hardware)
specific buffers when userspace issue commands to the kernel, so that
it would be possible to extend uverbs (eg. core) buffers independently
from the provider buffers.
But the new kernel command function prototypes were not modified to
take advantage of this extension. This issue was exposed by Roland
Dreier in a previous review[1].
So the following patch is an attempt to a revised extensible command
infrastructure.
This improved extensible command infrastructure distinguish between
core (eg. legacy)'s command/response buffers from provider
(eg. hardware)'s command/response buffers: each extended command
implementing function is given a struct ib_udata to hold core
(eg. uverbs) input and output buffers, and another struct ib_udata to
hold the hw (eg. provider) input and output buffers.
Having those buffers identified separately make it easier to increase
one buffer to support extension without having to add some code to
guess the exact size of each command/response parts: This should make
the extended functions more reliable.
Additionally, instead of relying on command identifier being greater
than IB_USER_VERBS_CMD_THRESHOLD, the proposed infrastructure rely on
unused bits in command field: on the 32 bits provided by command
field, only 6 bits are really needed to encode the identifier of
commands currently supported by the kernel. (Even using only 6 bits
leaves room for about 23 new commands).
So this patch makes use of some high order bits in command field to
store flags, leaving enough room for more command identifiers than one
will ever need (eg. 256).
The new flags are used to specify if the command should be processed
as an extended one or a legacy one. While designing the new command
format, care was taken to make usage of flags itself extensible.
Using high order bits of the commands field ensure that newer
libibverbs on older kernel will properly fail when trying to call
extended commands. On the other hand, older libibverbs on newer kernel
will never be able to issue calls to extended commands.
The extended command header includes the optional response pointer so
that output buffer length and output buffer pointer are located
together in the command, allowing proper parameters checking. This
should make implementing functions easier and safer.
Additionally the extended header ensure 64bits alignment, while making
all sizes multiple of 8 bytes, extending the maximum buffer size:
legacy extended
Maximum command buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
Maximum response buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
For the purpose of doing proper buffer size accounting, the headers
size are no more taken in account in "in_words".
One of the odds of the current extensible infrastructure, reading
twice the "legacy" command header, is fixed by removing the "legacy"
command header from the extended command header: they are processed as
two different parts of the command: memory is read once and
information are not duplicated: it's making clear that's an extended
command scheme and not a different command scheme.
The proposed scheme will format input (command) and output (response)
buffers this way:
- command:
legacy header +
extended header +
command data (core + hw):
+----------------------------------------+
| flags | 00 00 | command |
| in_words | out_words |
+----------------------------------------+
| response |
| response |
| provider_in_words | provider_out_words |
| padding |
+----------------------------------------+
| |
. <uverbs input> .
. (in_words * 8) .
| |
+----------------------------------------+
| |
. <provider input> .
. (provider_in_words * 8) .
| |
+----------------------------------------+
- response, if present:
+----------------------------------------+
| |
. <uverbs output space> .
. (out_words * 8) .
| |
+----------------------------------------+
| |
. <provider output space> .
. (provider_out_words * 8) .
| |
+----------------------------------------+
The overall design is to ensure that the extensible infrastructure is
itself extensible while begin more reliable with more input and bound
checking.
Note:
The unused field in the extended header would be perfect candidate to
hold the command "comp_mask" (eg. bit field used to handle
compatibility). This was suggested by Roland Dreier in a previous
review[2]. But "comp_mask" field is likely to be present in the uverb
input and/or provider input, likewise for the response, as noted by
Matan Barak[3], so it doesn't make sense to put "comp_mask" in the
header.
[1]:
http://marc.info/?i=CAL1RGDWxmM17W2o_era24A-TTDeKyoL6u3NRu_=t_dhV_ZA9MA@mail.gmail.com
[2]:
http://marc.info/?i=CAL1RGDXJtrc849M6_XNZT5xO1+ybKtLWGq6yg6LhoSsKpsmkYA@mail.gmail.com
[3]:
http://marc.info/?i=525C1149.6000701@mellanox.com
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Link: http://marc.info/?i=cover.1383773832.git.ydroneaud@opteya.com
[ Convert "ret ? ret : 0" to the equivalent "ret". - Roland ]
Signed-off-by: Roland Dreier <roland@purestorage.com>
2013-11-07 02:21:49 +04:00
|
|
|
__u32 flags;
|
2015-08-13 18:32:05 +03:00
|
|
|
int srcu_key;
|
|
|
|
ssize_t ret;
|
2015-08-13 18:32:04 +03:00
|
|
|
|
2005-07-08 04:57:13 +04:00
|
|
|
if (count < sizeof hdr)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (copy_from_user(&hdr, buf, sizeof hdr))
|
|
|
|
return -EFAULT;
|
|
|
|
|
2015-08-13 18:32:05 +03:00
|
|
|
srcu_key = srcu_read_lock(&file->device->disassociate_srcu);
|
|
|
|
ib_dev = srcu_dereference(file->device->ib_dev,
|
|
|
|
&file->device->disassociate_srcu);
|
|
|
|
if (!ib_dev) {
|
|
|
|
ret = -EIO;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
IB/core: extended command: an improved infrastructure for uverbs commands
Commit 400dbc96583f ("IB/core: Infrastructure for extensible uverbs
commands") added an infrastructure for extensible uverbs commands
while later commit 436f2ad05a0b ("IB/core: Export ib_create/destroy_flow
through uverbs") exported ib_create_flow()/ib_destroy_flow() functions
using this new infrastructure.
According to the commit 400dbc96583f, the purpose of this
infrastructure is to support passing around provider (eg. hardware)
specific buffers when userspace issue commands to the kernel, so that
it would be possible to extend uverbs (eg. core) buffers independently
from the provider buffers.
But the new kernel command function prototypes were not modified to
take advantage of this extension. This issue was exposed by Roland
Dreier in a previous review[1].
So the following patch is an attempt to a revised extensible command
infrastructure.
This improved extensible command infrastructure distinguish between
core (eg. legacy)'s command/response buffers from provider
(eg. hardware)'s command/response buffers: each extended command
implementing function is given a struct ib_udata to hold core
(eg. uverbs) input and output buffers, and another struct ib_udata to
hold the hw (eg. provider) input and output buffers.
Having those buffers identified separately make it easier to increase
one buffer to support extension without having to add some code to
guess the exact size of each command/response parts: This should make
the extended functions more reliable.
Additionally, instead of relying on command identifier being greater
than IB_USER_VERBS_CMD_THRESHOLD, the proposed infrastructure rely on
unused bits in command field: on the 32 bits provided by command
field, only 6 bits are really needed to encode the identifier of
commands currently supported by the kernel. (Even using only 6 bits
leaves room for about 23 new commands).
So this patch makes use of some high order bits in command field to
store flags, leaving enough room for more command identifiers than one
will ever need (eg. 256).
The new flags are used to specify if the command should be processed
as an extended one or a legacy one. While designing the new command
format, care was taken to make usage of flags itself extensible.
Using high order bits of the commands field ensure that newer
libibverbs on older kernel will properly fail when trying to call
extended commands. On the other hand, older libibverbs on newer kernel
will never be able to issue calls to extended commands.
The extended command header includes the optional response pointer so
that output buffer length and output buffer pointer are located
together in the command, allowing proper parameters checking. This
should make implementing functions easier and safer.
Additionally the extended header ensure 64bits alignment, while making
all sizes multiple of 8 bytes, extending the maximum buffer size:
legacy extended
Maximum command buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
Maximum response buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
For the purpose of doing proper buffer size accounting, the headers
size are no more taken in account in "in_words".
One of the odds of the current extensible infrastructure, reading
twice the "legacy" command header, is fixed by removing the "legacy"
command header from the extended command header: they are processed as
two different parts of the command: memory is read once and
information are not duplicated: it's making clear that's an extended
command scheme and not a different command scheme.
The proposed scheme will format input (command) and output (response)
buffers this way:
- command:
legacy header +
extended header +
command data (core + hw):
+----------------------------------------+
| flags | 00 00 | command |
| in_words | out_words |
+----------------------------------------+
| response |
| response |
| provider_in_words | provider_out_words |
| padding |
+----------------------------------------+
| |
. <uverbs input> .
. (in_words * 8) .
| |
+----------------------------------------+
| |
. <provider input> .
. (provider_in_words * 8) .
| |
+----------------------------------------+
- response, if present:
+----------------------------------------+
| |
. <uverbs output space> .
. (out_words * 8) .
| |
+----------------------------------------+
| |
. <provider output space> .
. (provider_out_words * 8) .
| |
+----------------------------------------+
The overall design is to ensure that the extensible infrastructure is
itself extensible while begin more reliable with more input and bound
checking.
Note:
The unused field in the extended header would be perfect candidate to
hold the command "comp_mask" (eg. bit field used to handle
compatibility). This was suggested by Roland Dreier in a previous
review[2]. But "comp_mask" field is likely to be present in the uverb
input and/or provider input, likewise for the response, as noted by
Matan Barak[3], so it doesn't make sense to put "comp_mask" in the
header.
[1]:
http://marc.info/?i=CAL1RGDWxmM17W2o_era24A-TTDeKyoL6u3NRu_=t_dhV_ZA9MA@mail.gmail.com
[2]:
http://marc.info/?i=CAL1RGDXJtrc849M6_XNZT5xO1+ybKtLWGq6yg6LhoSsKpsmkYA@mail.gmail.com
[3]:
http://marc.info/?i=525C1149.6000701@mellanox.com
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Link: http://marc.info/?i=cover.1383773832.git.ydroneaud@opteya.com
[ Convert "ret ? ret : 0" to the equivalent "ret". - Roland ]
Signed-off-by: Roland Dreier <roland@purestorage.com>
2013-11-07 02:21:49 +04:00
|
|
|
flags = (hdr.command &
|
|
|
|
IB_USER_VERBS_CMD_FLAGS_MASK) >> IB_USER_VERBS_CMD_FLAGS_SHIFT;
|
2005-07-08 04:57:13 +04:00
|
|
|
|
IB/core: extended command: an improved infrastructure for uverbs commands
Commit 400dbc96583f ("IB/core: Infrastructure for extensible uverbs
commands") added an infrastructure for extensible uverbs commands
while later commit 436f2ad05a0b ("IB/core: Export ib_create/destroy_flow
through uverbs") exported ib_create_flow()/ib_destroy_flow() functions
using this new infrastructure.
According to the commit 400dbc96583f, the purpose of this
infrastructure is to support passing around provider (eg. hardware)
specific buffers when userspace issue commands to the kernel, so that
it would be possible to extend uverbs (eg. core) buffers independently
from the provider buffers.
But the new kernel command function prototypes were not modified to
take advantage of this extension. This issue was exposed by Roland
Dreier in a previous review[1].
So the following patch is an attempt to a revised extensible command
infrastructure.
This improved extensible command infrastructure distinguish between
core (eg. legacy)'s command/response buffers from provider
(eg. hardware)'s command/response buffers: each extended command
implementing function is given a struct ib_udata to hold core
(eg. uverbs) input and output buffers, and another struct ib_udata to
hold the hw (eg. provider) input and output buffers.
Having those buffers identified separately make it easier to increase
one buffer to support extension without having to add some code to
guess the exact size of each command/response parts: This should make
the extended functions more reliable.
Additionally, instead of relying on command identifier being greater
than IB_USER_VERBS_CMD_THRESHOLD, the proposed infrastructure rely on
unused bits in command field: on the 32 bits provided by command
field, only 6 bits are really needed to encode the identifier of
commands currently supported by the kernel. (Even using only 6 bits
leaves room for about 23 new commands).
So this patch makes use of some high order bits in command field to
store flags, leaving enough room for more command identifiers than one
will ever need (eg. 256).
The new flags are used to specify if the command should be processed
as an extended one or a legacy one. While designing the new command
format, care was taken to make usage of flags itself extensible.
Using high order bits of the commands field ensure that newer
libibverbs on older kernel will properly fail when trying to call
extended commands. On the other hand, older libibverbs on newer kernel
will never be able to issue calls to extended commands.
The extended command header includes the optional response pointer so
that output buffer length and output buffer pointer are located
together in the command, allowing proper parameters checking. This
should make implementing functions easier and safer.
Additionally the extended header ensure 64bits alignment, while making
all sizes multiple of 8 bytes, extending the maximum buffer size:
legacy extended
Maximum command buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
Maximum response buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
For the purpose of doing proper buffer size accounting, the headers
size are no more taken in account in "in_words".
One of the odds of the current extensible infrastructure, reading
twice the "legacy" command header, is fixed by removing the "legacy"
command header from the extended command header: they are processed as
two different parts of the command: memory is read once and
information are not duplicated: it's making clear that's an extended
command scheme and not a different command scheme.
The proposed scheme will format input (command) and output (response)
buffers this way:
- command:
legacy header +
extended header +
command data (core + hw):
+----------------------------------------+
| flags | 00 00 | command |
| in_words | out_words |
+----------------------------------------+
| response |
| response |
| provider_in_words | provider_out_words |
| padding |
+----------------------------------------+
| |
. <uverbs input> .
. (in_words * 8) .
| |
+----------------------------------------+
| |
. <provider input> .
. (provider_in_words * 8) .
| |
+----------------------------------------+
- response, if present:
+----------------------------------------+
| |
. <uverbs output space> .
. (out_words * 8) .
| |
+----------------------------------------+
| |
. <provider output space> .
. (provider_out_words * 8) .
| |
+----------------------------------------+
The overall design is to ensure that the extensible infrastructure is
itself extensible while begin more reliable with more input and bound
checking.
Note:
The unused field in the extended header would be perfect candidate to
hold the command "comp_mask" (eg. bit field used to handle
compatibility). This was suggested by Roland Dreier in a previous
review[2]. But "comp_mask" field is likely to be present in the uverb
input and/or provider input, likewise for the response, as noted by
Matan Barak[3], so it doesn't make sense to put "comp_mask" in the
header.
[1]:
http://marc.info/?i=CAL1RGDWxmM17W2o_era24A-TTDeKyoL6u3NRu_=t_dhV_ZA9MA@mail.gmail.com
[2]:
http://marc.info/?i=CAL1RGDXJtrc849M6_XNZT5xO1+ybKtLWGq6yg6LhoSsKpsmkYA@mail.gmail.com
[3]:
http://marc.info/?i=525C1149.6000701@mellanox.com
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Link: http://marc.info/?i=cover.1383773832.git.ydroneaud@opteya.com
[ Convert "ret ? ret : 0" to the equivalent "ret". - Roland ]
Signed-off-by: Roland Dreier <roland@purestorage.com>
2013-11-07 02:21:49 +04:00
|
|
|
if (!flags) {
|
|
|
|
__u32 command;
|
2005-07-08 04:57:13 +04:00
|
|
|
|
IB/core: extended command: an improved infrastructure for uverbs commands
Commit 400dbc96583f ("IB/core: Infrastructure for extensible uverbs
commands") added an infrastructure for extensible uverbs commands
while later commit 436f2ad05a0b ("IB/core: Export ib_create/destroy_flow
through uverbs") exported ib_create_flow()/ib_destroy_flow() functions
using this new infrastructure.
According to the commit 400dbc96583f, the purpose of this
infrastructure is to support passing around provider (eg. hardware)
specific buffers when userspace issue commands to the kernel, so that
it would be possible to extend uverbs (eg. core) buffers independently
from the provider buffers.
But the new kernel command function prototypes were not modified to
take advantage of this extension. This issue was exposed by Roland
Dreier in a previous review[1].
So the following patch is an attempt to a revised extensible command
infrastructure.
This improved extensible command infrastructure distinguish between
core (eg. legacy)'s command/response buffers from provider
(eg. hardware)'s command/response buffers: each extended command
implementing function is given a struct ib_udata to hold core
(eg. uverbs) input and output buffers, and another struct ib_udata to
hold the hw (eg. provider) input and output buffers.
Having those buffers identified separately make it easier to increase
one buffer to support extension without having to add some code to
guess the exact size of each command/response parts: This should make
the extended functions more reliable.
Additionally, instead of relying on command identifier being greater
than IB_USER_VERBS_CMD_THRESHOLD, the proposed infrastructure rely on
unused bits in command field: on the 32 bits provided by command
field, only 6 bits are really needed to encode the identifier of
commands currently supported by the kernel. (Even using only 6 bits
leaves room for about 23 new commands).
So this patch makes use of some high order bits in command field to
store flags, leaving enough room for more command identifiers than one
will ever need (eg. 256).
The new flags are used to specify if the command should be processed
as an extended one or a legacy one. While designing the new command
format, care was taken to make usage of flags itself extensible.
Using high order bits of the commands field ensure that newer
libibverbs on older kernel will properly fail when trying to call
extended commands. On the other hand, older libibverbs on newer kernel
will never be able to issue calls to extended commands.
The extended command header includes the optional response pointer so
that output buffer length and output buffer pointer are located
together in the command, allowing proper parameters checking. This
should make implementing functions easier and safer.
Additionally the extended header ensure 64bits alignment, while making
all sizes multiple of 8 bytes, extending the maximum buffer size:
legacy extended
Maximum command buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
Maximum response buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
For the purpose of doing proper buffer size accounting, the headers
size are no more taken in account in "in_words".
One of the odds of the current extensible infrastructure, reading
twice the "legacy" command header, is fixed by removing the "legacy"
command header from the extended command header: they are processed as
two different parts of the command: memory is read once and
information are not duplicated: it's making clear that's an extended
command scheme and not a different command scheme.
The proposed scheme will format input (command) and output (response)
buffers this way:
- command:
legacy header +
extended header +
command data (core + hw):
+----------------------------------------+
| flags | 00 00 | command |
| in_words | out_words |
+----------------------------------------+
| response |
| response |
| provider_in_words | provider_out_words |
| padding |
+----------------------------------------+
| |
. <uverbs input> .
. (in_words * 8) .
| |
+----------------------------------------+
| |
. <provider input> .
. (provider_in_words * 8) .
| |
+----------------------------------------+
- response, if present:
+----------------------------------------+
| |
. <uverbs output space> .
. (out_words * 8) .
| |
+----------------------------------------+
| |
. <provider output space> .
. (provider_out_words * 8) .
| |
+----------------------------------------+
The overall design is to ensure that the extensible infrastructure is
itself extensible while begin more reliable with more input and bound
checking.
Note:
The unused field in the extended header would be perfect candidate to
hold the command "comp_mask" (eg. bit field used to handle
compatibility). This was suggested by Roland Dreier in a previous
review[2]. But "comp_mask" field is likely to be present in the uverb
input and/or provider input, likewise for the response, as noted by
Matan Barak[3], so it doesn't make sense to put "comp_mask" in the
header.
[1]:
http://marc.info/?i=CAL1RGDWxmM17W2o_era24A-TTDeKyoL6u3NRu_=t_dhV_ZA9MA@mail.gmail.com
[2]:
http://marc.info/?i=CAL1RGDXJtrc849M6_XNZT5xO1+ybKtLWGq6yg6LhoSsKpsmkYA@mail.gmail.com
[3]:
http://marc.info/?i=525C1149.6000701@mellanox.com
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Link: http://marc.info/?i=cover.1383773832.git.ydroneaud@opteya.com
[ Convert "ret ? ret : 0" to the equivalent "ret". - Roland ]
Signed-off-by: Roland Dreier <roland@purestorage.com>
2013-11-07 02:21:49 +04:00
|
|
|
if (hdr.command & ~(__u32)(IB_USER_VERBS_CMD_FLAGS_MASK |
|
2015-08-13 18:32:05 +03:00
|
|
|
IB_USER_VERBS_CMD_COMMAND_MASK)) {
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
2009-09-06 07:24:24 +04:00
|
|
|
|
IB/core: extended command: an improved infrastructure for uverbs commands
Commit 400dbc96583f ("IB/core: Infrastructure for extensible uverbs
commands") added an infrastructure for extensible uverbs commands
while later commit 436f2ad05a0b ("IB/core: Export ib_create/destroy_flow
through uverbs") exported ib_create_flow()/ib_destroy_flow() functions
using this new infrastructure.
According to the commit 400dbc96583f, the purpose of this
infrastructure is to support passing around provider (eg. hardware)
specific buffers when userspace issue commands to the kernel, so that
it would be possible to extend uverbs (eg. core) buffers independently
from the provider buffers.
But the new kernel command function prototypes were not modified to
take advantage of this extension. This issue was exposed by Roland
Dreier in a previous review[1].
So the following patch is an attempt to a revised extensible command
infrastructure.
This improved extensible command infrastructure distinguish between
core (eg. legacy)'s command/response buffers from provider
(eg. hardware)'s command/response buffers: each extended command
implementing function is given a struct ib_udata to hold core
(eg. uverbs) input and output buffers, and another struct ib_udata to
hold the hw (eg. provider) input and output buffers.
Having those buffers identified separately make it easier to increase
one buffer to support extension without having to add some code to
guess the exact size of each command/response parts: This should make
the extended functions more reliable.
Additionally, instead of relying on command identifier being greater
than IB_USER_VERBS_CMD_THRESHOLD, the proposed infrastructure rely on
unused bits in command field: on the 32 bits provided by command
field, only 6 bits are really needed to encode the identifier of
commands currently supported by the kernel. (Even using only 6 bits
leaves room for about 23 new commands).
So this patch makes use of some high order bits in command field to
store flags, leaving enough room for more command identifiers than one
will ever need (eg. 256).
The new flags are used to specify if the command should be processed
as an extended one or a legacy one. While designing the new command
format, care was taken to make usage of flags itself extensible.
Using high order bits of the commands field ensure that newer
libibverbs on older kernel will properly fail when trying to call
extended commands. On the other hand, older libibverbs on newer kernel
will never be able to issue calls to extended commands.
The extended command header includes the optional response pointer so
that output buffer length and output buffer pointer are located
together in the command, allowing proper parameters checking. This
should make implementing functions easier and safer.
Additionally the extended header ensure 64bits alignment, while making
all sizes multiple of 8 bytes, extending the maximum buffer size:
legacy extended
Maximum command buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
Maximum response buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
For the purpose of doing proper buffer size accounting, the headers
size are no more taken in account in "in_words".
One of the odds of the current extensible infrastructure, reading
twice the "legacy" command header, is fixed by removing the "legacy"
command header from the extended command header: they are processed as
two different parts of the command: memory is read once and
information are not duplicated: it's making clear that's an extended
command scheme and not a different command scheme.
The proposed scheme will format input (command) and output (response)
buffers this way:
- command:
legacy header +
extended header +
command data (core + hw):
+----------------------------------------+
| flags | 00 00 | command |
| in_words | out_words |
+----------------------------------------+
| response |
| response |
| provider_in_words | provider_out_words |
| padding |
+----------------------------------------+
| |
. <uverbs input> .
. (in_words * 8) .
| |
+----------------------------------------+
| |
. <provider input> .
. (provider_in_words * 8) .
| |
+----------------------------------------+
- response, if present:
+----------------------------------------+
| |
. <uverbs output space> .
. (out_words * 8) .
| |
+----------------------------------------+
| |
. <provider output space> .
. (provider_out_words * 8) .
| |
+----------------------------------------+
The overall design is to ensure that the extensible infrastructure is
itself extensible while begin more reliable with more input and bound
checking.
Note:
The unused field in the extended header would be perfect candidate to
hold the command "comp_mask" (eg. bit field used to handle
compatibility). This was suggested by Roland Dreier in a previous
review[2]. But "comp_mask" field is likely to be present in the uverb
input and/or provider input, likewise for the response, as noted by
Matan Barak[3], so it doesn't make sense to put "comp_mask" in the
header.
[1]:
http://marc.info/?i=CAL1RGDWxmM17W2o_era24A-TTDeKyoL6u3NRu_=t_dhV_ZA9MA@mail.gmail.com
[2]:
http://marc.info/?i=CAL1RGDXJtrc849M6_XNZT5xO1+ybKtLWGq6yg6LhoSsKpsmkYA@mail.gmail.com
[3]:
http://marc.info/?i=525C1149.6000701@mellanox.com
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Link: http://marc.info/?i=cover.1383773832.git.ydroneaud@opteya.com
[ Convert "ret ? ret : 0" to the equivalent "ret". - Roland ]
Signed-off-by: Roland Dreier <roland@purestorage.com>
2013-11-07 02:21:49 +04:00
|
|
|
command = hdr.command & IB_USER_VERBS_CMD_COMMAND_MASK;
|
2013-08-14 14:58:29 +04:00
|
|
|
|
IB/core: extended command: an improved infrastructure for uverbs commands
Commit 400dbc96583f ("IB/core: Infrastructure for extensible uverbs
commands") added an infrastructure for extensible uverbs commands
while later commit 436f2ad05a0b ("IB/core: Export ib_create/destroy_flow
through uverbs") exported ib_create_flow()/ib_destroy_flow() functions
using this new infrastructure.
According to the commit 400dbc96583f, the purpose of this
infrastructure is to support passing around provider (eg. hardware)
specific buffers when userspace issue commands to the kernel, so that
it would be possible to extend uverbs (eg. core) buffers independently
from the provider buffers.
But the new kernel command function prototypes were not modified to
take advantage of this extension. This issue was exposed by Roland
Dreier in a previous review[1].
So the following patch is an attempt to a revised extensible command
infrastructure.
This improved extensible command infrastructure distinguish between
core (eg. legacy)'s command/response buffers from provider
(eg. hardware)'s command/response buffers: each extended command
implementing function is given a struct ib_udata to hold core
(eg. uverbs) input and output buffers, and another struct ib_udata to
hold the hw (eg. provider) input and output buffers.
Having those buffers identified separately make it easier to increase
one buffer to support extension without having to add some code to
guess the exact size of each command/response parts: This should make
the extended functions more reliable.
Additionally, instead of relying on command identifier being greater
than IB_USER_VERBS_CMD_THRESHOLD, the proposed infrastructure rely on
unused bits in command field: on the 32 bits provided by command
field, only 6 bits are really needed to encode the identifier of
commands currently supported by the kernel. (Even using only 6 bits
leaves room for about 23 new commands).
So this patch makes use of some high order bits in command field to
store flags, leaving enough room for more command identifiers than one
will ever need (eg. 256).
The new flags are used to specify if the command should be processed
as an extended one or a legacy one. While designing the new command
format, care was taken to make usage of flags itself extensible.
Using high order bits of the commands field ensure that newer
libibverbs on older kernel will properly fail when trying to call
extended commands. On the other hand, older libibverbs on newer kernel
will never be able to issue calls to extended commands.
The extended command header includes the optional response pointer so
that output buffer length and output buffer pointer are located
together in the command, allowing proper parameters checking. This
should make implementing functions easier and safer.
Additionally the extended header ensure 64bits alignment, while making
all sizes multiple of 8 bytes, extending the maximum buffer size:
legacy extended
Maximum command buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
Maximum response buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
For the purpose of doing proper buffer size accounting, the headers
size are no more taken in account in "in_words".
One of the odds of the current extensible infrastructure, reading
twice the "legacy" command header, is fixed by removing the "legacy"
command header from the extended command header: they are processed as
two different parts of the command: memory is read once and
information are not duplicated: it's making clear that's an extended
command scheme and not a different command scheme.
The proposed scheme will format input (command) and output (response)
buffers this way:
- command:
legacy header +
extended header +
command data (core + hw):
+----------------------------------------+
| flags | 00 00 | command |
| in_words | out_words |
+----------------------------------------+
| response |
| response |
| provider_in_words | provider_out_words |
| padding |
+----------------------------------------+
| |
. <uverbs input> .
. (in_words * 8) .
| |
+----------------------------------------+
| |
. <provider input> .
. (provider_in_words * 8) .
| |
+----------------------------------------+
- response, if present:
+----------------------------------------+
| |
. <uverbs output space> .
. (out_words * 8) .
| |
+----------------------------------------+
| |
. <provider output space> .
. (provider_out_words * 8) .
| |
+----------------------------------------+
The overall design is to ensure that the extensible infrastructure is
itself extensible while begin more reliable with more input and bound
checking.
Note:
The unused field in the extended header would be perfect candidate to
hold the command "comp_mask" (eg. bit field used to handle
compatibility). This was suggested by Roland Dreier in a previous
review[2]. But "comp_mask" field is likely to be present in the uverb
input and/or provider input, likewise for the response, as noted by
Matan Barak[3], so it doesn't make sense to put "comp_mask" in the
header.
[1]:
http://marc.info/?i=CAL1RGDWxmM17W2o_era24A-TTDeKyoL6u3NRu_=t_dhV_ZA9MA@mail.gmail.com
[2]:
http://marc.info/?i=CAL1RGDXJtrc849M6_XNZT5xO1+ybKtLWGq6yg6LhoSsKpsmkYA@mail.gmail.com
[3]:
http://marc.info/?i=525C1149.6000701@mellanox.com
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Link: http://marc.info/?i=cover.1383773832.git.ydroneaud@opteya.com
[ Convert "ret ? ret : 0" to the equivalent "ret". - Roland ]
Signed-off-by: Roland Dreier <roland@purestorage.com>
2013-11-07 02:21:49 +04:00
|
|
|
if (command >= ARRAY_SIZE(uverbs_cmd_table) ||
|
2015-08-13 18:32:05 +03:00
|
|
|
!uverbs_cmd_table[command]) {
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
2013-08-14 14:58:29 +04:00
|
|
|
|
IB/core: extended command: an improved infrastructure for uverbs commands
Commit 400dbc96583f ("IB/core: Infrastructure for extensible uverbs
commands") added an infrastructure for extensible uverbs commands
while later commit 436f2ad05a0b ("IB/core: Export ib_create/destroy_flow
through uverbs") exported ib_create_flow()/ib_destroy_flow() functions
using this new infrastructure.
According to the commit 400dbc96583f, the purpose of this
infrastructure is to support passing around provider (eg. hardware)
specific buffers when userspace issue commands to the kernel, so that
it would be possible to extend uverbs (eg. core) buffers independently
from the provider buffers.
But the new kernel command function prototypes were not modified to
take advantage of this extension. This issue was exposed by Roland
Dreier in a previous review[1].
So the following patch is an attempt to a revised extensible command
infrastructure.
This improved extensible command infrastructure distinguish between
core (eg. legacy)'s command/response buffers from provider
(eg. hardware)'s command/response buffers: each extended command
implementing function is given a struct ib_udata to hold core
(eg. uverbs) input and output buffers, and another struct ib_udata to
hold the hw (eg. provider) input and output buffers.
Having those buffers identified separately make it easier to increase
one buffer to support extension without having to add some code to
guess the exact size of each command/response parts: This should make
the extended functions more reliable.
Additionally, instead of relying on command identifier being greater
than IB_USER_VERBS_CMD_THRESHOLD, the proposed infrastructure rely on
unused bits in command field: on the 32 bits provided by command
field, only 6 bits are really needed to encode the identifier of
commands currently supported by the kernel. (Even using only 6 bits
leaves room for about 23 new commands).
So this patch makes use of some high order bits in command field to
store flags, leaving enough room for more command identifiers than one
will ever need (eg. 256).
The new flags are used to specify if the command should be processed
as an extended one or a legacy one. While designing the new command
format, care was taken to make usage of flags itself extensible.
Using high order bits of the commands field ensure that newer
libibverbs on older kernel will properly fail when trying to call
extended commands. On the other hand, older libibverbs on newer kernel
will never be able to issue calls to extended commands.
The extended command header includes the optional response pointer so
that output buffer length and output buffer pointer are located
together in the command, allowing proper parameters checking. This
should make implementing functions easier and safer.
Additionally the extended header ensure 64bits alignment, while making
all sizes multiple of 8 bytes, extending the maximum buffer size:
legacy extended
Maximum command buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
Maximum response buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
For the purpose of doing proper buffer size accounting, the headers
size are no more taken in account in "in_words".
One of the odds of the current extensible infrastructure, reading
twice the "legacy" command header, is fixed by removing the "legacy"
command header from the extended command header: they are processed as
two different parts of the command: memory is read once and
information are not duplicated: it's making clear that's an extended
command scheme and not a different command scheme.
The proposed scheme will format input (command) and output (response)
buffers this way:
- command:
legacy header +
extended header +
command data (core + hw):
+----------------------------------------+
| flags | 00 00 | command |
| in_words | out_words |
+----------------------------------------+
| response |
| response |
| provider_in_words | provider_out_words |
| padding |
+----------------------------------------+
| |
. <uverbs input> .
. (in_words * 8) .
| |
+----------------------------------------+
| |
. <provider input> .
. (provider_in_words * 8) .
| |
+----------------------------------------+
- response, if present:
+----------------------------------------+
| |
. <uverbs output space> .
. (out_words * 8) .
| |
+----------------------------------------+
| |
. <provider output space> .
. (provider_out_words * 8) .
| |
+----------------------------------------+
The overall design is to ensure that the extensible infrastructure is
itself extensible while begin more reliable with more input and bound
checking.
Note:
The unused field in the extended header would be perfect candidate to
hold the command "comp_mask" (eg. bit field used to handle
compatibility). This was suggested by Roland Dreier in a previous
review[2]. But "comp_mask" field is likely to be present in the uverb
input and/or provider input, likewise for the response, as noted by
Matan Barak[3], so it doesn't make sense to put "comp_mask" in the
header.
[1]:
http://marc.info/?i=CAL1RGDWxmM17W2o_era24A-TTDeKyoL6u3NRu_=t_dhV_ZA9MA@mail.gmail.com
[2]:
http://marc.info/?i=CAL1RGDXJtrc849M6_XNZT5xO1+ybKtLWGq6yg6LhoSsKpsmkYA@mail.gmail.com
[3]:
http://marc.info/?i=525C1149.6000701@mellanox.com
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Link: http://marc.info/?i=cover.1383773832.git.ydroneaud@opteya.com
[ Convert "ret ? ret : 0" to the equivalent "ret". - Roland ]
Signed-off-by: Roland Dreier <roland@purestorage.com>
2013-11-07 02:21:49 +04:00
|
|
|
if (!file->ucontext &&
|
2015-08-13 18:32:05 +03:00
|
|
|
command != IB_USER_VERBS_CMD_GET_CONTEXT) {
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
2013-08-14 14:58:29 +04:00
|
|
|
|
2015-08-13 18:32:05 +03:00
|
|
|
if (!(ib_dev->uverbs_cmd_mask & (1ull << command))) {
|
|
|
|
ret = -ENOSYS;
|
|
|
|
goto out;
|
|
|
|
}
|
IB/core: extended command: an improved infrastructure for uverbs commands
Commit 400dbc96583f ("IB/core: Infrastructure for extensible uverbs
commands") added an infrastructure for extensible uverbs commands
while later commit 436f2ad05a0b ("IB/core: Export ib_create/destroy_flow
through uverbs") exported ib_create_flow()/ib_destroy_flow() functions
using this new infrastructure.
According to the commit 400dbc96583f, the purpose of this
infrastructure is to support passing around provider (eg. hardware)
specific buffers when userspace issue commands to the kernel, so that
it would be possible to extend uverbs (eg. core) buffers independently
from the provider buffers.
But the new kernel command function prototypes were not modified to
take advantage of this extension. This issue was exposed by Roland
Dreier in a previous review[1].
So the following patch is an attempt to a revised extensible command
infrastructure.
This improved extensible command infrastructure distinguish between
core (eg. legacy)'s command/response buffers from provider
(eg. hardware)'s command/response buffers: each extended command
implementing function is given a struct ib_udata to hold core
(eg. uverbs) input and output buffers, and another struct ib_udata to
hold the hw (eg. provider) input and output buffers.
Having those buffers identified separately make it easier to increase
one buffer to support extension without having to add some code to
guess the exact size of each command/response parts: This should make
the extended functions more reliable.
Additionally, instead of relying on command identifier being greater
than IB_USER_VERBS_CMD_THRESHOLD, the proposed infrastructure rely on
unused bits in command field: on the 32 bits provided by command
field, only 6 bits are really needed to encode the identifier of
commands currently supported by the kernel. (Even using only 6 bits
leaves room for about 23 new commands).
So this patch makes use of some high order bits in command field to
store flags, leaving enough room for more command identifiers than one
will ever need (eg. 256).
The new flags are used to specify if the command should be processed
as an extended one or a legacy one. While designing the new command
format, care was taken to make usage of flags itself extensible.
Using high order bits of the commands field ensure that newer
libibverbs on older kernel will properly fail when trying to call
extended commands. On the other hand, older libibverbs on newer kernel
will never be able to issue calls to extended commands.
The extended command header includes the optional response pointer so
that output buffer length and output buffer pointer are located
together in the command, allowing proper parameters checking. This
should make implementing functions easier and safer.
Additionally the extended header ensure 64bits alignment, while making
all sizes multiple of 8 bytes, extending the maximum buffer size:
legacy extended
Maximum command buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
Maximum response buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
For the purpose of doing proper buffer size accounting, the headers
size are no more taken in account in "in_words".
One of the odds of the current extensible infrastructure, reading
twice the "legacy" command header, is fixed by removing the "legacy"
command header from the extended command header: they are processed as
two different parts of the command: memory is read once and
information are not duplicated: it's making clear that's an extended
command scheme and not a different command scheme.
The proposed scheme will format input (command) and output (response)
buffers this way:
- command:
legacy header +
extended header +
command data (core + hw):
+----------------------------------------+
| flags | 00 00 | command |
| in_words | out_words |
+----------------------------------------+
| response |
| response |
| provider_in_words | provider_out_words |
| padding |
+----------------------------------------+
| |
. <uverbs input> .
. (in_words * 8) .
| |
+----------------------------------------+
| |
. <provider input> .
. (provider_in_words * 8) .
| |
+----------------------------------------+
- response, if present:
+----------------------------------------+
| |
. <uverbs output space> .
. (out_words * 8) .
| |
+----------------------------------------+
| |
. <provider output space> .
. (provider_out_words * 8) .
| |
+----------------------------------------+
The overall design is to ensure that the extensible infrastructure is
itself extensible while begin more reliable with more input and bound
checking.
Note:
The unused field in the extended header would be perfect candidate to
hold the command "comp_mask" (eg. bit field used to handle
compatibility). This was suggested by Roland Dreier in a previous
review[2]. But "comp_mask" field is likely to be present in the uverb
input and/or provider input, likewise for the response, as noted by
Matan Barak[3], so it doesn't make sense to put "comp_mask" in the
header.
[1]:
http://marc.info/?i=CAL1RGDWxmM17W2o_era24A-TTDeKyoL6u3NRu_=t_dhV_ZA9MA@mail.gmail.com
[2]:
http://marc.info/?i=CAL1RGDXJtrc849M6_XNZT5xO1+ybKtLWGq6yg6LhoSsKpsmkYA@mail.gmail.com
[3]:
http://marc.info/?i=525C1149.6000701@mellanox.com
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Link: http://marc.info/?i=cover.1383773832.git.ydroneaud@opteya.com
[ Convert "ret ? ret : 0" to the equivalent "ret". - Roland ]
Signed-off-by: Roland Dreier <roland@purestorage.com>
2013-11-07 02:21:49 +04:00
|
|
|
|
2015-08-13 18:32:05 +03:00
|
|
|
if (hdr.in_words * 4 != count) {
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
2013-08-14 14:58:29 +04:00
|
|
|
|
2015-08-13 18:32:05 +03:00
|
|
|
ret = uverbs_cmd_table[command](file, ib_dev,
|
IB/core: extended command: an improved infrastructure for uverbs commands
Commit 400dbc96583f ("IB/core: Infrastructure for extensible uverbs
commands") added an infrastructure for extensible uverbs commands
while later commit 436f2ad05a0b ("IB/core: Export ib_create/destroy_flow
through uverbs") exported ib_create_flow()/ib_destroy_flow() functions
using this new infrastructure.
According to the commit 400dbc96583f, the purpose of this
infrastructure is to support passing around provider (eg. hardware)
specific buffers when userspace issue commands to the kernel, so that
it would be possible to extend uverbs (eg. core) buffers independently
from the provider buffers.
But the new kernel command function prototypes were not modified to
take advantage of this extension. This issue was exposed by Roland
Dreier in a previous review[1].
So the following patch is an attempt to a revised extensible command
infrastructure.
This improved extensible command infrastructure distinguish between
core (eg. legacy)'s command/response buffers from provider
(eg. hardware)'s command/response buffers: each extended command
implementing function is given a struct ib_udata to hold core
(eg. uverbs) input and output buffers, and another struct ib_udata to
hold the hw (eg. provider) input and output buffers.
Having those buffers identified separately make it easier to increase
one buffer to support extension without having to add some code to
guess the exact size of each command/response parts: This should make
the extended functions more reliable.
Additionally, instead of relying on command identifier being greater
than IB_USER_VERBS_CMD_THRESHOLD, the proposed infrastructure rely on
unused bits in command field: on the 32 bits provided by command
field, only 6 bits are really needed to encode the identifier of
commands currently supported by the kernel. (Even using only 6 bits
leaves room for about 23 new commands).
So this patch makes use of some high order bits in command field to
store flags, leaving enough room for more command identifiers than one
will ever need (eg. 256).
The new flags are used to specify if the command should be processed
as an extended one or a legacy one. While designing the new command
format, care was taken to make usage of flags itself extensible.
Using high order bits of the commands field ensure that newer
libibverbs on older kernel will properly fail when trying to call
extended commands. On the other hand, older libibverbs on newer kernel
will never be able to issue calls to extended commands.
The extended command header includes the optional response pointer so
that output buffer length and output buffer pointer are located
together in the command, allowing proper parameters checking. This
should make implementing functions easier and safer.
Additionally the extended header ensure 64bits alignment, while making
all sizes multiple of 8 bytes, extending the maximum buffer size:
legacy extended
Maximum command buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
Maximum response buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
For the purpose of doing proper buffer size accounting, the headers
size are no more taken in account in "in_words".
One of the odds of the current extensible infrastructure, reading
twice the "legacy" command header, is fixed by removing the "legacy"
command header from the extended command header: they are processed as
two different parts of the command: memory is read once and
information are not duplicated: it's making clear that's an extended
command scheme and not a different command scheme.
The proposed scheme will format input (command) and output (response)
buffers this way:
- command:
legacy header +
extended header +
command data (core + hw):
+----------------------------------------+
| flags | 00 00 | command |
| in_words | out_words |
+----------------------------------------+
| response |
| response |
| provider_in_words | provider_out_words |
| padding |
+----------------------------------------+
| |
. <uverbs input> .
. (in_words * 8) .
| |
+----------------------------------------+
| |
. <provider input> .
. (provider_in_words * 8) .
| |
+----------------------------------------+
- response, if present:
+----------------------------------------+
| |
. <uverbs output space> .
. (out_words * 8) .
| |
+----------------------------------------+
| |
. <provider output space> .
. (provider_out_words * 8) .
| |
+----------------------------------------+
The overall design is to ensure that the extensible infrastructure is
itself extensible while begin more reliable with more input and bound
checking.
Note:
The unused field in the extended header would be perfect candidate to
hold the command "comp_mask" (eg. bit field used to handle
compatibility). This was suggested by Roland Dreier in a previous
review[2]. But "comp_mask" field is likely to be present in the uverb
input and/or provider input, likewise for the response, as noted by
Matan Barak[3], so it doesn't make sense to put "comp_mask" in the
header.
[1]:
http://marc.info/?i=CAL1RGDWxmM17W2o_era24A-TTDeKyoL6u3NRu_=t_dhV_ZA9MA@mail.gmail.com
[2]:
http://marc.info/?i=CAL1RGDXJtrc849M6_XNZT5xO1+ybKtLWGq6yg6LhoSsKpsmkYA@mail.gmail.com
[3]:
http://marc.info/?i=525C1149.6000701@mellanox.com
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Link: http://marc.info/?i=cover.1383773832.git.ydroneaud@opteya.com
[ Convert "ret ? ret : 0" to the equivalent "ret". - Roland ]
Signed-off-by: Roland Dreier <roland@purestorage.com>
2013-11-07 02:21:49 +04:00
|
|
|
buf + sizeof(hdr),
|
|
|
|
hdr.in_words * 4,
|
|
|
|
hdr.out_words * 4);
|
|
|
|
|
|
|
|
} else if (flags == IB_USER_VERBS_CMD_FLAG_EXTENDED) {
|
|
|
|
__u32 command;
|
|
|
|
|
|
|
|
struct ib_uverbs_ex_cmd_hdr ex_hdr;
|
|
|
|
struct ib_udata ucore;
|
|
|
|
struct ib_udata uhw;
|
|
|
|
size_t written_count = count;
|
|
|
|
|
|
|
|
if (hdr.command & ~(__u32)(IB_USER_VERBS_CMD_FLAGS_MASK |
|
2015-08-13 18:32:05 +03:00
|
|
|
IB_USER_VERBS_CMD_COMMAND_MASK)) {
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
IB/core: extended command: an improved infrastructure for uverbs commands
Commit 400dbc96583f ("IB/core: Infrastructure for extensible uverbs
commands") added an infrastructure for extensible uverbs commands
while later commit 436f2ad05a0b ("IB/core: Export ib_create/destroy_flow
through uverbs") exported ib_create_flow()/ib_destroy_flow() functions
using this new infrastructure.
According to the commit 400dbc96583f, the purpose of this
infrastructure is to support passing around provider (eg. hardware)
specific buffers when userspace issue commands to the kernel, so that
it would be possible to extend uverbs (eg. core) buffers independently
from the provider buffers.
But the new kernel command function prototypes were not modified to
take advantage of this extension. This issue was exposed by Roland
Dreier in a previous review[1].
So the following patch is an attempt to a revised extensible command
infrastructure.
This improved extensible command infrastructure distinguish between
core (eg. legacy)'s command/response buffers from provider
(eg. hardware)'s command/response buffers: each extended command
implementing function is given a struct ib_udata to hold core
(eg. uverbs) input and output buffers, and another struct ib_udata to
hold the hw (eg. provider) input and output buffers.
Having those buffers identified separately make it easier to increase
one buffer to support extension without having to add some code to
guess the exact size of each command/response parts: This should make
the extended functions more reliable.
Additionally, instead of relying on command identifier being greater
than IB_USER_VERBS_CMD_THRESHOLD, the proposed infrastructure rely on
unused bits in command field: on the 32 bits provided by command
field, only 6 bits are really needed to encode the identifier of
commands currently supported by the kernel. (Even using only 6 bits
leaves room for about 23 new commands).
So this patch makes use of some high order bits in command field to
store flags, leaving enough room for more command identifiers than one
will ever need (eg. 256).
The new flags are used to specify if the command should be processed
as an extended one or a legacy one. While designing the new command
format, care was taken to make usage of flags itself extensible.
Using high order bits of the commands field ensure that newer
libibverbs on older kernel will properly fail when trying to call
extended commands. On the other hand, older libibverbs on newer kernel
will never be able to issue calls to extended commands.
The extended command header includes the optional response pointer so
that output buffer length and output buffer pointer are located
together in the command, allowing proper parameters checking. This
should make implementing functions easier and safer.
Additionally the extended header ensure 64bits alignment, while making
all sizes multiple of 8 bytes, extending the maximum buffer size:
legacy extended
Maximum command buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
Maximum response buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
For the purpose of doing proper buffer size accounting, the headers
size are no more taken in account in "in_words".
One of the odds of the current extensible infrastructure, reading
twice the "legacy" command header, is fixed by removing the "legacy"
command header from the extended command header: they are processed as
two different parts of the command: memory is read once and
information are not duplicated: it's making clear that's an extended
command scheme and not a different command scheme.
The proposed scheme will format input (command) and output (response)
buffers this way:
- command:
legacy header +
extended header +
command data (core + hw):
+----------------------------------------+
| flags | 00 00 | command |
| in_words | out_words |
+----------------------------------------+
| response |
| response |
| provider_in_words | provider_out_words |
| padding |
+----------------------------------------+
| |
. <uverbs input> .
. (in_words * 8) .
| |
+----------------------------------------+
| |
. <provider input> .
. (provider_in_words * 8) .
| |
+----------------------------------------+
- response, if present:
+----------------------------------------+
| |
. <uverbs output space> .
. (out_words * 8) .
| |
+----------------------------------------+
| |
. <provider output space> .
. (provider_out_words * 8) .
| |
+----------------------------------------+
The overall design is to ensure that the extensible infrastructure is
itself extensible while begin more reliable with more input and bound
checking.
Note:
The unused field in the extended header would be perfect candidate to
hold the command "comp_mask" (eg. bit field used to handle
compatibility). This was suggested by Roland Dreier in a previous
review[2]. But "comp_mask" field is likely to be present in the uverb
input and/or provider input, likewise for the response, as noted by
Matan Barak[3], so it doesn't make sense to put "comp_mask" in the
header.
[1]:
http://marc.info/?i=CAL1RGDWxmM17W2o_era24A-TTDeKyoL6u3NRu_=t_dhV_ZA9MA@mail.gmail.com
[2]:
http://marc.info/?i=CAL1RGDXJtrc849M6_XNZT5xO1+ybKtLWGq6yg6LhoSsKpsmkYA@mail.gmail.com
[3]:
http://marc.info/?i=525C1149.6000701@mellanox.com
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Link: http://marc.info/?i=cover.1383773832.git.ydroneaud@opteya.com
[ Convert "ret ? ret : 0" to the equivalent "ret". - Roland ]
Signed-off-by: Roland Dreier <roland@purestorage.com>
2013-11-07 02:21:49 +04:00
|
|
|
|
|
|
|
command = hdr.command & IB_USER_VERBS_CMD_COMMAND_MASK;
|
|
|
|
|
|
|
|
if (command >= ARRAY_SIZE(uverbs_ex_cmd_table) ||
|
2015-08-13 18:32:05 +03:00
|
|
|
!uverbs_ex_cmd_table[command]) {
|
|
|
|
ret = -ENOSYS;
|
|
|
|
goto out;
|
|
|
|
}
|
IB/core: extended command: an improved infrastructure for uverbs commands
Commit 400dbc96583f ("IB/core: Infrastructure for extensible uverbs
commands") added an infrastructure for extensible uverbs commands
while later commit 436f2ad05a0b ("IB/core: Export ib_create/destroy_flow
through uverbs") exported ib_create_flow()/ib_destroy_flow() functions
using this new infrastructure.
According to the commit 400dbc96583f, the purpose of this
infrastructure is to support passing around provider (eg. hardware)
specific buffers when userspace issue commands to the kernel, so that
it would be possible to extend uverbs (eg. core) buffers independently
from the provider buffers.
But the new kernel command function prototypes were not modified to
take advantage of this extension. This issue was exposed by Roland
Dreier in a previous review[1].
So the following patch is an attempt to a revised extensible command
infrastructure.
This improved extensible command infrastructure distinguish between
core (eg. legacy)'s command/response buffers from provider
(eg. hardware)'s command/response buffers: each extended command
implementing function is given a struct ib_udata to hold core
(eg. uverbs) input and output buffers, and another struct ib_udata to
hold the hw (eg. provider) input and output buffers.
Having those buffers identified separately make it easier to increase
one buffer to support extension without having to add some code to
guess the exact size of each command/response parts: This should make
the extended functions more reliable.
Additionally, instead of relying on command identifier being greater
than IB_USER_VERBS_CMD_THRESHOLD, the proposed infrastructure rely on
unused bits in command field: on the 32 bits provided by command
field, only 6 bits are really needed to encode the identifier of
commands currently supported by the kernel. (Even using only 6 bits
leaves room for about 23 new commands).
So this patch makes use of some high order bits in command field to
store flags, leaving enough room for more command identifiers than one
will ever need (eg. 256).
The new flags are used to specify if the command should be processed
as an extended one or a legacy one. While designing the new command
format, care was taken to make usage of flags itself extensible.
Using high order bits of the commands field ensure that newer
libibverbs on older kernel will properly fail when trying to call
extended commands. On the other hand, older libibverbs on newer kernel
will never be able to issue calls to extended commands.
The extended command header includes the optional response pointer so
that output buffer length and output buffer pointer are located
together in the command, allowing proper parameters checking. This
should make implementing functions easier and safer.
Additionally the extended header ensure 64bits alignment, while making
all sizes multiple of 8 bytes, extending the maximum buffer size:
legacy extended
Maximum command buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
Maximum response buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
For the purpose of doing proper buffer size accounting, the headers
size are no more taken in account in "in_words".
One of the odds of the current extensible infrastructure, reading
twice the "legacy" command header, is fixed by removing the "legacy"
command header from the extended command header: they are processed as
two different parts of the command: memory is read once and
information are not duplicated: it's making clear that's an extended
command scheme and not a different command scheme.
The proposed scheme will format input (command) and output (response)
buffers this way:
- command:
legacy header +
extended header +
command data (core + hw):
+----------------------------------------+
| flags | 00 00 | command |
| in_words | out_words |
+----------------------------------------+
| response |
| response |
| provider_in_words | provider_out_words |
| padding |
+----------------------------------------+
| |
. <uverbs input> .
. (in_words * 8) .
| |
+----------------------------------------+
| |
. <provider input> .
. (provider_in_words * 8) .
| |
+----------------------------------------+
- response, if present:
+----------------------------------------+
| |
. <uverbs output space> .
. (out_words * 8) .
| |
+----------------------------------------+
| |
. <provider output space> .
. (provider_out_words * 8) .
| |
+----------------------------------------+
The overall design is to ensure that the extensible infrastructure is
itself extensible while begin more reliable with more input and bound
checking.
Note:
The unused field in the extended header would be perfect candidate to
hold the command "comp_mask" (eg. bit field used to handle
compatibility). This was suggested by Roland Dreier in a previous
review[2]. But "comp_mask" field is likely to be present in the uverb
input and/or provider input, likewise for the response, as noted by
Matan Barak[3], so it doesn't make sense to put "comp_mask" in the
header.
[1]:
http://marc.info/?i=CAL1RGDWxmM17W2o_era24A-TTDeKyoL6u3NRu_=t_dhV_ZA9MA@mail.gmail.com
[2]:
http://marc.info/?i=CAL1RGDXJtrc849M6_XNZT5xO1+ybKtLWGq6yg6LhoSsKpsmkYA@mail.gmail.com
[3]:
http://marc.info/?i=525C1149.6000701@mellanox.com
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Link: http://marc.info/?i=cover.1383773832.git.ydroneaud@opteya.com
[ Convert "ret ? ret : 0" to the equivalent "ret". - Roland ]
Signed-off-by: Roland Dreier <roland@purestorage.com>
2013-11-07 02:21:49 +04:00
|
|
|
|
2015-08-13 18:32:05 +03:00
|
|
|
if (!file->ucontext) {
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
IB/core: extended command: an improved infrastructure for uverbs commands
Commit 400dbc96583f ("IB/core: Infrastructure for extensible uverbs
commands") added an infrastructure for extensible uverbs commands
while later commit 436f2ad05a0b ("IB/core: Export ib_create/destroy_flow
through uverbs") exported ib_create_flow()/ib_destroy_flow() functions
using this new infrastructure.
According to the commit 400dbc96583f, the purpose of this
infrastructure is to support passing around provider (eg. hardware)
specific buffers when userspace issue commands to the kernel, so that
it would be possible to extend uverbs (eg. core) buffers independently
from the provider buffers.
But the new kernel command function prototypes were not modified to
take advantage of this extension. This issue was exposed by Roland
Dreier in a previous review[1].
So the following patch is an attempt to a revised extensible command
infrastructure.
This improved extensible command infrastructure distinguish between
core (eg. legacy)'s command/response buffers from provider
(eg. hardware)'s command/response buffers: each extended command
implementing function is given a struct ib_udata to hold core
(eg. uverbs) input and output buffers, and another struct ib_udata to
hold the hw (eg. provider) input and output buffers.
Having those buffers identified separately make it easier to increase
one buffer to support extension without having to add some code to
guess the exact size of each command/response parts: This should make
the extended functions more reliable.
Additionally, instead of relying on command identifier being greater
than IB_USER_VERBS_CMD_THRESHOLD, the proposed infrastructure rely on
unused bits in command field: on the 32 bits provided by command
field, only 6 bits are really needed to encode the identifier of
commands currently supported by the kernel. (Even using only 6 bits
leaves room for about 23 new commands).
So this patch makes use of some high order bits in command field to
store flags, leaving enough room for more command identifiers than one
will ever need (eg. 256).
The new flags are used to specify if the command should be processed
as an extended one or a legacy one. While designing the new command
format, care was taken to make usage of flags itself extensible.
Using high order bits of the commands field ensure that newer
libibverbs on older kernel will properly fail when trying to call
extended commands. On the other hand, older libibverbs on newer kernel
will never be able to issue calls to extended commands.
The extended command header includes the optional response pointer so
that output buffer length and output buffer pointer are located
together in the command, allowing proper parameters checking. This
should make implementing functions easier and safer.
Additionally the extended header ensure 64bits alignment, while making
all sizes multiple of 8 bytes, extending the maximum buffer size:
legacy extended
Maximum command buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
Maximum response buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
For the purpose of doing proper buffer size accounting, the headers
size are no more taken in account in "in_words".
One of the odds of the current extensible infrastructure, reading
twice the "legacy" command header, is fixed by removing the "legacy"
command header from the extended command header: they are processed as
two different parts of the command: memory is read once and
information are not duplicated: it's making clear that's an extended
command scheme and not a different command scheme.
The proposed scheme will format input (command) and output (response)
buffers this way:
- command:
legacy header +
extended header +
command data (core + hw):
+----------------------------------------+
| flags | 00 00 | command |
| in_words | out_words |
+----------------------------------------+
| response |
| response |
| provider_in_words | provider_out_words |
| padding |
+----------------------------------------+
| |
. <uverbs input> .
. (in_words * 8) .
| |
+----------------------------------------+
| |
. <provider input> .
. (provider_in_words * 8) .
| |
+----------------------------------------+
- response, if present:
+----------------------------------------+
| |
. <uverbs output space> .
. (out_words * 8) .
| |
+----------------------------------------+
| |
. <provider output space> .
. (provider_out_words * 8) .
| |
+----------------------------------------+
The overall design is to ensure that the extensible infrastructure is
itself extensible while begin more reliable with more input and bound
checking.
Note:
The unused field in the extended header would be perfect candidate to
hold the command "comp_mask" (eg. bit field used to handle
compatibility). This was suggested by Roland Dreier in a previous
review[2]. But "comp_mask" field is likely to be present in the uverb
input and/or provider input, likewise for the response, as noted by
Matan Barak[3], so it doesn't make sense to put "comp_mask" in the
header.
[1]:
http://marc.info/?i=CAL1RGDWxmM17W2o_era24A-TTDeKyoL6u3NRu_=t_dhV_ZA9MA@mail.gmail.com
[2]:
http://marc.info/?i=CAL1RGDXJtrc849M6_XNZT5xO1+ybKtLWGq6yg6LhoSsKpsmkYA@mail.gmail.com
[3]:
http://marc.info/?i=525C1149.6000701@mellanox.com
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Link: http://marc.info/?i=cover.1383773832.git.ydroneaud@opteya.com
[ Convert "ret ? ret : 0" to the equivalent "ret". - Roland ]
Signed-off-by: Roland Dreier <roland@purestorage.com>
2013-11-07 02:21:49 +04:00
|
|
|
|
2015-08-13 18:32:05 +03:00
|
|
|
if (!(ib_dev->uverbs_ex_cmd_mask & (1ull << command))) {
|
|
|
|
ret = -ENOSYS;
|
|
|
|
goto out;
|
|
|
|
}
|
IB/core: extended command: an improved infrastructure for uverbs commands
Commit 400dbc96583f ("IB/core: Infrastructure for extensible uverbs
commands") added an infrastructure for extensible uverbs commands
while later commit 436f2ad05a0b ("IB/core: Export ib_create/destroy_flow
through uverbs") exported ib_create_flow()/ib_destroy_flow() functions
using this new infrastructure.
According to the commit 400dbc96583f, the purpose of this
infrastructure is to support passing around provider (eg. hardware)
specific buffers when userspace issue commands to the kernel, so that
it would be possible to extend uverbs (eg. core) buffers independently
from the provider buffers.
But the new kernel command function prototypes were not modified to
take advantage of this extension. This issue was exposed by Roland
Dreier in a previous review[1].
So the following patch is an attempt to a revised extensible command
infrastructure.
This improved extensible command infrastructure distinguish between
core (eg. legacy)'s command/response buffers from provider
(eg. hardware)'s command/response buffers: each extended command
implementing function is given a struct ib_udata to hold core
(eg. uverbs) input and output buffers, and another struct ib_udata to
hold the hw (eg. provider) input and output buffers.
Having those buffers identified separately make it easier to increase
one buffer to support extension without having to add some code to
guess the exact size of each command/response parts: This should make
the extended functions more reliable.
Additionally, instead of relying on command identifier being greater
than IB_USER_VERBS_CMD_THRESHOLD, the proposed infrastructure rely on
unused bits in command field: on the 32 bits provided by command
field, only 6 bits are really needed to encode the identifier of
commands currently supported by the kernel. (Even using only 6 bits
leaves room for about 23 new commands).
So this patch makes use of some high order bits in command field to
store flags, leaving enough room for more command identifiers than one
will ever need (eg. 256).
The new flags are used to specify if the command should be processed
as an extended one or a legacy one. While designing the new command
format, care was taken to make usage of flags itself extensible.
Using high order bits of the commands field ensure that newer
libibverbs on older kernel will properly fail when trying to call
extended commands. On the other hand, older libibverbs on newer kernel
will never be able to issue calls to extended commands.
The extended command header includes the optional response pointer so
that output buffer length and output buffer pointer are located
together in the command, allowing proper parameters checking. This
should make implementing functions easier and safer.
Additionally the extended header ensure 64bits alignment, while making
all sizes multiple of 8 bytes, extending the maximum buffer size:
legacy extended
Maximum command buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
Maximum response buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
For the purpose of doing proper buffer size accounting, the headers
size are no more taken in account in "in_words".
One of the odds of the current extensible infrastructure, reading
twice the "legacy" command header, is fixed by removing the "legacy"
command header from the extended command header: they are processed as
two different parts of the command: memory is read once and
information are not duplicated: it's making clear that's an extended
command scheme and not a different command scheme.
The proposed scheme will format input (command) and output (response)
buffers this way:
- command:
legacy header +
extended header +
command data (core + hw):
+----------------------------------------+
| flags | 00 00 | command |
| in_words | out_words |
+----------------------------------------+
| response |
| response |
| provider_in_words | provider_out_words |
| padding |
+----------------------------------------+
| |
. <uverbs input> .
. (in_words * 8) .
| |
+----------------------------------------+
| |
. <provider input> .
. (provider_in_words * 8) .
| |
+----------------------------------------+
- response, if present:
+----------------------------------------+
| |
. <uverbs output space> .
. (out_words * 8) .
| |
+----------------------------------------+
| |
. <provider output space> .
. (provider_out_words * 8) .
| |
+----------------------------------------+
The overall design is to ensure that the extensible infrastructure is
itself extensible while begin more reliable with more input and bound
checking.
Note:
The unused field in the extended header would be perfect candidate to
hold the command "comp_mask" (eg. bit field used to handle
compatibility). This was suggested by Roland Dreier in a previous
review[2]. But "comp_mask" field is likely to be present in the uverb
input and/or provider input, likewise for the response, as noted by
Matan Barak[3], so it doesn't make sense to put "comp_mask" in the
header.
[1]:
http://marc.info/?i=CAL1RGDWxmM17W2o_era24A-TTDeKyoL6u3NRu_=t_dhV_ZA9MA@mail.gmail.com
[2]:
http://marc.info/?i=CAL1RGDXJtrc849M6_XNZT5xO1+ybKtLWGq6yg6LhoSsKpsmkYA@mail.gmail.com
[3]:
http://marc.info/?i=525C1149.6000701@mellanox.com
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Link: http://marc.info/?i=cover.1383773832.git.ydroneaud@opteya.com
[ Convert "ret ? ret : 0" to the equivalent "ret". - Roland ]
Signed-off-by: Roland Dreier <roland@purestorage.com>
2013-11-07 02:21:49 +04:00
|
|
|
|
2015-08-13 18:32:05 +03:00
|
|
|
if (count < (sizeof(hdr) + sizeof(ex_hdr))) {
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
IB/core: extended command: an improved infrastructure for uverbs commands
Commit 400dbc96583f ("IB/core: Infrastructure for extensible uverbs
commands") added an infrastructure for extensible uverbs commands
while later commit 436f2ad05a0b ("IB/core: Export ib_create/destroy_flow
through uverbs") exported ib_create_flow()/ib_destroy_flow() functions
using this new infrastructure.
According to the commit 400dbc96583f, the purpose of this
infrastructure is to support passing around provider (eg. hardware)
specific buffers when userspace issue commands to the kernel, so that
it would be possible to extend uverbs (eg. core) buffers independently
from the provider buffers.
But the new kernel command function prototypes were not modified to
take advantage of this extension. This issue was exposed by Roland
Dreier in a previous review[1].
So the following patch is an attempt to a revised extensible command
infrastructure.
This improved extensible command infrastructure distinguish between
core (eg. legacy)'s command/response buffers from provider
(eg. hardware)'s command/response buffers: each extended command
implementing function is given a struct ib_udata to hold core
(eg. uverbs) input and output buffers, and another struct ib_udata to
hold the hw (eg. provider) input and output buffers.
Having those buffers identified separately make it easier to increase
one buffer to support extension without having to add some code to
guess the exact size of each command/response parts: This should make
the extended functions more reliable.
Additionally, instead of relying on command identifier being greater
than IB_USER_VERBS_CMD_THRESHOLD, the proposed infrastructure rely on
unused bits in command field: on the 32 bits provided by command
field, only 6 bits are really needed to encode the identifier of
commands currently supported by the kernel. (Even using only 6 bits
leaves room for about 23 new commands).
So this patch makes use of some high order bits in command field to
store flags, leaving enough room for more command identifiers than one
will ever need (eg. 256).
The new flags are used to specify if the command should be processed
as an extended one or a legacy one. While designing the new command
format, care was taken to make usage of flags itself extensible.
Using high order bits of the commands field ensure that newer
libibverbs on older kernel will properly fail when trying to call
extended commands. On the other hand, older libibverbs on newer kernel
will never be able to issue calls to extended commands.
The extended command header includes the optional response pointer so
that output buffer length and output buffer pointer are located
together in the command, allowing proper parameters checking. This
should make implementing functions easier and safer.
Additionally the extended header ensure 64bits alignment, while making
all sizes multiple of 8 bytes, extending the maximum buffer size:
legacy extended
Maximum command buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
Maximum response buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
For the purpose of doing proper buffer size accounting, the headers
size are no more taken in account in "in_words".
One of the odds of the current extensible infrastructure, reading
twice the "legacy" command header, is fixed by removing the "legacy"
command header from the extended command header: they are processed as
two different parts of the command: memory is read once and
information are not duplicated: it's making clear that's an extended
command scheme and not a different command scheme.
The proposed scheme will format input (command) and output (response)
buffers this way:
- command:
legacy header +
extended header +
command data (core + hw):
+----------------------------------------+
| flags | 00 00 | command |
| in_words | out_words |
+----------------------------------------+
| response |
| response |
| provider_in_words | provider_out_words |
| padding |
+----------------------------------------+
| |
. <uverbs input> .
. (in_words * 8) .
| |
+----------------------------------------+
| |
. <provider input> .
. (provider_in_words * 8) .
| |
+----------------------------------------+
- response, if present:
+----------------------------------------+
| |
. <uverbs output space> .
. (out_words * 8) .
| |
+----------------------------------------+
| |
. <provider output space> .
. (provider_out_words * 8) .
| |
+----------------------------------------+
The overall design is to ensure that the extensible infrastructure is
itself extensible while begin more reliable with more input and bound
checking.
Note:
The unused field in the extended header would be perfect candidate to
hold the command "comp_mask" (eg. bit field used to handle
compatibility). This was suggested by Roland Dreier in a previous
review[2]. But "comp_mask" field is likely to be present in the uverb
input and/or provider input, likewise for the response, as noted by
Matan Barak[3], so it doesn't make sense to put "comp_mask" in the
header.
[1]:
http://marc.info/?i=CAL1RGDWxmM17W2o_era24A-TTDeKyoL6u3NRu_=t_dhV_ZA9MA@mail.gmail.com
[2]:
http://marc.info/?i=CAL1RGDXJtrc849M6_XNZT5xO1+ybKtLWGq6yg6LhoSsKpsmkYA@mail.gmail.com
[3]:
http://marc.info/?i=525C1149.6000701@mellanox.com
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Link: http://marc.info/?i=cover.1383773832.git.ydroneaud@opteya.com
[ Convert "ret ? ret : 0" to the equivalent "ret". - Roland ]
Signed-off-by: Roland Dreier <roland@purestorage.com>
2013-11-07 02:21:49 +04:00
|
|
|
|
2015-08-13 18:32:05 +03:00
|
|
|
if (copy_from_user(&ex_hdr, buf + sizeof(hdr), sizeof(ex_hdr))) {
|
|
|
|
ret = -EFAULT;
|
|
|
|
goto out;
|
|
|
|
}
|
IB/core: extended command: an improved infrastructure for uverbs commands
Commit 400dbc96583f ("IB/core: Infrastructure for extensible uverbs
commands") added an infrastructure for extensible uverbs commands
while later commit 436f2ad05a0b ("IB/core: Export ib_create/destroy_flow
through uverbs") exported ib_create_flow()/ib_destroy_flow() functions
using this new infrastructure.
According to the commit 400dbc96583f, the purpose of this
infrastructure is to support passing around provider (eg. hardware)
specific buffers when userspace issue commands to the kernel, so that
it would be possible to extend uverbs (eg. core) buffers independently
from the provider buffers.
But the new kernel command function prototypes were not modified to
take advantage of this extension. This issue was exposed by Roland
Dreier in a previous review[1].
So the following patch is an attempt to a revised extensible command
infrastructure.
This improved extensible command infrastructure distinguish between
core (eg. legacy)'s command/response buffers from provider
(eg. hardware)'s command/response buffers: each extended command
implementing function is given a struct ib_udata to hold core
(eg. uverbs) input and output buffers, and another struct ib_udata to
hold the hw (eg. provider) input and output buffers.
Having those buffers identified separately make it easier to increase
one buffer to support extension without having to add some code to
guess the exact size of each command/response parts: This should make
the extended functions more reliable.
Additionally, instead of relying on command identifier being greater
than IB_USER_VERBS_CMD_THRESHOLD, the proposed infrastructure rely on
unused bits in command field: on the 32 bits provided by command
field, only 6 bits are really needed to encode the identifier of
commands currently supported by the kernel. (Even using only 6 bits
leaves room for about 23 new commands).
So this patch makes use of some high order bits in command field to
store flags, leaving enough room for more command identifiers than one
will ever need (eg. 256).
The new flags are used to specify if the command should be processed
as an extended one or a legacy one. While designing the new command
format, care was taken to make usage of flags itself extensible.
Using high order bits of the commands field ensure that newer
libibverbs on older kernel will properly fail when trying to call
extended commands. On the other hand, older libibverbs on newer kernel
will never be able to issue calls to extended commands.
The extended command header includes the optional response pointer so
that output buffer length and output buffer pointer are located
together in the command, allowing proper parameters checking. This
should make implementing functions easier and safer.
Additionally the extended header ensure 64bits alignment, while making
all sizes multiple of 8 bytes, extending the maximum buffer size:
legacy extended
Maximum command buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
Maximum response buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
For the purpose of doing proper buffer size accounting, the headers
size are no more taken in account in "in_words".
One of the odds of the current extensible infrastructure, reading
twice the "legacy" command header, is fixed by removing the "legacy"
command header from the extended command header: they are processed as
two different parts of the command: memory is read once and
information are not duplicated: it's making clear that's an extended
command scheme and not a different command scheme.
The proposed scheme will format input (command) and output (response)
buffers this way:
- command:
legacy header +
extended header +
command data (core + hw):
+----------------------------------------+
| flags | 00 00 | command |
| in_words | out_words |
+----------------------------------------+
| response |
| response |
| provider_in_words | provider_out_words |
| padding |
+----------------------------------------+
| |
. <uverbs input> .
. (in_words * 8) .
| |
+----------------------------------------+
| |
. <provider input> .
. (provider_in_words * 8) .
| |
+----------------------------------------+
- response, if present:
+----------------------------------------+
| |
. <uverbs output space> .
. (out_words * 8) .
| |
+----------------------------------------+
| |
. <provider output space> .
. (provider_out_words * 8) .
| |
+----------------------------------------+
The overall design is to ensure that the extensible infrastructure is
itself extensible while begin more reliable with more input and bound
checking.
Note:
The unused field in the extended header would be perfect candidate to
hold the command "comp_mask" (eg. bit field used to handle
compatibility). This was suggested by Roland Dreier in a previous
review[2]. But "comp_mask" field is likely to be present in the uverb
input and/or provider input, likewise for the response, as noted by
Matan Barak[3], so it doesn't make sense to put "comp_mask" in the
header.
[1]:
http://marc.info/?i=CAL1RGDWxmM17W2o_era24A-TTDeKyoL6u3NRu_=t_dhV_ZA9MA@mail.gmail.com
[2]:
http://marc.info/?i=CAL1RGDXJtrc849M6_XNZT5xO1+ybKtLWGq6yg6LhoSsKpsmkYA@mail.gmail.com
[3]:
http://marc.info/?i=525C1149.6000701@mellanox.com
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Link: http://marc.info/?i=cover.1383773832.git.ydroneaud@opteya.com
[ Convert "ret ? ret : 0" to the equivalent "ret". - Roland ]
Signed-off-by: Roland Dreier <roland@purestorage.com>
2013-11-07 02:21:49 +04:00
|
|
|
|
|
|
|
count -= sizeof(hdr) + sizeof(ex_hdr);
|
|
|
|
buf += sizeof(hdr) + sizeof(ex_hdr);
|
|
|
|
|
2015-08-13 18:32:05 +03:00
|
|
|
if ((hdr.in_words + ex_hdr.provider_in_words) * 8 != count) {
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
IB/core: extended command: an improved infrastructure for uverbs commands
Commit 400dbc96583f ("IB/core: Infrastructure for extensible uverbs
commands") added an infrastructure for extensible uverbs commands
while later commit 436f2ad05a0b ("IB/core: Export ib_create/destroy_flow
through uverbs") exported ib_create_flow()/ib_destroy_flow() functions
using this new infrastructure.
According to the commit 400dbc96583f, the purpose of this
infrastructure is to support passing around provider (eg. hardware)
specific buffers when userspace issue commands to the kernel, so that
it would be possible to extend uverbs (eg. core) buffers independently
from the provider buffers.
But the new kernel command function prototypes were not modified to
take advantage of this extension. This issue was exposed by Roland
Dreier in a previous review[1].
So the following patch is an attempt to a revised extensible command
infrastructure.
This improved extensible command infrastructure distinguish between
core (eg. legacy)'s command/response buffers from provider
(eg. hardware)'s command/response buffers: each extended command
implementing function is given a struct ib_udata to hold core
(eg. uverbs) input and output buffers, and another struct ib_udata to
hold the hw (eg. provider) input and output buffers.
Having those buffers identified separately make it easier to increase
one buffer to support extension without having to add some code to
guess the exact size of each command/response parts: This should make
the extended functions more reliable.
Additionally, instead of relying on command identifier being greater
than IB_USER_VERBS_CMD_THRESHOLD, the proposed infrastructure rely on
unused bits in command field: on the 32 bits provided by command
field, only 6 bits are really needed to encode the identifier of
commands currently supported by the kernel. (Even using only 6 bits
leaves room for about 23 new commands).
So this patch makes use of some high order bits in command field to
store flags, leaving enough room for more command identifiers than one
will ever need (eg. 256).
The new flags are used to specify if the command should be processed
as an extended one or a legacy one. While designing the new command
format, care was taken to make usage of flags itself extensible.
Using high order bits of the commands field ensure that newer
libibverbs on older kernel will properly fail when trying to call
extended commands. On the other hand, older libibverbs on newer kernel
will never be able to issue calls to extended commands.
The extended command header includes the optional response pointer so
that output buffer length and output buffer pointer are located
together in the command, allowing proper parameters checking. This
should make implementing functions easier and safer.
Additionally the extended header ensure 64bits alignment, while making
all sizes multiple of 8 bytes, extending the maximum buffer size:
legacy extended
Maximum command buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
Maximum response buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
For the purpose of doing proper buffer size accounting, the headers
size are no more taken in account in "in_words".
One of the odds of the current extensible infrastructure, reading
twice the "legacy" command header, is fixed by removing the "legacy"
command header from the extended command header: they are processed as
two different parts of the command: memory is read once and
information are not duplicated: it's making clear that's an extended
command scheme and not a different command scheme.
The proposed scheme will format input (command) and output (response)
buffers this way:
- command:
legacy header +
extended header +
command data (core + hw):
+----------------------------------------+
| flags | 00 00 | command |
| in_words | out_words |
+----------------------------------------+
| response |
| response |
| provider_in_words | provider_out_words |
| padding |
+----------------------------------------+
| |
. <uverbs input> .
. (in_words * 8) .
| |
+----------------------------------------+
| |
. <provider input> .
. (provider_in_words * 8) .
| |
+----------------------------------------+
- response, if present:
+----------------------------------------+
| |
. <uverbs output space> .
. (out_words * 8) .
| |
+----------------------------------------+
| |
. <provider output space> .
. (provider_out_words * 8) .
| |
+----------------------------------------+
The overall design is to ensure that the extensible infrastructure is
itself extensible while begin more reliable with more input and bound
checking.
Note:
The unused field in the extended header would be perfect candidate to
hold the command "comp_mask" (eg. bit field used to handle
compatibility). This was suggested by Roland Dreier in a previous
review[2]. But "comp_mask" field is likely to be present in the uverb
input and/or provider input, likewise for the response, as noted by
Matan Barak[3], so it doesn't make sense to put "comp_mask" in the
header.
[1]:
http://marc.info/?i=CAL1RGDWxmM17W2o_era24A-TTDeKyoL6u3NRu_=t_dhV_ZA9MA@mail.gmail.com
[2]:
http://marc.info/?i=CAL1RGDXJtrc849M6_XNZT5xO1+ybKtLWGq6yg6LhoSsKpsmkYA@mail.gmail.com
[3]:
http://marc.info/?i=525C1149.6000701@mellanox.com
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Link: http://marc.info/?i=cover.1383773832.git.ydroneaud@opteya.com
[ Convert "ret ? ret : 0" to the equivalent "ret". - Roland ]
Signed-off-by: Roland Dreier <roland@purestorage.com>
2013-11-07 02:21:49 +04:00
|
|
|
|
2015-08-13 18:32:05 +03:00
|
|
|
if (ex_hdr.cmd_hdr_reserved) {
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
2013-12-12 02:01:47 +04:00
|
|
|
|
IB/core: extended command: an improved infrastructure for uverbs commands
Commit 400dbc96583f ("IB/core: Infrastructure for extensible uverbs
commands") added an infrastructure for extensible uverbs commands
while later commit 436f2ad05a0b ("IB/core: Export ib_create/destroy_flow
through uverbs") exported ib_create_flow()/ib_destroy_flow() functions
using this new infrastructure.
According to the commit 400dbc96583f, the purpose of this
infrastructure is to support passing around provider (eg. hardware)
specific buffers when userspace issue commands to the kernel, so that
it would be possible to extend uverbs (eg. core) buffers independently
from the provider buffers.
But the new kernel command function prototypes were not modified to
take advantage of this extension. This issue was exposed by Roland
Dreier in a previous review[1].
So the following patch is an attempt to a revised extensible command
infrastructure.
This improved extensible command infrastructure distinguish between
core (eg. legacy)'s command/response buffers from provider
(eg. hardware)'s command/response buffers: each extended command
implementing function is given a struct ib_udata to hold core
(eg. uverbs) input and output buffers, and another struct ib_udata to
hold the hw (eg. provider) input and output buffers.
Having those buffers identified separately make it easier to increase
one buffer to support extension without having to add some code to
guess the exact size of each command/response parts: This should make
the extended functions more reliable.
Additionally, instead of relying on command identifier being greater
than IB_USER_VERBS_CMD_THRESHOLD, the proposed infrastructure rely on
unused bits in command field: on the 32 bits provided by command
field, only 6 bits are really needed to encode the identifier of
commands currently supported by the kernel. (Even using only 6 bits
leaves room for about 23 new commands).
So this patch makes use of some high order bits in command field to
store flags, leaving enough room for more command identifiers than one
will ever need (eg. 256).
The new flags are used to specify if the command should be processed
as an extended one or a legacy one. While designing the new command
format, care was taken to make usage of flags itself extensible.
Using high order bits of the commands field ensure that newer
libibverbs on older kernel will properly fail when trying to call
extended commands. On the other hand, older libibverbs on newer kernel
will never be able to issue calls to extended commands.
The extended command header includes the optional response pointer so
that output buffer length and output buffer pointer are located
together in the command, allowing proper parameters checking. This
should make implementing functions easier and safer.
Additionally the extended header ensure 64bits alignment, while making
all sizes multiple of 8 bytes, extending the maximum buffer size:
legacy extended
Maximum command buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
Maximum response buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
For the purpose of doing proper buffer size accounting, the headers
size are no more taken in account in "in_words".
One of the odds of the current extensible infrastructure, reading
twice the "legacy" command header, is fixed by removing the "legacy"
command header from the extended command header: they are processed as
two different parts of the command: memory is read once and
information are not duplicated: it's making clear that's an extended
command scheme and not a different command scheme.
The proposed scheme will format input (command) and output (response)
buffers this way:
- command:
legacy header +
extended header +
command data (core + hw):
+----------------------------------------+
| flags | 00 00 | command |
| in_words | out_words |
+----------------------------------------+
| response |
| response |
| provider_in_words | provider_out_words |
| padding |
+----------------------------------------+
| |
. <uverbs input> .
. (in_words * 8) .
| |
+----------------------------------------+
| |
. <provider input> .
. (provider_in_words * 8) .
| |
+----------------------------------------+
- response, if present:
+----------------------------------------+
| |
. <uverbs output space> .
. (out_words * 8) .
| |
+----------------------------------------+
| |
. <provider output space> .
. (provider_out_words * 8) .
| |
+----------------------------------------+
The overall design is to ensure that the extensible infrastructure is
itself extensible while begin more reliable with more input and bound
checking.
Note:
The unused field in the extended header would be perfect candidate to
hold the command "comp_mask" (eg. bit field used to handle
compatibility). This was suggested by Roland Dreier in a previous
review[2]. But "comp_mask" field is likely to be present in the uverb
input and/or provider input, likewise for the response, as noted by
Matan Barak[3], so it doesn't make sense to put "comp_mask" in the
header.
[1]:
http://marc.info/?i=CAL1RGDWxmM17W2o_era24A-TTDeKyoL6u3NRu_=t_dhV_ZA9MA@mail.gmail.com
[2]:
http://marc.info/?i=CAL1RGDXJtrc849M6_XNZT5xO1+ybKtLWGq6yg6LhoSsKpsmkYA@mail.gmail.com
[3]:
http://marc.info/?i=525C1149.6000701@mellanox.com
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Link: http://marc.info/?i=cover.1383773832.git.ydroneaud@opteya.com
[ Convert "ret ? ret : 0" to the equivalent "ret". - Roland ]
Signed-off-by: Roland Dreier <roland@purestorage.com>
2013-11-07 02:21:49 +04:00
|
|
|
if (ex_hdr.response) {
|
2015-08-13 18:32:05 +03:00
|
|
|
if (!hdr.out_words && !ex_hdr.provider_out_words) {
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
2013-12-12 02:01:51 +04:00
|
|
|
|
|
|
|
if (!access_ok(VERIFY_WRITE,
|
|
|
|
(void __user *) (unsigned long) ex_hdr.response,
|
2015-08-13 18:32:05 +03:00
|
|
|
(hdr.out_words + ex_hdr.provider_out_words) * 8)) {
|
|
|
|
ret = -EFAULT;
|
|
|
|
goto out;
|
|
|
|
}
|
IB/core: extended command: an improved infrastructure for uverbs commands
Commit 400dbc96583f ("IB/core: Infrastructure for extensible uverbs
commands") added an infrastructure for extensible uverbs commands
while later commit 436f2ad05a0b ("IB/core: Export ib_create/destroy_flow
through uverbs") exported ib_create_flow()/ib_destroy_flow() functions
using this new infrastructure.
According to the commit 400dbc96583f, the purpose of this
infrastructure is to support passing around provider (eg. hardware)
specific buffers when userspace issue commands to the kernel, so that
it would be possible to extend uverbs (eg. core) buffers independently
from the provider buffers.
But the new kernel command function prototypes were not modified to
take advantage of this extension. This issue was exposed by Roland
Dreier in a previous review[1].
So the following patch is an attempt to a revised extensible command
infrastructure.
This improved extensible command infrastructure distinguish between
core (eg. legacy)'s command/response buffers from provider
(eg. hardware)'s command/response buffers: each extended command
implementing function is given a struct ib_udata to hold core
(eg. uverbs) input and output buffers, and another struct ib_udata to
hold the hw (eg. provider) input and output buffers.
Having those buffers identified separately make it easier to increase
one buffer to support extension without having to add some code to
guess the exact size of each command/response parts: This should make
the extended functions more reliable.
Additionally, instead of relying on command identifier being greater
than IB_USER_VERBS_CMD_THRESHOLD, the proposed infrastructure rely on
unused bits in command field: on the 32 bits provided by command
field, only 6 bits are really needed to encode the identifier of
commands currently supported by the kernel. (Even using only 6 bits
leaves room for about 23 new commands).
So this patch makes use of some high order bits in command field to
store flags, leaving enough room for more command identifiers than one
will ever need (eg. 256).
The new flags are used to specify if the command should be processed
as an extended one or a legacy one. While designing the new command
format, care was taken to make usage of flags itself extensible.
Using high order bits of the commands field ensure that newer
libibverbs on older kernel will properly fail when trying to call
extended commands. On the other hand, older libibverbs on newer kernel
will never be able to issue calls to extended commands.
The extended command header includes the optional response pointer so
that output buffer length and output buffer pointer are located
together in the command, allowing proper parameters checking. This
should make implementing functions easier and safer.
Additionally the extended header ensure 64bits alignment, while making
all sizes multiple of 8 bytes, extending the maximum buffer size:
legacy extended
Maximum command buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
Maximum response buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
For the purpose of doing proper buffer size accounting, the headers
size are no more taken in account in "in_words".
One of the odds of the current extensible infrastructure, reading
twice the "legacy" command header, is fixed by removing the "legacy"
command header from the extended command header: they are processed as
two different parts of the command: memory is read once and
information are not duplicated: it's making clear that's an extended
command scheme and not a different command scheme.
The proposed scheme will format input (command) and output (response)
buffers this way:
- command:
legacy header +
extended header +
command data (core + hw):
+----------------------------------------+
| flags | 00 00 | command |
| in_words | out_words |
+----------------------------------------+
| response |
| response |
| provider_in_words | provider_out_words |
| padding |
+----------------------------------------+
| |
. <uverbs input> .
. (in_words * 8) .
| |
+----------------------------------------+
| |
. <provider input> .
. (provider_in_words * 8) .
| |
+----------------------------------------+
- response, if present:
+----------------------------------------+
| |
. <uverbs output space> .
. (out_words * 8) .
| |
+----------------------------------------+
| |
. <provider output space> .
. (provider_out_words * 8) .
| |
+----------------------------------------+
The overall design is to ensure that the extensible infrastructure is
itself extensible while begin more reliable with more input and bound
checking.
Note:
The unused field in the extended header would be perfect candidate to
hold the command "comp_mask" (eg. bit field used to handle
compatibility). This was suggested by Roland Dreier in a previous
review[2]. But "comp_mask" field is likely to be present in the uverb
input and/or provider input, likewise for the response, as noted by
Matan Barak[3], so it doesn't make sense to put "comp_mask" in the
header.
[1]:
http://marc.info/?i=CAL1RGDWxmM17W2o_era24A-TTDeKyoL6u3NRu_=t_dhV_ZA9MA@mail.gmail.com
[2]:
http://marc.info/?i=CAL1RGDXJtrc849M6_XNZT5xO1+ybKtLWGq6yg6LhoSsKpsmkYA@mail.gmail.com
[3]:
http://marc.info/?i=525C1149.6000701@mellanox.com
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Link: http://marc.info/?i=cover.1383773832.git.ydroneaud@opteya.com
[ Convert "ret ? ret : 0" to the equivalent "ret". - Roland ]
Signed-off-by: Roland Dreier <roland@purestorage.com>
2013-11-07 02:21:49 +04:00
|
|
|
} else {
|
2015-08-13 18:32:05 +03:00
|
|
|
if (hdr.out_words || ex_hdr.provider_out_words) {
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
IB/core: extended command: an improved infrastructure for uverbs commands
Commit 400dbc96583f ("IB/core: Infrastructure for extensible uverbs
commands") added an infrastructure for extensible uverbs commands
while later commit 436f2ad05a0b ("IB/core: Export ib_create/destroy_flow
through uverbs") exported ib_create_flow()/ib_destroy_flow() functions
using this new infrastructure.
According to the commit 400dbc96583f, the purpose of this
infrastructure is to support passing around provider (eg. hardware)
specific buffers when userspace issue commands to the kernel, so that
it would be possible to extend uverbs (eg. core) buffers independently
from the provider buffers.
But the new kernel command function prototypes were not modified to
take advantage of this extension. This issue was exposed by Roland
Dreier in a previous review[1].
So the following patch is an attempt to a revised extensible command
infrastructure.
This improved extensible command infrastructure distinguish between
core (eg. legacy)'s command/response buffers from provider
(eg. hardware)'s command/response buffers: each extended command
implementing function is given a struct ib_udata to hold core
(eg. uverbs) input and output buffers, and another struct ib_udata to
hold the hw (eg. provider) input and output buffers.
Having those buffers identified separately make it easier to increase
one buffer to support extension without having to add some code to
guess the exact size of each command/response parts: This should make
the extended functions more reliable.
Additionally, instead of relying on command identifier being greater
than IB_USER_VERBS_CMD_THRESHOLD, the proposed infrastructure rely on
unused bits in command field: on the 32 bits provided by command
field, only 6 bits are really needed to encode the identifier of
commands currently supported by the kernel. (Even using only 6 bits
leaves room for about 23 new commands).
So this patch makes use of some high order bits in command field to
store flags, leaving enough room for more command identifiers than one
will ever need (eg. 256).
The new flags are used to specify if the command should be processed
as an extended one or a legacy one. While designing the new command
format, care was taken to make usage of flags itself extensible.
Using high order bits of the commands field ensure that newer
libibverbs on older kernel will properly fail when trying to call
extended commands. On the other hand, older libibverbs on newer kernel
will never be able to issue calls to extended commands.
The extended command header includes the optional response pointer so
that output buffer length and output buffer pointer are located
together in the command, allowing proper parameters checking. This
should make implementing functions easier and safer.
Additionally the extended header ensure 64bits alignment, while making
all sizes multiple of 8 bytes, extending the maximum buffer size:
legacy extended
Maximum command buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
Maximum response buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
For the purpose of doing proper buffer size accounting, the headers
size are no more taken in account in "in_words".
One of the odds of the current extensible infrastructure, reading
twice the "legacy" command header, is fixed by removing the "legacy"
command header from the extended command header: they are processed as
two different parts of the command: memory is read once and
information are not duplicated: it's making clear that's an extended
command scheme and not a different command scheme.
The proposed scheme will format input (command) and output (response)
buffers this way:
- command:
legacy header +
extended header +
command data (core + hw):
+----------------------------------------+
| flags | 00 00 | command |
| in_words | out_words |
+----------------------------------------+
| response |
| response |
| provider_in_words | provider_out_words |
| padding |
+----------------------------------------+
| |
. <uverbs input> .
. (in_words * 8) .
| |
+----------------------------------------+
| |
. <provider input> .
. (provider_in_words * 8) .
| |
+----------------------------------------+
- response, if present:
+----------------------------------------+
| |
. <uverbs output space> .
. (out_words * 8) .
| |
+----------------------------------------+
| |
. <provider output space> .
. (provider_out_words * 8) .
| |
+----------------------------------------+
The overall design is to ensure that the extensible infrastructure is
itself extensible while begin more reliable with more input and bound
checking.
Note:
The unused field in the extended header would be perfect candidate to
hold the command "comp_mask" (eg. bit field used to handle
compatibility). This was suggested by Roland Dreier in a previous
review[2]. But "comp_mask" field is likely to be present in the uverb
input and/or provider input, likewise for the response, as noted by
Matan Barak[3], so it doesn't make sense to put "comp_mask" in the
header.
[1]:
http://marc.info/?i=CAL1RGDWxmM17W2o_era24A-TTDeKyoL6u3NRu_=t_dhV_ZA9MA@mail.gmail.com
[2]:
http://marc.info/?i=CAL1RGDXJtrc849M6_XNZT5xO1+ybKtLWGq6yg6LhoSsKpsmkYA@mail.gmail.com
[3]:
http://marc.info/?i=525C1149.6000701@mellanox.com
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Link: http://marc.info/?i=cover.1383773832.git.ydroneaud@opteya.com
[ Convert "ret ? ret : 0" to the equivalent "ret". - Roland ]
Signed-off-by: Roland Dreier <roland@purestorage.com>
2013-11-07 02:21:49 +04:00
|
|
|
}
|
|
|
|
|
2013-12-19 20:37:03 +04:00
|
|
|
INIT_UDATA_BUF_OR_NULL(&ucore, buf, (unsigned long) ex_hdr.response,
|
|
|
|
hdr.in_words * 8, hdr.out_words * 8);
|
|
|
|
|
|
|
|
INIT_UDATA_BUF_OR_NULL(&uhw,
|
|
|
|
buf + ucore.inlen,
|
|
|
|
(unsigned long) ex_hdr.response + ucore.outlen,
|
|
|
|
ex_hdr.provider_in_words * 8,
|
|
|
|
ex_hdr.provider_out_words * 8);
|
IB/core: extended command: an improved infrastructure for uverbs commands
Commit 400dbc96583f ("IB/core: Infrastructure for extensible uverbs
commands") added an infrastructure for extensible uverbs commands
while later commit 436f2ad05a0b ("IB/core: Export ib_create/destroy_flow
through uverbs") exported ib_create_flow()/ib_destroy_flow() functions
using this new infrastructure.
According to the commit 400dbc96583f, the purpose of this
infrastructure is to support passing around provider (eg. hardware)
specific buffers when userspace issue commands to the kernel, so that
it would be possible to extend uverbs (eg. core) buffers independently
from the provider buffers.
But the new kernel command function prototypes were not modified to
take advantage of this extension. This issue was exposed by Roland
Dreier in a previous review[1].
So the following patch is an attempt to a revised extensible command
infrastructure.
This improved extensible command infrastructure distinguish between
core (eg. legacy)'s command/response buffers from provider
(eg. hardware)'s command/response buffers: each extended command
implementing function is given a struct ib_udata to hold core
(eg. uverbs) input and output buffers, and another struct ib_udata to
hold the hw (eg. provider) input and output buffers.
Having those buffers identified separately make it easier to increase
one buffer to support extension without having to add some code to
guess the exact size of each command/response parts: This should make
the extended functions more reliable.
Additionally, instead of relying on command identifier being greater
than IB_USER_VERBS_CMD_THRESHOLD, the proposed infrastructure rely on
unused bits in command field: on the 32 bits provided by command
field, only 6 bits are really needed to encode the identifier of
commands currently supported by the kernel. (Even using only 6 bits
leaves room for about 23 new commands).
So this patch makes use of some high order bits in command field to
store flags, leaving enough room for more command identifiers than one
will ever need (eg. 256).
The new flags are used to specify if the command should be processed
as an extended one or a legacy one. While designing the new command
format, care was taken to make usage of flags itself extensible.
Using high order bits of the commands field ensure that newer
libibverbs on older kernel will properly fail when trying to call
extended commands. On the other hand, older libibverbs on newer kernel
will never be able to issue calls to extended commands.
The extended command header includes the optional response pointer so
that output buffer length and output buffer pointer are located
together in the command, allowing proper parameters checking. This
should make implementing functions easier and safer.
Additionally the extended header ensure 64bits alignment, while making
all sizes multiple of 8 bytes, extending the maximum buffer size:
legacy extended
Maximum command buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
Maximum response buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
For the purpose of doing proper buffer size accounting, the headers
size are no more taken in account in "in_words".
One of the odds of the current extensible infrastructure, reading
twice the "legacy" command header, is fixed by removing the "legacy"
command header from the extended command header: they are processed as
two different parts of the command: memory is read once and
information are not duplicated: it's making clear that's an extended
command scheme and not a different command scheme.
The proposed scheme will format input (command) and output (response)
buffers this way:
- command:
legacy header +
extended header +
command data (core + hw):
+----------------------------------------+
| flags | 00 00 | command |
| in_words | out_words |
+----------------------------------------+
| response |
| response |
| provider_in_words | provider_out_words |
| padding |
+----------------------------------------+
| |
. <uverbs input> .
. (in_words * 8) .
| |
+----------------------------------------+
| |
. <provider input> .
. (provider_in_words * 8) .
| |
+----------------------------------------+
- response, if present:
+----------------------------------------+
| |
. <uverbs output space> .
. (out_words * 8) .
| |
+----------------------------------------+
| |
. <provider output space> .
. (provider_out_words * 8) .
| |
+----------------------------------------+
The overall design is to ensure that the extensible infrastructure is
itself extensible while begin more reliable with more input and bound
checking.
Note:
The unused field in the extended header would be perfect candidate to
hold the command "comp_mask" (eg. bit field used to handle
compatibility). This was suggested by Roland Dreier in a previous
review[2]. But "comp_mask" field is likely to be present in the uverb
input and/or provider input, likewise for the response, as noted by
Matan Barak[3], so it doesn't make sense to put "comp_mask" in the
header.
[1]:
http://marc.info/?i=CAL1RGDWxmM17W2o_era24A-TTDeKyoL6u3NRu_=t_dhV_ZA9MA@mail.gmail.com
[2]:
http://marc.info/?i=CAL1RGDXJtrc849M6_XNZT5xO1+ybKtLWGq6yg6LhoSsKpsmkYA@mail.gmail.com
[3]:
http://marc.info/?i=525C1149.6000701@mellanox.com
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Link: http://marc.info/?i=cover.1383773832.git.ydroneaud@opteya.com
[ Convert "ret ? ret : 0" to the equivalent "ret". - Roland ]
Signed-off-by: Roland Dreier <roland@purestorage.com>
2013-11-07 02:21:49 +04:00
|
|
|
|
2015-08-13 18:32:05 +03:00
|
|
|
ret = uverbs_ex_cmd_table[command](file,
|
2015-08-13 18:32:04 +03:00
|
|
|
ib_dev,
|
IB/core: extended command: an improved infrastructure for uverbs commands
Commit 400dbc96583f ("IB/core: Infrastructure for extensible uverbs
commands") added an infrastructure for extensible uverbs commands
while later commit 436f2ad05a0b ("IB/core: Export ib_create/destroy_flow
through uverbs") exported ib_create_flow()/ib_destroy_flow() functions
using this new infrastructure.
According to the commit 400dbc96583f, the purpose of this
infrastructure is to support passing around provider (eg. hardware)
specific buffers when userspace issue commands to the kernel, so that
it would be possible to extend uverbs (eg. core) buffers independently
from the provider buffers.
But the new kernel command function prototypes were not modified to
take advantage of this extension. This issue was exposed by Roland
Dreier in a previous review[1].
So the following patch is an attempt to a revised extensible command
infrastructure.
This improved extensible command infrastructure distinguish between
core (eg. legacy)'s command/response buffers from provider
(eg. hardware)'s command/response buffers: each extended command
implementing function is given a struct ib_udata to hold core
(eg. uverbs) input and output buffers, and another struct ib_udata to
hold the hw (eg. provider) input and output buffers.
Having those buffers identified separately make it easier to increase
one buffer to support extension without having to add some code to
guess the exact size of each command/response parts: This should make
the extended functions more reliable.
Additionally, instead of relying on command identifier being greater
than IB_USER_VERBS_CMD_THRESHOLD, the proposed infrastructure rely on
unused bits in command field: on the 32 bits provided by command
field, only 6 bits are really needed to encode the identifier of
commands currently supported by the kernel. (Even using only 6 bits
leaves room for about 23 new commands).
So this patch makes use of some high order bits in command field to
store flags, leaving enough room for more command identifiers than one
will ever need (eg. 256).
The new flags are used to specify if the command should be processed
as an extended one or a legacy one. While designing the new command
format, care was taken to make usage of flags itself extensible.
Using high order bits of the commands field ensure that newer
libibverbs on older kernel will properly fail when trying to call
extended commands. On the other hand, older libibverbs on newer kernel
will never be able to issue calls to extended commands.
The extended command header includes the optional response pointer so
that output buffer length and output buffer pointer are located
together in the command, allowing proper parameters checking. This
should make implementing functions easier and safer.
Additionally the extended header ensure 64bits alignment, while making
all sizes multiple of 8 bytes, extending the maximum buffer size:
legacy extended
Maximum command buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
Maximum response buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
For the purpose of doing proper buffer size accounting, the headers
size are no more taken in account in "in_words".
One of the odds of the current extensible infrastructure, reading
twice the "legacy" command header, is fixed by removing the "legacy"
command header from the extended command header: they are processed as
two different parts of the command: memory is read once and
information are not duplicated: it's making clear that's an extended
command scheme and not a different command scheme.
The proposed scheme will format input (command) and output (response)
buffers this way:
- command:
legacy header +
extended header +
command data (core + hw):
+----------------------------------------+
| flags | 00 00 | command |
| in_words | out_words |
+----------------------------------------+
| response |
| response |
| provider_in_words | provider_out_words |
| padding |
+----------------------------------------+
| |
. <uverbs input> .
. (in_words * 8) .
| |
+----------------------------------------+
| |
. <provider input> .
. (provider_in_words * 8) .
| |
+----------------------------------------+
- response, if present:
+----------------------------------------+
| |
. <uverbs output space> .
. (out_words * 8) .
| |
+----------------------------------------+
| |
. <provider output space> .
. (provider_out_words * 8) .
| |
+----------------------------------------+
The overall design is to ensure that the extensible infrastructure is
itself extensible while begin more reliable with more input and bound
checking.
Note:
The unused field in the extended header would be perfect candidate to
hold the command "comp_mask" (eg. bit field used to handle
compatibility). This was suggested by Roland Dreier in a previous
review[2]. But "comp_mask" field is likely to be present in the uverb
input and/or provider input, likewise for the response, as noted by
Matan Barak[3], so it doesn't make sense to put "comp_mask" in the
header.
[1]:
http://marc.info/?i=CAL1RGDWxmM17W2o_era24A-TTDeKyoL6u3NRu_=t_dhV_ZA9MA@mail.gmail.com
[2]:
http://marc.info/?i=CAL1RGDXJtrc849M6_XNZT5xO1+ybKtLWGq6yg6LhoSsKpsmkYA@mail.gmail.com
[3]:
http://marc.info/?i=525C1149.6000701@mellanox.com
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Link: http://marc.info/?i=cover.1383773832.git.ydroneaud@opteya.com
[ Convert "ret ? ret : 0" to the equivalent "ret". - Roland ]
Signed-off-by: Roland Dreier <roland@purestorage.com>
2013-11-07 02:21:49 +04:00
|
|
|
&ucore,
|
|
|
|
&uhw);
|
2015-08-13 18:32:05 +03:00
|
|
|
if (!ret)
|
|
|
|
ret = written_count;
|
|
|
|
} else {
|
|
|
|
ret = -ENOSYS;
|
2013-08-14 14:58:29 +04:00
|
|
|
}
|
IB/core: extended command: an improved infrastructure for uverbs commands
Commit 400dbc96583f ("IB/core: Infrastructure for extensible uverbs
commands") added an infrastructure for extensible uverbs commands
while later commit 436f2ad05a0b ("IB/core: Export ib_create/destroy_flow
through uverbs") exported ib_create_flow()/ib_destroy_flow() functions
using this new infrastructure.
According to the commit 400dbc96583f, the purpose of this
infrastructure is to support passing around provider (eg. hardware)
specific buffers when userspace issue commands to the kernel, so that
it would be possible to extend uverbs (eg. core) buffers independently
from the provider buffers.
But the new kernel command function prototypes were not modified to
take advantage of this extension. This issue was exposed by Roland
Dreier in a previous review[1].
So the following patch is an attempt to a revised extensible command
infrastructure.
This improved extensible command infrastructure distinguish between
core (eg. legacy)'s command/response buffers from provider
(eg. hardware)'s command/response buffers: each extended command
implementing function is given a struct ib_udata to hold core
(eg. uverbs) input and output buffers, and another struct ib_udata to
hold the hw (eg. provider) input and output buffers.
Having those buffers identified separately make it easier to increase
one buffer to support extension without having to add some code to
guess the exact size of each command/response parts: This should make
the extended functions more reliable.
Additionally, instead of relying on command identifier being greater
than IB_USER_VERBS_CMD_THRESHOLD, the proposed infrastructure rely on
unused bits in command field: on the 32 bits provided by command
field, only 6 bits are really needed to encode the identifier of
commands currently supported by the kernel. (Even using only 6 bits
leaves room for about 23 new commands).
So this patch makes use of some high order bits in command field to
store flags, leaving enough room for more command identifiers than one
will ever need (eg. 256).
The new flags are used to specify if the command should be processed
as an extended one or a legacy one. While designing the new command
format, care was taken to make usage of flags itself extensible.
Using high order bits of the commands field ensure that newer
libibverbs on older kernel will properly fail when trying to call
extended commands. On the other hand, older libibverbs on newer kernel
will never be able to issue calls to extended commands.
The extended command header includes the optional response pointer so
that output buffer length and output buffer pointer are located
together in the command, allowing proper parameters checking. This
should make implementing functions easier and safer.
Additionally the extended header ensure 64bits alignment, while making
all sizes multiple of 8 bytes, extending the maximum buffer size:
legacy extended
Maximum command buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
Maximum response buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
For the purpose of doing proper buffer size accounting, the headers
size are no more taken in account in "in_words".
One of the odds of the current extensible infrastructure, reading
twice the "legacy" command header, is fixed by removing the "legacy"
command header from the extended command header: they are processed as
two different parts of the command: memory is read once and
information are not duplicated: it's making clear that's an extended
command scheme and not a different command scheme.
The proposed scheme will format input (command) and output (response)
buffers this way:
- command:
legacy header +
extended header +
command data (core + hw):
+----------------------------------------+
| flags | 00 00 | command |
| in_words | out_words |
+----------------------------------------+
| response |
| response |
| provider_in_words | provider_out_words |
| padding |
+----------------------------------------+
| |
. <uverbs input> .
. (in_words * 8) .
| |
+----------------------------------------+
| |
. <provider input> .
. (provider_in_words * 8) .
| |
+----------------------------------------+
- response, if present:
+----------------------------------------+
| |
. <uverbs output space> .
. (out_words * 8) .
| |
+----------------------------------------+
| |
. <provider output space> .
. (provider_out_words * 8) .
| |
+----------------------------------------+
The overall design is to ensure that the extensible infrastructure is
itself extensible while begin more reliable with more input and bound
checking.
Note:
The unused field in the extended header would be perfect candidate to
hold the command "comp_mask" (eg. bit field used to handle
compatibility). This was suggested by Roland Dreier in a previous
review[2]. But "comp_mask" field is likely to be present in the uverb
input and/or provider input, likewise for the response, as noted by
Matan Barak[3], so it doesn't make sense to put "comp_mask" in the
header.
[1]:
http://marc.info/?i=CAL1RGDWxmM17W2o_era24A-TTDeKyoL6u3NRu_=t_dhV_ZA9MA@mail.gmail.com
[2]:
http://marc.info/?i=CAL1RGDXJtrc849M6_XNZT5xO1+ybKtLWGq6yg6LhoSsKpsmkYA@mail.gmail.com
[3]:
http://marc.info/?i=525C1149.6000701@mellanox.com
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Link: http://marc.info/?i=cover.1383773832.git.ydroneaud@opteya.com
[ Convert "ret ? ret : 0" to the equivalent "ret". - Roland ]
Signed-off-by: Roland Dreier <roland@purestorage.com>
2013-11-07 02:21:49 +04:00
|
|
|
|
2015-08-13 18:32:05 +03:00
|
|
|
out:
|
|
|
|
srcu_read_unlock(&file->device->disassociate_srcu, srcu_key);
|
|
|
|
return ret;
|
2005-07-08 04:57:13 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
static int ib_uverbs_mmap(struct file *filp, struct vm_area_struct *vma)
|
|
|
|
{
|
|
|
|
struct ib_uverbs_file *file = filp->private_data;
|
2015-08-13 18:32:05 +03:00
|
|
|
struct ib_device *ib_dev;
|
|
|
|
int ret = 0;
|
|
|
|
int srcu_key;
|
2005-07-08 04:57:13 +04:00
|
|
|
|
2015-08-13 18:32:05 +03:00
|
|
|
srcu_key = srcu_read_lock(&file->device->disassociate_srcu);
|
|
|
|
ib_dev = srcu_dereference(file->device->ib_dev,
|
|
|
|
&file->device->disassociate_srcu);
|
|
|
|
if (!ib_dev) {
|
|
|
|
ret = -EIO;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!file->ucontext)
|
|
|
|
ret = -ENODEV;
|
2005-07-08 04:57:13 +04:00
|
|
|
else
|
2015-08-13 18:32:05 +03:00
|
|
|
ret = ib_dev->mmap(file->ucontext, vma);
|
|
|
|
out:
|
|
|
|
srcu_read_unlock(&file->device->disassociate_srcu, srcu_key);
|
|
|
|
return ret;
|
2005-07-08 04:57:13 +04:00
|
|
|
}
|
|
|
|
|
2008-06-28 01:43:20 +04:00
|
|
|
/*
|
|
|
|
* ib_uverbs_open() does not need the BKL:
|
|
|
|
*
|
2010-02-02 22:07:54 +03:00
|
|
|
* - the ib_uverbs_device structures are properly reference counted and
|
2008-06-28 01:43:20 +04:00
|
|
|
* everything else is purely local to the file being created, so
|
|
|
|
* races against other open calls are not a problem;
|
|
|
|
* - there is no ioctl method to race against;
|
2010-02-02 22:07:54 +03:00
|
|
|
* - the open method will either immediately run -ENXIO, or all
|
|
|
|
* required initialization will be done.
|
2008-06-28 01:43:20 +04:00
|
|
|
*/
|
2005-07-08 04:57:13 +04:00
|
|
|
static int ib_uverbs_open(struct inode *inode, struct file *filp)
|
|
|
|
{
|
2005-10-29 02:38:26 +04:00
|
|
|
struct ib_uverbs_device *dev;
|
2005-07-08 04:57:13 +04:00
|
|
|
struct ib_uverbs_file *file;
|
2015-08-13 18:32:05 +03:00
|
|
|
struct ib_device *ib_dev;
|
2005-10-29 02:38:26 +04:00
|
|
|
int ret;
|
2015-08-13 18:32:05 +03:00
|
|
|
int module_dependent;
|
|
|
|
int srcu_key;
|
2005-07-08 04:57:13 +04:00
|
|
|
|
2010-02-02 22:07:54 +03:00
|
|
|
dev = container_of(inode->i_cdev, struct ib_uverbs_device, cdev);
|
2015-08-13 18:32:03 +03:00
|
|
|
if (!atomic_inc_not_zero(&dev->refcount))
|
2005-10-29 02:38:26 +04:00
|
|
|
return -ENXIO;
|
|
|
|
|
2015-08-13 18:32:05 +03:00
|
|
|
srcu_key = srcu_read_lock(&dev->disassociate_srcu);
|
|
|
|
mutex_lock(&dev->lists_mutex);
|
|
|
|
ib_dev = srcu_dereference(dev->ib_dev,
|
|
|
|
&dev->disassociate_srcu);
|
|
|
|
if (!ib_dev) {
|
|
|
|
ret = -EIO;
|
2005-10-29 02:38:26 +04:00
|
|
|
goto err;
|
|
|
|
}
|
2005-07-08 04:57:13 +04:00
|
|
|
|
2015-08-13 18:32:05 +03:00
|
|
|
/* In case IB device supports disassociate ucontext, there is no hard
|
|
|
|
* dependency between uverbs device and its low level device.
|
|
|
|
*/
|
|
|
|
module_dependent = !(ib_dev->disassociate_ucontext);
|
|
|
|
|
|
|
|
if (module_dependent) {
|
|
|
|
if (!try_module_get(ib_dev->owner)) {
|
|
|
|
ret = -ENODEV;
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
file = kzalloc(sizeof(*file), GFP_KERNEL);
|
2005-09-27 00:01:03 +04:00
|
|
|
if (!file) {
|
2005-10-29 02:38:26 +04:00
|
|
|
ret = -ENOMEM;
|
2015-08-13 18:32:05 +03:00
|
|
|
if (module_dependent)
|
|
|
|
goto err_module;
|
|
|
|
|
|
|
|
goto err;
|
2005-09-27 00:01:03 +04:00
|
|
|
}
|
2005-07-08 04:57:13 +04:00
|
|
|
|
2005-10-29 02:38:26 +04:00
|
|
|
file->device = dev;
|
|
|
|
file->ucontext = NULL;
|
|
|
|
file->async_file = NULL;
|
2005-07-08 04:57:13 +04:00
|
|
|
kref_init(&file->ref);
|
2006-01-14 01:51:39 +03:00
|
|
|
mutex_init(&file->mutex);
|
2005-07-08 04:57:13 +04:00
|
|
|
|
|
|
|
filp->private_data = file;
|
2015-08-13 18:32:03 +03:00
|
|
|
kobject_get(&dev->kobj);
|
2015-08-13 18:32:05 +03:00
|
|
|
list_add_tail(&file->list, &dev->uverbs_file_list);
|
|
|
|
mutex_unlock(&dev->lists_mutex);
|
|
|
|
srcu_read_unlock(&dev->disassociate_srcu, srcu_key);
|
2005-07-08 04:57:13 +04:00
|
|
|
|
2010-04-10 04:13:50 +04:00
|
|
|
return nonseekable_open(inode, filp);
|
2005-10-29 02:38:26 +04:00
|
|
|
|
|
|
|
err_module:
|
2015-08-13 18:32:05 +03:00
|
|
|
module_put(ib_dev->owner);
|
2005-10-29 02:38:26 +04:00
|
|
|
|
|
|
|
err:
|
2015-08-13 18:32:05 +03:00
|
|
|
mutex_unlock(&dev->lists_mutex);
|
|
|
|
srcu_read_unlock(&dev->disassociate_srcu, srcu_key);
|
2015-08-13 18:32:03 +03:00
|
|
|
if (atomic_dec_and_test(&dev->refcount))
|
|
|
|
ib_uverbs_comp_dev(dev);
|
|
|
|
|
2005-10-29 02:38:26 +04:00
|
|
|
return ret;
|
2005-07-08 04:57:13 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
static int ib_uverbs_close(struct inode *inode, struct file *filp)
|
|
|
|
{
|
|
|
|
struct ib_uverbs_file *file = filp->private_data;
|
2015-08-13 18:32:03 +03:00
|
|
|
struct ib_uverbs_device *dev = file->device;
|
2015-08-13 18:32:05 +03:00
|
|
|
struct ib_ucontext *ucontext = NULL;
|
|
|
|
|
|
|
|
mutex_lock(&file->device->lists_mutex);
|
|
|
|
ucontext = file->ucontext;
|
|
|
|
file->ucontext = NULL;
|
|
|
|
if (!file->is_closed) {
|
|
|
|
list_del(&file->list);
|
|
|
|
file->is_closed = 1;
|
|
|
|
}
|
|
|
|
mutex_unlock(&file->device->lists_mutex);
|
|
|
|
if (ucontext)
|
|
|
|
ib_uverbs_cleanup_ucontext(file, ucontext);
|
2005-10-29 02:38:26 +04:00
|
|
|
|
|
|
|
if (file->async_file)
|
|
|
|
kref_put(&file->async_file->ref, ib_uverbs_release_event_file);
|
2005-07-08 04:57:13 +04:00
|
|
|
|
|
|
|
kref_put(&file->ref, ib_uverbs_release_file);
|
2015-08-13 18:32:03 +03:00
|
|
|
kobject_put(&dev->kobj);
|
2005-07-08 04:57:13 +04:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2007-02-12 11:55:32 +03:00
|
|
|
static const struct file_operations uverbs_fops = {
|
2010-02-02 22:08:19 +03:00
|
|
|
.owner = THIS_MODULE,
|
|
|
|
.write = ib_uverbs_write,
|
|
|
|
.open = ib_uverbs_open,
|
2010-04-10 04:13:50 +04:00
|
|
|
.release = ib_uverbs_close,
|
|
|
|
.llseek = no_llseek,
|
2005-07-08 04:57:13 +04:00
|
|
|
};
|
|
|
|
|
2007-02-12 11:55:32 +03:00
|
|
|
static const struct file_operations uverbs_mmap_fops = {
|
2010-02-02 22:08:19 +03:00
|
|
|
.owner = THIS_MODULE,
|
|
|
|
.write = ib_uverbs_write,
|
2005-07-08 04:57:13 +04:00
|
|
|
.mmap = ib_uverbs_mmap,
|
2010-02-02 22:08:19 +03:00
|
|
|
.open = ib_uverbs_open,
|
2010-04-10 04:13:50 +04:00
|
|
|
.release = ib_uverbs_close,
|
|
|
|
.llseek = no_llseek,
|
2005-07-08 04:57:13 +04:00
|
|
|
};
|
|
|
|
|
|
|
|
static struct ib_client uverbs_client = {
|
|
|
|
.name = "uverbs",
|
|
|
|
.add = ib_uverbs_add_one,
|
|
|
|
.remove = ib_uverbs_remove_one
|
|
|
|
};
|
|
|
|
|
2008-02-22 02:13:36 +03:00
|
|
|
static ssize_t show_ibdev(struct device *device, struct device_attribute *attr,
|
|
|
|
char *buf)
|
2005-07-08 04:57:13 +04:00
|
|
|
{
|
2015-08-13 18:32:05 +03:00
|
|
|
int ret = -ENODEV;
|
|
|
|
int srcu_key;
|
2008-02-22 02:13:36 +03:00
|
|
|
struct ib_uverbs_device *dev = dev_get_drvdata(device);
|
2015-08-13 18:32:05 +03:00
|
|
|
struct ib_device *ib_dev;
|
2005-10-29 02:38:26 +04:00
|
|
|
|
|
|
|
if (!dev)
|
|
|
|
return -ENODEV;
|
2005-07-08 04:57:13 +04:00
|
|
|
|
2015-08-13 18:32:05 +03:00
|
|
|
srcu_key = srcu_read_lock(&dev->disassociate_srcu);
|
|
|
|
ib_dev = srcu_dereference(dev->ib_dev, &dev->disassociate_srcu);
|
|
|
|
if (ib_dev)
|
|
|
|
ret = sprintf(buf, "%s\n", ib_dev->name);
|
|
|
|
srcu_read_unlock(&dev->disassociate_srcu, srcu_key);
|
|
|
|
|
|
|
|
return ret;
|
2005-07-08 04:57:13 +04:00
|
|
|
}
|
2008-02-22 02:13:36 +03:00
|
|
|
static DEVICE_ATTR(ibdev, S_IRUGO, show_ibdev, NULL);
|
2005-07-08 04:57:13 +04:00
|
|
|
|
2008-02-22 02:13:36 +03:00
|
|
|
static ssize_t show_dev_abi_version(struct device *device,
|
|
|
|
struct device_attribute *attr, char *buf)
|
2005-09-30 01:17:48 +04:00
|
|
|
{
|
2008-02-22 02:13:36 +03:00
|
|
|
struct ib_uverbs_device *dev = dev_get_drvdata(device);
|
2015-08-13 18:32:05 +03:00
|
|
|
int ret = -ENODEV;
|
|
|
|
int srcu_key;
|
|
|
|
struct ib_device *ib_dev;
|
2005-10-29 02:38:26 +04:00
|
|
|
|
|
|
|
if (!dev)
|
|
|
|
return -ENODEV;
|
2015-08-13 18:32:05 +03:00
|
|
|
srcu_key = srcu_read_lock(&dev->disassociate_srcu);
|
|
|
|
ib_dev = srcu_dereference(dev->ib_dev, &dev->disassociate_srcu);
|
|
|
|
if (ib_dev)
|
|
|
|
ret = sprintf(buf, "%d\n", ib_dev->uverbs_abi_ver);
|
|
|
|
srcu_read_unlock(&dev->disassociate_srcu, srcu_key);
|
2005-09-30 01:17:48 +04:00
|
|
|
|
2015-08-13 18:32:05 +03:00
|
|
|
return ret;
|
2005-09-30 01:17:48 +04:00
|
|
|
}
|
2008-02-22 02:13:36 +03:00
|
|
|
static DEVICE_ATTR(abi_version, S_IRUGO, show_dev_abi_version, NULL);
|
2005-09-30 01:17:48 +04:00
|
|
|
|
2010-01-05 14:48:09 +03:00
|
|
|
static CLASS_ATTR_STRING(abi_version, S_IRUGO,
|
|
|
|
__stringify(IB_USER_VERBS_ABI_VERSION));
|
2005-07-08 04:57:13 +04:00
|
|
|
|
2010-02-02 22:08:09 +03:00
|
|
|
static dev_t overflow_maj;
|
|
|
|
static DECLARE_BITMAP(overflow_map, IB_UVERBS_MAX_DEVICES);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we have more than IB_UVERBS_MAX_DEVICES, dynamically overflow by
|
|
|
|
* requesting a new major number and doubling the number of max devices we
|
|
|
|
* support. It's stupid, but simple.
|
|
|
|
*/
|
|
|
|
static int find_overflow_devnum(void)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (!overflow_maj) {
|
|
|
|
ret = alloc_chrdev_region(&overflow_maj, 0, IB_UVERBS_MAX_DEVICES,
|
|
|
|
"infiniband_verbs");
|
|
|
|
if (ret) {
|
|
|
|
printk(KERN_ERR "user_verbs: couldn't register dynamic device number\n");
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = find_first_zero_bit(overflow_map, IB_UVERBS_MAX_DEVICES);
|
|
|
|
if (ret >= IB_UVERBS_MAX_DEVICES)
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2005-07-08 04:57:13 +04:00
|
|
|
static void ib_uverbs_add_one(struct ib_device *device)
|
|
|
|
{
|
2010-02-02 22:07:59 +03:00
|
|
|
int devnum;
|
2010-02-02 22:08:04 +03:00
|
|
|
dev_t base;
|
2005-07-08 04:57:13 +04:00
|
|
|
struct ib_uverbs_device *uverbs_dev;
|
2015-08-13 18:32:05 +03:00
|
|
|
int ret;
|
2005-07-08 04:57:13 +04:00
|
|
|
|
|
|
|
if (!device->alloc_ucontext)
|
|
|
|
return;
|
|
|
|
|
2005-11-02 18:23:14 +03:00
|
|
|
uverbs_dev = kzalloc(sizeof *uverbs_dev, GFP_KERNEL);
|
2005-07-08 04:57:13 +04:00
|
|
|
if (!uverbs_dev)
|
|
|
|
return;
|
|
|
|
|
2015-08-13 18:32:05 +03:00
|
|
|
ret = init_srcu_struct(&uverbs_dev->disassociate_srcu);
|
|
|
|
if (ret) {
|
|
|
|
kfree(uverbs_dev);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-08-13 18:32:03 +03:00
|
|
|
atomic_set(&uverbs_dev->refcount, 1);
|
2006-08-03 21:56:42 +04:00
|
|
|
init_completion(&uverbs_dev->comp);
|
2011-05-24 19:33:46 +04:00
|
|
|
uverbs_dev->xrcd_tree = RB_ROOT;
|
|
|
|
mutex_init(&uverbs_dev->xrcd_tree_mutex);
|
2015-08-13 18:32:03 +03:00
|
|
|
kobject_init(&uverbs_dev->kobj, &ib_uverbs_dev_ktype);
|
2015-08-13 18:32:05 +03:00
|
|
|
mutex_init(&uverbs_dev->lists_mutex);
|
|
|
|
INIT_LIST_HEAD(&uverbs_dev->uverbs_file_list);
|
|
|
|
INIT_LIST_HEAD(&uverbs_dev->uverbs_events_file_list);
|
2005-10-29 02:38:26 +04:00
|
|
|
|
2005-07-08 04:57:13 +04:00
|
|
|
spin_lock(&map_lock);
|
2010-02-02 22:07:59 +03:00
|
|
|
devnum = find_first_zero_bit(dev_map, IB_UVERBS_MAX_DEVICES);
|
|
|
|
if (devnum >= IB_UVERBS_MAX_DEVICES) {
|
2005-07-08 04:57:13 +04:00
|
|
|
spin_unlock(&map_lock);
|
2010-02-02 22:08:09 +03:00
|
|
|
devnum = find_overflow_devnum();
|
|
|
|
if (devnum < 0)
|
|
|
|
goto err;
|
|
|
|
|
|
|
|
spin_lock(&map_lock);
|
|
|
|
uverbs_dev->devnum = devnum + IB_UVERBS_MAX_DEVICES;
|
|
|
|
base = devnum + overflow_maj;
|
|
|
|
set_bit(devnum, overflow_map);
|
|
|
|
} else {
|
|
|
|
uverbs_dev->devnum = devnum;
|
|
|
|
base = devnum + IB_UVERBS_BASE_DEV;
|
|
|
|
set_bit(devnum, dev_map);
|
2005-07-08 04:57:13 +04:00
|
|
|
}
|
|
|
|
spin_unlock(&map_lock);
|
|
|
|
|
2015-08-13 18:32:05 +03:00
|
|
|
rcu_assign_pointer(uverbs_dev->ib_dev, device);
|
2007-05-03 14:48:47 +04:00
|
|
|
uverbs_dev->num_comp_vectors = device->num_comp_vectors;
|
2005-07-08 04:57:13 +04:00
|
|
|
|
2010-02-02 22:07:49 +03:00
|
|
|
cdev_init(&uverbs_dev->cdev, NULL);
|
|
|
|
uverbs_dev->cdev.owner = THIS_MODULE;
|
|
|
|
uverbs_dev->cdev.ops = device->mmap ? &uverbs_mmap_fops : &uverbs_fops;
|
2015-08-13 18:32:03 +03:00
|
|
|
uverbs_dev->cdev.kobj.parent = &uverbs_dev->kobj;
|
2010-02-02 22:07:49 +03:00
|
|
|
kobject_set_name(&uverbs_dev->cdev.kobj, "uverbs%d", uverbs_dev->devnum);
|
2010-02-02 22:08:04 +03:00
|
|
|
if (cdev_add(&uverbs_dev->cdev, base, 1))
|
2005-10-29 02:38:26 +04:00
|
|
|
goto err_cdev;
|
2005-07-08 04:57:13 +04:00
|
|
|
|
2008-07-22 07:03:34 +04:00
|
|
|
uverbs_dev->dev = device_create(uverbs_class, device->dma_device,
|
2010-02-02 22:07:49 +03:00
|
|
|
uverbs_dev->cdev.dev, uverbs_dev,
|
2008-07-22 07:03:34 +04:00
|
|
|
"uverbs%d", uverbs_dev->devnum);
|
2008-02-22 02:13:36 +03:00
|
|
|
if (IS_ERR(uverbs_dev->dev))
|
2005-07-08 04:57:13 +04:00
|
|
|
goto err_cdev;
|
|
|
|
|
2008-02-22 02:13:36 +03:00
|
|
|
if (device_create_file(uverbs_dev->dev, &dev_attr_ibdev))
|
2005-07-08 04:57:13 +04:00
|
|
|
goto err_class;
|
2008-02-22 02:13:36 +03:00
|
|
|
if (device_create_file(uverbs_dev->dev, &dev_attr_abi_version))
|
2005-09-30 01:17:48 +04:00
|
|
|
goto err_class;
|
2005-07-08 04:57:13 +04:00
|
|
|
|
|
|
|
ib_set_client_data(device, &uverbs_client, uverbs_dev);
|
|
|
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
err_class:
|
2010-02-02 22:07:49 +03:00
|
|
|
device_destroy(uverbs_class, uverbs_dev->cdev.dev);
|
2005-07-08 04:57:13 +04:00
|
|
|
|
|
|
|
err_cdev:
|
2010-02-02 22:07:49 +03:00
|
|
|
cdev_del(&uverbs_dev->cdev);
|
2010-02-02 22:08:09 +03:00
|
|
|
if (uverbs_dev->devnum < IB_UVERBS_MAX_DEVICES)
|
|
|
|
clear_bit(devnum, dev_map);
|
|
|
|
else
|
|
|
|
clear_bit(devnum, overflow_map);
|
2005-07-08 04:57:13 +04:00
|
|
|
|
|
|
|
err:
|
2015-08-13 18:32:03 +03:00
|
|
|
if (atomic_dec_and_test(&uverbs_dev->refcount))
|
|
|
|
ib_uverbs_comp_dev(uverbs_dev);
|
2006-08-03 21:56:42 +04:00
|
|
|
wait_for_completion(&uverbs_dev->comp);
|
2015-08-13 18:32:03 +03:00
|
|
|
kobject_put(&uverbs_dev->kobj);
|
2005-07-08 04:57:13 +04:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-08-13 18:32:05 +03:00
|
|
|
static void ib_uverbs_free_hw_resources(struct ib_uverbs_device *uverbs_dev,
|
|
|
|
struct ib_device *ib_dev)
|
|
|
|
{
|
|
|
|
struct ib_uverbs_file *file;
|
|
|
|
struct ib_uverbs_event_file *event_file;
|
|
|
|
struct ib_event event;
|
|
|
|
|
|
|
|
/* Pending running commands to terminate */
|
|
|
|
synchronize_srcu(&uverbs_dev->disassociate_srcu);
|
|
|
|
event.event = IB_EVENT_DEVICE_FATAL;
|
|
|
|
event.element.port_num = 0;
|
|
|
|
event.device = ib_dev;
|
|
|
|
|
|
|
|
mutex_lock(&uverbs_dev->lists_mutex);
|
|
|
|
while (!list_empty(&uverbs_dev->uverbs_file_list)) {
|
|
|
|
struct ib_ucontext *ucontext;
|
|
|
|
|
|
|
|
file = list_first_entry(&uverbs_dev->uverbs_file_list,
|
|
|
|
struct ib_uverbs_file, list);
|
|
|
|
file->is_closed = 1;
|
|
|
|
ucontext = file->ucontext;
|
|
|
|
list_del(&file->list);
|
|
|
|
file->ucontext = NULL;
|
|
|
|
kref_get(&file->ref);
|
|
|
|
mutex_unlock(&uverbs_dev->lists_mutex);
|
|
|
|
/* We must release the mutex before going ahead and calling
|
|
|
|
* disassociate_ucontext. disassociate_ucontext might end up
|
|
|
|
* indirectly calling uverbs_close, for example due to freeing
|
|
|
|
* the resources (e.g mmput).
|
|
|
|
*/
|
|
|
|
ib_uverbs_event_handler(&file->event_handler, &event);
|
|
|
|
if (ucontext) {
|
|
|
|
ib_dev->disassociate_ucontext(ucontext);
|
|
|
|
ib_uverbs_cleanup_ucontext(file, ucontext);
|
|
|
|
}
|
|
|
|
|
|
|
|
mutex_lock(&uverbs_dev->lists_mutex);
|
|
|
|
kref_put(&file->ref, ib_uverbs_release_file);
|
|
|
|
}
|
|
|
|
|
|
|
|
while (!list_empty(&uverbs_dev->uverbs_events_file_list)) {
|
|
|
|
event_file = list_first_entry(&uverbs_dev->
|
|
|
|
uverbs_events_file_list,
|
|
|
|
struct ib_uverbs_event_file,
|
|
|
|
list);
|
|
|
|
spin_lock_irq(&event_file->lock);
|
|
|
|
event_file->is_closed = 1;
|
|
|
|
spin_unlock_irq(&event_file->lock);
|
|
|
|
|
|
|
|
list_del(&event_file->list);
|
|
|
|
if (event_file->is_async) {
|
|
|
|
ib_unregister_event_handler(&event_file->uverbs_file->
|
|
|
|
event_handler);
|
|
|
|
event_file->uverbs_file->event_handler.device = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
wake_up_interruptible(&event_file->poll_wait);
|
|
|
|
kill_fasync(&event_file->async_queue, SIGIO, POLL_IN);
|
|
|
|
}
|
|
|
|
mutex_unlock(&uverbs_dev->lists_mutex);
|
|
|
|
}
|
|
|
|
|
2015-07-30 17:50:14 +03:00
|
|
|
static void ib_uverbs_remove_one(struct ib_device *device, void *client_data)
|
2005-07-08 04:57:13 +04:00
|
|
|
{
|
2015-07-30 17:50:14 +03:00
|
|
|
struct ib_uverbs_device *uverbs_dev = client_data;
|
2015-08-13 18:32:05 +03:00
|
|
|
int wait_clients = 1;
|
2005-07-08 04:57:13 +04:00
|
|
|
|
|
|
|
if (!uverbs_dev)
|
|
|
|
return;
|
|
|
|
|
2008-02-22 02:13:36 +03:00
|
|
|
dev_set_drvdata(uverbs_dev->dev, NULL);
|
2010-02-02 22:07:49 +03:00
|
|
|
device_destroy(uverbs_class, uverbs_dev->cdev.dev);
|
|
|
|
cdev_del(&uverbs_dev->cdev);
|
2005-10-29 02:38:26 +04:00
|
|
|
|
2010-02-02 22:08:09 +03:00
|
|
|
if (uverbs_dev->devnum < IB_UVERBS_MAX_DEVICES)
|
|
|
|
clear_bit(uverbs_dev->devnum, dev_map);
|
|
|
|
else
|
|
|
|
clear_bit(uverbs_dev->devnum - IB_UVERBS_MAX_DEVICES, overflow_map);
|
2006-08-03 21:56:42 +04:00
|
|
|
|
2015-08-13 18:32:05 +03:00
|
|
|
if (device->disassociate_ucontext) {
|
|
|
|
/* We disassociate HW resources and immediately return.
|
|
|
|
* Userspace will see a EIO errno for all future access.
|
|
|
|
* Upon returning, ib_device may be freed internally and is not
|
|
|
|
* valid any more.
|
|
|
|
* uverbs_device is still available until all clients close
|
|
|
|
* their files, then the uverbs device ref count will be zero
|
|
|
|
* and its resources will be freed.
|
|
|
|
* Note: At this point no more files can be opened since the
|
|
|
|
* cdev was deleted, however active clients can still issue
|
|
|
|
* commands and close their open files.
|
|
|
|
*/
|
|
|
|
rcu_assign_pointer(uverbs_dev->ib_dev, NULL);
|
|
|
|
ib_uverbs_free_hw_resources(uverbs_dev, device);
|
|
|
|
wait_clients = 0;
|
|
|
|
}
|
|
|
|
|
2015-08-13 18:32:03 +03:00
|
|
|
if (atomic_dec_and_test(&uverbs_dev->refcount))
|
|
|
|
ib_uverbs_comp_dev(uverbs_dev);
|
2015-08-13 18:32:05 +03:00
|
|
|
if (wait_clients)
|
|
|
|
wait_for_completion(&uverbs_dev->comp);
|
2015-08-13 18:32:03 +03:00
|
|
|
kobject_put(&uverbs_dev->kobj);
|
2005-07-08 04:57:13 +04:00
|
|
|
}
|
|
|
|
|
2011-07-24 04:24:48 +04:00
|
|
|
static char *uverbs_devnode(struct device *dev, umode_t *mode)
|
2011-05-23 22:10:05 +04:00
|
|
|
{
|
2011-07-04 20:26:57 +04:00
|
|
|
if (mode)
|
|
|
|
*mode = 0666;
|
2011-05-23 22:10:05 +04:00
|
|
|
return kasprintf(GFP_KERNEL, "infiniband/%s", dev_name(dev));
|
|
|
|
}
|
|
|
|
|
2005-07-08 04:57:13 +04:00
|
|
|
static int __init ib_uverbs_init(void)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = register_chrdev_region(IB_UVERBS_BASE_DEV, IB_UVERBS_MAX_DEVICES,
|
|
|
|
"infiniband_verbs");
|
|
|
|
if (ret) {
|
|
|
|
printk(KERN_ERR "user_verbs: couldn't register device number\n");
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2005-10-29 02:38:26 +04:00
|
|
|
uverbs_class = class_create(THIS_MODULE, "infiniband_verbs");
|
|
|
|
if (IS_ERR(uverbs_class)) {
|
|
|
|
ret = PTR_ERR(uverbs_class);
|
2005-07-08 04:57:13 +04:00
|
|
|
printk(KERN_ERR "user_verbs: couldn't create class infiniband_verbs\n");
|
|
|
|
goto out_chrdev;
|
|
|
|
}
|
|
|
|
|
2011-05-23 22:10:05 +04:00
|
|
|
uverbs_class->devnode = uverbs_devnode;
|
|
|
|
|
2010-01-05 14:48:09 +03:00
|
|
|
ret = class_create_file(uverbs_class, &class_attr_abi_version.attr);
|
2005-07-08 04:57:13 +04:00
|
|
|
if (ret) {
|
|
|
|
printk(KERN_ERR "user_verbs: couldn't create abi_version attribute\n");
|
|
|
|
goto out_class;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = ib_register_client(&uverbs_client);
|
|
|
|
if (ret) {
|
|
|
|
printk(KERN_ERR "user_verbs: couldn't register client\n");
|
2010-02-25 03:51:20 +03:00
|
|
|
goto out_class;
|
2005-07-08 04:57:13 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
out_class:
|
2005-10-29 02:38:26 +04:00
|
|
|
class_destroy(uverbs_class);
|
2005-07-08 04:57:13 +04:00
|
|
|
|
|
|
|
out_chrdev:
|
|
|
|
unregister_chrdev_region(IB_UVERBS_BASE_DEV, IB_UVERBS_MAX_DEVICES);
|
|
|
|
|
|
|
|
out:
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __exit ib_uverbs_cleanup(void)
|
|
|
|
{
|
|
|
|
ib_unregister_client(&uverbs_client);
|
2005-10-29 02:38:26 +04:00
|
|
|
class_destroy(uverbs_class);
|
2005-07-08 04:57:13 +04:00
|
|
|
unregister_chrdev_region(IB_UVERBS_BASE_DEV, IB_UVERBS_MAX_DEVICES);
|
2010-02-02 22:08:09 +03:00
|
|
|
if (overflow_maj)
|
|
|
|
unregister_chrdev_region(overflow_maj, IB_UVERBS_MAX_DEVICES);
|
2005-10-24 21:53:25 +04:00
|
|
|
idr_destroy(&ib_uverbs_pd_idr);
|
|
|
|
idr_destroy(&ib_uverbs_mr_idr);
|
|
|
|
idr_destroy(&ib_uverbs_mw_idr);
|
|
|
|
idr_destroy(&ib_uverbs_ah_idr);
|
|
|
|
idr_destroy(&ib_uverbs_cq_idr);
|
|
|
|
idr_destroy(&ib_uverbs_qp_idr);
|
|
|
|
idr_destroy(&ib_uverbs_srq_idr);
|
2005-07-08 04:57:13 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
module_init(ib_uverbs_init);
|
|
|
|
module_exit(ib_uverbs_cleanup);
|