* Re: undefined reference to `__aeabi_uldivmod' after 25c13324d03d ("IB/mlx5: Add steering SW ICM device memory type")
From: Jason Gunthorpe @ 2019-05-15 0:32 UTC (permalink / raw)
To: Nathan Chancellor, fengguang.wu, kbuild
Cc: Ariel Levkovich, Eli Cohen, Mark Bloch, Leon Romanovsky,
Doug Ledford, linux-rdma, linux-kernel
In-Reply-To: <20190514194510.GA15465@archlinux-i9>
On Tue, May 14, 2019 at 12:45:10PM -0700, Nathan Chancellor wrote:
> Hi all,
>
> I checked the RDMA mailing list and trees and I haven't seen this
> reported/fixed yet (forgive me if it has) but when building for arm32
> with multi_v7_defconfig and the following configs (distilled from
> allyesconfig):
>
> CONFIG_INFINIBAND=y
> CONFIG_INFINIBAND_ON_DEMAND_PAGING=y
> CONFIG_INFINIBAND_USER_ACCESS=y
> CONFIG_MLX5_CORE=y
> CONFIG_MLX5_INFINIBAND=y
>
> The following link time errors occur:
>
> arm-linux-gnueabi-ld: drivers/infiniband/hw/mlx5/main.o: in function `mlx5_ib_alloc_dm':
> main.c:(.text+0x60c): undefined reference to `__aeabi_uldivmod'
> arm-linux-gnueabi-ld: drivers/infiniband/hw/mlx5/cmd.o: in function `mlx5_cmd_alloc_sw_icm':
> cmd.c:(.text+0x6d4): undefined reference to `__aeabi_uldivmod'
> arm-linux-gnueabi-ld: drivers/infiniband/hw/mlx5/cmd.o: in function `mlx5_cmd_dealloc_sw_icm':
> cmd.c:(.text+0x9ec): undefined reference to `__aeabi_uldivmod'
Fengguang, I'm surprised that 0-day didn't report this earlier..
and come to think of it, I haven't seen a success email from 0-day for
the rdma trees in some time - is it still working?
Thanks,
Jason
^ permalink raw reply
* Re: [PATCH mlx5-next 2/2] net/mlx5: Set completion EQs as shared resources
From: Saeed Mahameed @ 2019-05-14 20:14 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, Jason Gunthorpe, Leon Romanovsky, RDMA mailing list,
Saeed Mahameed, Yishai Hadas, linux-netdev
In-Reply-To: <20190514114412.30604-3-leon@kernel.org>
On Tue, May 14, 2019 at 4:44 AM Leon Romanovsky <leon@kernel.org> wrote:
>
> From: Yishai Hadas <yishaih@mellanox.com>
>
> Mark completion EQs as shared resources so that they can be used by CQs
> with uid != 0.
>
> Fixes: 7efce3691d33 ("IB/mlx5: Add obj create and destroy functionality")
> Signed-off-by: Yishai Hadas <yishaih@mellanox.com>
> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> ---
> drivers/net/ethernet/mellanox/mlx5/core/eq.c | 3 +++
> include/linux/mlx5/mlx5_ifc.h | 2 +-
> 2 files changed, 4 insertions(+), 1 deletion(-)
>
Hi leon,
I see the patch is marked for mlx5-next,
As we spoke earlier, let's push this directly to rdma-next and skip
mlx5-next, we will need to reset the branch soon, so let's keep it
clean.
Thanks,
Saeed
^ permalink raw reply
* undefined reference to `__aeabi_uldivmod' after 25c13324d03d ("IB/mlx5: Add steering SW ICM device memory type")
From: Nathan Chancellor @ 2019-05-14 19:45 UTC (permalink / raw)
To: Ariel Levkovich, Eli Cohen, Mark Bloch, Leon Romanovsky,
Jason Gunthorpe, Doug Ledford
Cc: linux-rdma, linux-kernel
Hi all,
I checked the RDMA mailing list and trees and I haven't seen this
reported/fixed yet (forgive me if it has) but when building for arm32
with multi_v7_defconfig and the following configs (distilled from
allyesconfig):
CONFIG_INFINIBAND=y
CONFIG_INFINIBAND_ON_DEMAND_PAGING=y
CONFIG_INFINIBAND_USER_ACCESS=y
CONFIG_MLX5_CORE=y
CONFIG_MLX5_INFINIBAND=y
The following link time errors occur:
arm-linux-gnueabi-ld: drivers/infiniband/hw/mlx5/main.o: in function `mlx5_ib_alloc_dm':
main.c:(.text+0x60c): undefined reference to `__aeabi_uldivmod'
arm-linux-gnueabi-ld: drivers/infiniband/hw/mlx5/cmd.o: in function `mlx5_cmd_alloc_sw_icm':
cmd.c:(.text+0x6d4): undefined reference to `__aeabi_uldivmod'
arm-linux-gnueabi-ld: drivers/infiniband/hw/mlx5/cmd.o: in function `mlx5_cmd_dealloc_sw_icm':
cmd.c:(.text+0x9ec): undefined reference to `__aeabi_uldivmod'
Bisect log:
git bisect start
# good: [e93c9c99a629c61837d5a7fc2120cd2b6c70dbdd] Linux 5.1
git bisect good e93c9c99a629c61837d5a7fc2120cd2b6c70dbdd
# bad: [63863ee8e2f6f6ae47be3dff4af2f2806f5ca2dd] Merge tag 'gcc-plugins-v5.2-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/kees/linux
git bisect bad 63863ee8e2f6f6ae47be3dff4af2f2806f5ca2dd
# good: [80f232121b69cc69a31ccb2b38c1665d770b0710] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
git bisect good 80f232121b69cc69a31ccb2b38c1665d770b0710
# good: [a2d635decbfa9c1e4ae15cb05b68b2559f7f827c] Merge tag 'drm-next-2019-05-09' of git://anongit.freedesktop.org/drm/drm
git bisect good a2d635decbfa9c1e4ae15cb05b68b2559f7f827c
# bad: [8e4ff713ce313dcabbb60e6ede1ffc193e67631f] Merge tag 'rtc-5.2' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux
git bisect bad 8e4ff713ce313dcabbb60e6ede1ffc193e67631f
# good: [055128ee008b00fba14e3638e7e84fc2cff8d77d] Merge tag 'dmaengine-5.2-rc1' of git://git.infradead.org/users/vkoul/slave-dma
git bisect good 055128ee008b00fba14e3638e7e84fc2cff8d77d
# bad: [abde77eb5c66b2f98539c4644b54f34b7e179e6b] Merge branch 'for-5.2' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup
git bisect bad abde77eb5c66b2f98539c4644b54f34b7e179e6b
# good: [3b70508a6bfbdc78b565e9da22fd98483263494e] RDMA/mlx5: Create flow table with max size supported
git bisect good 3b70508a6bfbdc78b565e9da22fd98483263494e
# bad: [e7a5b4aafd82771f8924905c208d5d236ddcb671] RDMA/device: Don't fire uevent before device is fully initialized
git bisect bad e7a5b4aafd82771f8924905c208d5d236ddcb671
# good: [dd05cb828d0ebecd3d772075fccb85ec3618bedf] RDMA: Get rid of iw_cm_verbs
git bisect good dd05cb828d0ebecd3d772075fccb85ec3618bedf
# bad: [a808273a495c657e33281b181fd7fcc2bb28f662] RDMA/verbs: Add a DMA iterator to return aligned contiguous memory blocks
git bisect bad a808273a495c657e33281b181fd7fcc2bb28f662
# good: [3a4ef2e2b5cf9a34bcc66c0d33f7eba180a14535] RDMA/rdmavt: Catch use-after-free access of AH structures
git bisect good 3a4ef2e2b5cf9a34bcc66c0d33f7eba180a14535
# bad: [33cde96fb5d7ae36207541c8a832d7fae3cadbde] IB/mlx5: Device resource control for privileged DEVX user
git bisect bad 33cde96fb5d7ae36207541c8a832d7fae3cadbde
# good: [4056b12efd43248d8331b6ed93df5ea5250106a9] IB/mlx5: Warn on allocated MEMIC buffers during cleanup
git bisect good 4056b12efd43248d8331b6ed93df5ea5250106a9
# bad: [25c13324d03d004f9e8071bf5bf5d5c6fdace71e] IB/mlx5: Add steering SW ICM device memory type
git bisect bad 25c13324d03d004f9e8071bf5bf5d5c6fdace71e
# first bad commit: [25c13324d03d004f9e8071bf5bf5d5c6fdace71e] IB/mlx5: Add steering SW ICM device memory type
DIV_ROUND_UP is u64 / u32 in this case. I think DIV_ROUND_UP_ULL is
needed but I am not sure if that has any unintended side effects so I
didn't want to send a patch.
I would appreciate if you guys could look into this.
Cheers,
Nathan
^ permalink raw reply
* Re: [PATCH 5/5] IB/hfi1: Fix improper uses of smp_mb__before_atomic()
From: Andrea Parri @ 2019-05-14 14:48 UTC (permalink / raw)
To: Dennis Dalessandro
Cc: Ruhl, Michael J, linux-kernel@vger.kernel.org, Marciniszyn, Mike,
Doug Ledford, Jason Gunthorpe, linux-rdma@vger.kernel.org,
Paul E. McKenney, Peter Zijlstra
In-Reply-To: <0a78eded-6c08-8d32-ec31-d62d6feb2118@intel.com>
On Tue, May 14, 2019 at 08:32:52AM -0400, Dennis Dalessandro wrote:
> On 5/9/2019 5:12 PM, Andrea Parri wrote:
> >On Tue, Apr 30, 2019 at 01:16:57AM +0200, Andrea Parri wrote:
> >>Hi Mike,
> >>
> >>>>This barrier only applies to the read-modify-write operations; in
> >>>>particular, it does not apply to the atomic_read() primitive.
> >>>>
> >>>>Replace the barrier with an smp_mb().
> >>>
> >>>This is one of a couple of barrier issues that we are currently looking into.
> >>>
> >>>See:
> >>>
> >>>[PATCH for-next 6/9] IB/rdmavt: Add new completion inline
> >>>
> >>>We will take a look at this one as well.
> >>
> >>Thank you for the reference and for looking into this,
> >
> >So, I'm planning to just drop this patch; or can I do something to help?
> >
> >Please let me know.
>
> Mike was looking into this, and I've got a handful of patches from him to
> review. He's unavailable for a while but if it's not included in the patches
> I've got we'll get something out shortly. So yes I think we can hold off on
> this patch for now. Thanks.
Thank you for the confirmation, Dennis. I'll hold off on this one.
Andrea
^ permalink raw reply
* Re: [PATCH 5/5] IB/hfi1: Fix improper uses of smp_mb__before_atomic()
From: Dennis Dalessandro @ 2019-05-14 12:32 UTC (permalink / raw)
To: Andrea Parri, Ruhl, Michael J
Cc: linux-kernel@vger.kernel.org, Marciniszyn, Mike, Doug Ledford,
Jason Gunthorpe, linux-rdma@vger.kernel.org, Paul E. McKenney,
Peter Zijlstra
In-Reply-To: <20190509211221.GA4966@andrea>
On 5/9/2019 5:12 PM, Andrea Parri wrote:
> On Tue, Apr 30, 2019 at 01:16:57AM +0200, Andrea Parri wrote:
>> Hi Mike,
>>
>>>> This barrier only applies to the read-modify-write operations; in
>>>> particular, it does not apply to the atomic_read() primitive.
>>>>
>>>> Replace the barrier with an smp_mb().
>>>
>>> This is one of a couple of barrier issues that we are currently looking into.
>>>
>>> See:
>>>
>>> [PATCH for-next 6/9] IB/rdmavt: Add new completion inline
>>>
>>> We will take a look at this one as well.
>>
>> Thank you for the reference and for looking into this,
>
> So, I'm planning to just drop this patch; or can I do something to help?
>
> Please let me know.
Mike was looking into this, and I've got a handful of patches from him
to review. He's unavailable for a while but if it's not included in the
patches I've got we'll get something out shortly. So yes I think we can
hold off on this patch for now. Thanks.
-Denny
^ permalink raw reply
* CFP: 4th RDMA Mini-Summit at LPC 2019
From: Leon Romanovsky @ 2019-05-14 12:23 UTC (permalink / raw)
To: RDMA mailing list; +Cc: linux-netdev, linux-mm, Jason Gunthorpe, Doug Ledford
This is a call for proposals for the 4th RDMA mini-summit at the Linux
Plumbers Conference in Lisbon, Portugal, which will be happening on
September 9-11h, 2019.
We are looking for topics with focus on active audience discussions
and problem solving. The preferable topic is up to 30 minutes with
3-5 slides maximum.
This year, the LPC will include netdev track too and it is
collocated with Kernel Summit, such timing makes an excellent
opportunity to drive cross-tree solutions.
BTW, RDMA is not accepted yet as a track in LPC, but let's think
positive and start collect topics.
Thanks
^ permalink raw reply
* [PATCH mlx5-next 2/2] net/mlx5: Set completion EQs as shared resources
From: Leon Romanovsky @ 2019-05-14 11:44 UTC (permalink / raw)
To: Doug Ledford, Jason Gunthorpe
Cc: Leon Romanovsky, RDMA mailing list, Saeed Mahameed, Yishai Hadas,
linux-netdev
In-Reply-To: <20190514114412.30604-1-leon@kernel.org>
From: Yishai Hadas <yishaih@mellanox.com>
Mark completion EQs as shared resources so that they can be used by CQs
with uid != 0.
Fixes: 7efce3691d33 ("IB/mlx5: Add obj create and destroy functionality")
Signed-off-by: Yishai Hadas <yishaih@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/eq.c | 3 +++
include/linux/mlx5/mlx5_ifc.h | 2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eq.c b/drivers/net/ethernet/mellanox/mlx5/core/eq.c
index 5aac97847721..23883d1fa22f 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eq.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eq.c
@@ -291,6 +291,9 @@ create_map_eq(struct mlx5_core_dev *dev, struct mlx5_eq *eq, const char *name,
mlx5_fill_page_array(&eq->buf, pas);
MLX5_SET(create_eq_in, in, opcode, MLX5_CMD_OP_CREATE_EQ);
+ if (!param->mask && MLX5_CAP_GEN(dev, log_max_uctx))
+ MLX5_SET(create_eq_in, in, uid, MLX5_SHARED_RESOURCE_UID);
+
MLX5_SET64(create_eq_in, in, event_bitmask, param->mask);
eqc = MLX5_ADDR_OF(create_eq_in, in, eq_context_entry);
diff --git a/include/linux/mlx5/mlx5_ifc.h b/include/linux/mlx5/mlx5_ifc.h
index 9be13e2c5a20..9c9979cf0fd5 100644
--- a/include/linux/mlx5/mlx5_ifc.h
+++ b/include/linux/mlx5/mlx5_ifc.h
@@ -7346,7 +7346,7 @@ struct mlx5_ifc_create_eq_out_bits {
struct mlx5_ifc_create_eq_in_bits {
u8 opcode[0x10];
- u8 reserved_at_10[0x10];
+ u8 uid[0x10];
u8 reserved_at_20[0x10];
u8 op_mod[0x10];
--
2.20.1
^ permalink raw reply related
* [PATCH rdma-next 1/2] IB/mlx5: Verify DEVX general object type correctly
From: Leon Romanovsky @ 2019-05-14 11:44 UTC (permalink / raw)
To: Doug Ledford, Jason Gunthorpe
Cc: Leon Romanovsky, RDMA mailing list, Saeed Mahameed, Yishai Hadas,
linux-netdev
In-Reply-To: <20190514114412.30604-1-leon@kernel.org>
From: Yishai Hadas <yishaih@mellanox.com>
As the obj_id in the firmware is not globally unique in general_object,
the object type must be considered upon checking for a valid object id.
Fixes: 2351776e87a1 ("IB/mlx5: Verify DEVX object type")
Signed-off-by: Yishai Hadas <yishaih@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
---
drivers/infiniband/hw/mlx5/devx.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/infiniband/hw/mlx5/devx.c b/drivers/infiniband/hw/mlx5/devx.c
index 169ffffcf5ed..80b42d069328 100644
--- a/drivers/infiniband/hw/mlx5/devx.c
+++ b/drivers/infiniband/hw/mlx5/devx.c
@@ -154,7 +154,7 @@ bool mlx5_ib_devx_is_flow_counter(void *obj, u32 *counter_id)
* must be considered upon checking for a valid object id.
* For that the opcode of the creator command is encoded as part of the obj_id.
*/
-static u64 get_enc_obj_id(u16 opcode, u32 obj_id)
+static u64 get_enc_obj_id(u32 opcode, u32 obj_id)
{
return ((u64)opcode << 32) | obj_id;
}
@@ -167,7 +167,9 @@ static u64 devx_get_obj_id(const void *in)
switch (opcode) {
case MLX5_CMD_OP_MODIFY_GENERAL_OBJECT:
case MLX5_CMD_OP_QUERY_GENERAL_OBJECT:
- obj_id = get_enc_obj_id(MLX5_CMD_OP_CREATE_GENERAL_OBJECT,
+ obj_id = get_enc_obj_id(MLX5_CMD_OP_CREATE_GENERAL_OBJECT |
+ MLX5_GET(general_obj_in_cmd_hdr, in,
+ obj_type) << 16,
MLX5_GET(general_obj_in_cmd_hdr, in,
obj_id));
break;
@@ -1171,6 +1173,7 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_OBJ_CREATE)(
struct mlx5_ib_dev *dev = to_mdev(c->ibucontext.device);
u32 out[MLX5_ST_SZ_DW(general_obj_out_cmd_hdr)];
struct devx_obj *obj;
+ u16 obj_type = 0;
int err;
int uid;
u32 obj_id;
@@ -1230,7 +1233,11 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_OBJ_CREATE)(
if (err)
goto err_copy;
- obj->obj_id = get_enc_obj_id(opcode, obj_id);
+ if (opcode == MLX5_CMD_OP_CREATE_GENERAL_OBJECT)
+ obj_type = MLX5_GET(general_obj_in_cmd_hdr, cmd_in, obj_type);
+
+ obj->obj_id = get_enc_obj_id(opcode | obj_type << 16, obj_id);
+
return 0;
err_copy:
--
2.20.1
^ permalink raw reply related
* [PATCH rdma-next 0/2] DevX fixes
From: Leon Romanovsky @ 2019-05-14 11:44 UTC (permalink / raw)
To: Doug Ledford, Jason Gunthorpe
Cc: Leon Romanovsky, RDMA mailing list, Saeed Mahameed, Yishai Hadas,
linux-netdev
From: Leon Romanovsky <leonro@mellanox.com>
Hi,
There are two very short but important fixes to DevX flows.
Thanks
Yishai Hadas (2):
IB/mlx5: Verify DEVX general object type correctly
net/mlx5: Set completion EQs as shared resources
drivers/infiniband/hw/mlx5/devx.c | 13 ++++++++++---
drivers/net/ethernet/mellanox/mlx5/core/eq.c | 3 +++
include/linux/mlx5/mlx5_ifc.h | 2 +-
3 files changed, 14 insertions(+), 4 deletions(-)
^ permalink raw reply
* [PATCH v2] RDMA: Directly cast the sockaddr union to sockaddr
From: Jason Gunthorpe @ 2019-05-14 0:55 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Miller, Doug Ledford, linux-rdma, Linux List Kernel Mailing,
Netdev
gcc 9 now does allocation size tracking and thinks that passing the member
of a union and then accessing beyond that member's bounds is an overflow.
Instead of using the union member, use the entire union with a cast to
get to the sockaddr. gcc will now know that the memory extends the full
size of the union.
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
---
drivers/infiniband/core/addr.c | 16 ++++++++--------
drivers/infiniband/hw/ocrdma/ocrdma_ah.c | 5 ++---
drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 5 ++---
3 files changed, 12 insertions(+), 14 deletions(-)
I missed the ocrdma files in the v1
We can revisit what to do with that repetitive union after the merge
window, but this simple patch will eliminate the warnings for now.
Linus, I'll send this as a PR tomorrow - there is also a bug fix for
the rdma-netlink changes posted that should go too.
Thanks,
Jason
diff --git a/drivers/infiniband/core/addr.c b/drivers/infiniband/core/addr.c
index ba01b90c04e775..2f7d14159841f8 100644
--- a/drivers/infiniband/core/addr.c
+++ b/drivers/infiniband/core/addr.c
@@ -731,8 +731,8 @@ int roce_resolve_route_from_path(struct sa_path_rec *rec,
if (rec->roce.route_resolved)
return 0;
- rdma_gid2ip(&sgid._sockaddr, &rec->sgid);
- rdma_gid2ip(&dgid._sockaddr, &rec->dgid);
+ rdma_gid2ip((struct sockaddr *)&sgid, &rec->sgid);
+ rdma_gid2ip((struct sockaddr *)&dgid, &rec->dgid);
if (sgid._sockaddr.sa_family != dgid._sockaddr.sa_family)
return -EINVAL;
@@ -743,7 +743,7 @@ int roce_resolve_route_from_path(struct sa_path_rec *rec,
dev_addr.net = &init_net;
dev_addr.sgid_attr = attr;
- ret = addr_resolve(&sgid._sockaddr, &dgid._sockaddr,
+ ret = addr_resolve((struct sockaddr *)&sgid, (struct sockaddr *)&dgid,
&dev_addr, false, true, 0);
if (ret)
return ret;
@@ -815,22 +815,22 @@ int rdma_addr_find_l2_eth_by_grh(const union ib_gid *sgid,
struct rdma_dev_addr dev_addr;
struct resolve_cb_context ctx;
union {
- struct sockaddr _sockaddr;
struct sockaddr_in _sockaddr_in;
struct sockaddr_in6 _sockaddr_in6;
} sgid_addr, dgid_addr;
int ret;
- rdma_gid2ip(&sgid_addr._sockaddr, sgid);
- rdma_gid2ip(&dgid_addr._sockaddr, dgid);
+ rdma_gid2ip((struct sockaddr *)&sgid_addr, sgid);
+ rdma_gid2ip((struct sockaddr *)&dgid_addr, dgid);
memset(&dev_addr, 0, sizeof(dev_addr));
dev_addr.net = &init_net;
dev_addr.sgid_attr = sgid_attr;
init_completion(&ctx.comp);
- ret = rdma_resolve_ip(&sgid_addr._sockaddr, &dgid_addr._sockaddr,
- &dev_addr, 1000, resolve_cb, true, &ctx);
+ ret = rdma_resolve_ip((struct sockaddr *)&sgid_addr,
+ (struct sockaddr *)&dgid_addr, &dev_addr, 1000,
+ resolve_cb, true, &ctx);
if (ret)
return ret;
diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_ah.c b/drivers/infiniband/hw/ocrdma/ocrdma_ah.c
index 1d4ea135c28f2a..8d3e36d548aae9 100644
--- a/drivers/infiniband/hw/ocrdma/ocrdma_ah.c
+++ b/drivers/infiniband/hw/ocrdma/ocrdma_ah.c
@@ -83,7 +83,6 @@ static inline int set_av_attr(struct ocrdma_dev *dev, struct ocrdma_ah *ah,
struct iphdr ipv4;
const struct ib_global_route *ib_grh;
union {
- struct sockaddr _sockaddr;
struct sockaddr_in _sockaddr_in;
struct sockaddr_in6 _sockaddr_in6;
} sgid_addr, dgid_addr;
@@ -133,9 +132,9 @@ static inline int set_av_attr(struct ocrdma_dev *dev, struct ocrdma_ah *ah,
ipv4.tot_len = htons(0);
ipv4.ttl = ib_grh->hop_limit;
ipv4.protocol = nxthdr;
- rdma_gid2ip(&sgid_addr._sockaddr, sgid);
+ rdma_gid2ip((struct sockaddr *)&sgid_addr, sgid);
ipv4.saddr = sgid_addr._sockaddr_in.sin_addr.s_addr;
- rdma_gid2ip(&dgid_addr._sockaddr, &ib_grh->dgid);
+ rdma_gid2ip((struct sockaddr*)&dgid_addr, &ib_grh->dgid);
ipv4.daddr = dgid_addr._sockaddr_in.sin_addr.s_addr;
memcpy((u8 *)ah->av + eth_sz, &ipv4, sizeof(struct iphdr));
} else {
diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
index 32674b291f60da..5127e2ea4bdd2d 100644
--- a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
+++ b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
@@ -2499,7 +2499,6 @@ static int ocrdma_set_av_params(struct ocrdma_qp *qp,
u16 vlan_id = 0xFFFF;
u8 mac_addr[6], hdr_type;
union {
- struct sockaddr _sockaddr;
struct sockaddr_in _sockaddr_in;
struct sockaddr_in6 _sockaddr_in6;
} sgid_addr, dgid_addr;
@@ -2542,8 +2541,8 @@ static int ocrdma_set_av_params(struct ocrdma_qp *qp,
hdr_type = rdma_gid_attr_network_type(sgid_attr);
if (hdr_type == RDMA_NETWORK_IPV4) {
- rdma_gid2ip(&sgid_addr._sockaddr, &sgid_attr->gid);
- rdma_gid2ip(&dgid_addr._sockaddr, &grh->dgid);
+ rdma_gid2ip((struct sockaddr *)&sgid_addr, &sgid_attr->gid);
+ rdma_gid2ip((struct sockaddr *)&dgid_addr, &grh->dgid);
memcpy(&cmd->params.dgid[0],
&dgid_addr._sockaddr_in.sin_addr.s_addr, 4);
memcpy(&cmd->params.sgid[0],
--
2.21.0
^ permalink raw reply related
* Re: Annoying gcc / rdma / networking warnings
From: Jason Gunthorpe @ 2019-05-13 18:30 UTC (permalink / raw)
To: David Miller, g@mellanox.com
Cc: torvalds@linux-foundation.org, dledford@redhat.com,
linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <20190512.201701.1918995863082655897.davem@davemloft.net>
On Sun, May 12, 2019 at 08:17:01PM -0700, David Miller wrote:
> From: Jason Gunthorpe <jgg@mellanox.com>
> Date: Mon, 13 May 2019 01:11:42 +0000
>
> > I think the specific sockaddr types should only ever be used if we
> > *know* the sa_family is that type. If the sa_family is not known then
> > it should be sockaddr or sockaddr_storage. Otherwise things get very
> > confusing.
> >
> > When using sockaddr_storage code always has the cast to sockaddr
> > anyhow, as it is not a union, so this jaunty cast is not out of place
> > in sockets code.
>
> From what I can see, each and every call side of these helpers like
> rdma_gid2ip() et al. redefine this union type over and over and over
> again in the local function.
Yes, the repeated union is very ugly and could be consolidated - or
should just use sockaddr_storage in the first place.
> It seems that if we just defined it explicitly in one place, like
> include/rdma/ib_addr.h, then we could have tdma_gid2ip(), addr_resolve(),
> and rdma_resolve_ip() take that type explcitily.
I pulled on this thread for a while and the number of places that
would need to convert to use a global 'union rdma_sockaddr_inet'
started to become pretty silly and weird. I eventually reached a point
where I had to cast a sockaddr * to the union - which is something
that makes no sense and I gave up.
So, I think this feels simpler to follow the usual sockaddr_storage
pattern and only use the union to declare the initial storage. Then
everything else just uses the sockaddr * plus casts..
Jason
^ permalink raw reply
* Re: Annoying gcc / rdma / networking warnings
From: David Miller @ 2019-05-13 3:17 UTC (permalink / raw)
To: jgg; +Cc: torvalds, dledford, linux-rdma, linux-kernel, netdev
In-Reply-To: <20190513011131.GA7948@mellanox.com>
From: Jason Gunthorpe <jgg@mellanox.com>
Date: Mon, 13 May 2019 01:11:42 +0000
> I think the specific sockaddr types should only ever be used if we
> *know* the sa_family is that type. If the sa_family is not known then
> it should be sockaddr or sockaddr_storage. Otherwise things get very
> confusing.
>
> When using sockaddr_storage code always has the cast to sockaddr
> anyhow, as it is not a union, so this jaunty cast is not out of place
> in sockets code.
>From what I can see, each and every call side of these helpers like
rdma_gid2ip() et al. redefine this union type over and over and over
again in the local function.
That's the real problem.
It seems that if we just defined it explicitly in one place, like
include/rdma/ib_addr.h, then we could have tdma_gid2ip(), addr_resolve(),
and rdma_resolve_ip() take that type explcitily.
No?
^ permalink raw reply
* Re: Annoying gcc / rdma / networking warnings
From: Jason Gunthorpe @ 2019-05-13 1:11 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Miller, Doug Ledford, linux-rdma, Linux List Kernel Mailing,
Netdev
In-Reply-To: <CAHk-=whbuwm5FbkPSfftZ3oHMWw43ZNFXqvW1b6KFMEj5wBipA@mail.gmail.com>
On Sat, May 11, 2019 at 12:52:06PM -0400, Linus Torvalds wrote:
> Jason and Davem,
> with gcc-9, I'm now seeing a number of annoying warnings from the
> rdma layer. I think it depends on the exact gcc version, because I'm
> seeing them on my laptop but didn't see them on my desktop, probably
> due to updating at different times.
I can see them too on a latest FC30 compiler.. It is pretty amazing
FC30 shipped this month with a compiler that was just released 10 days
ago. :)
Also a lot of of 'taking address of a packed member' warnings in RDMA
code for structs that probably should be aligned(4) not packed. I'll
have to look at those more carefully this week and see what can be
done.
> So if you look at the types like gcc does, then the rdma layer really
> is passing a pointer to a 16-byte sockaddr, and then filling it with
> (much bigger) sockaddr_ip6 data.
It looks like gcc is assuming that since we started with the _sockaddr
union member that the memory is actually bounded to that specific
member. This doesn't seem unreasonable and matches a lot of uses of
unions. However I wonder how that sort of analysis is going to work in
the kernel, considering our container_of idiom breaks it in the same
way, but maybe that is special case'd..
So if we tell gcc the sockaddr memory is actually the whole union then
it becomes happy, see below.
> So David, arguably the kernel "struct sockaddr" is simply wrong, if it
> can't contain a "struct sockaddr_in6". No? Is extending it a huge
> problem for other users that don't need it (mainly stack, I assume..)?
We have sockaddr_storage for this, and arguably this code is just
over-optimizing to save a few bytes of stack vs sockaddr_storage..
> Also equally arguably, the rdma code could just use a "struct
> sockaddr_in6 for this use and avoid the gcc issue, couldn't it?
I think the specific sockaddr types should only ever be used if we
*know* the sa_family is that type. If the sa_family is not known then
it should be sockaddr or sockaddr_storage. Otherwise things get very
confusing.
When using sockaddr_storage code always has the cast to sockaddr
anyhow, as it is not a union, so this jaunty cast is not out of place
in sockets code.
Below silences the warning, and the warning continues to work in other
cases, ie if I remove _sockaddr_in6 from the union I do get compile
warnings about out of bound references.
Jason
>From 38a4d7e4644a13378c11381feb3936aa1faf9f58 Mon Sep 17 00:00:00 2001
From: Jason Gunthorpe <jgg@mellanox.com>
Date: Sun, 12 May 2019 21:57:57 -0300
Subject: [PATCH] RDMA: Directly cast the sockaddr union to sockaddr
gcc 9 now does allocation size tracking and thinks that passing the member
of a union and then accessing beyond that member's bounds is an overflow.
Instead of using the union member, use the entire union with a cast to
get to the sockaddr. gcc will now know that the memory extends the full
size of the union.
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
---
drivers/infiniband/core/addr.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/infiniband/core/addr.c b/drivers/infiniband/core/addr.c
index 0dce94e3c49561..d0b04b0d309fa6 100644
--- a/drivers/infiniband/core/addr.c
+++ b/drivers/infiniband/core/addr.c
@@ -730,8 +730,8 @@ int roce_resolve_route_from_path(struct sa_path_rec *rec,
if (rec->roce.route_resolved)
return 0;
- rdma_gid2ip(&sgid._sockaddr, &rec->sgid);
- rdma_gid2ip(&dgid._sockaddr, &rec->dgid);
+ rdma_gid2ip((struct sockaddr *)&sgid, &rec->sgid);
+ rdma_gid2ip((struct sockaddr *)&dgid, &rec->dgid);
if (sgid._sockaddr.sa_family != dgid._sockaddr.sa_family)
return -EINVAL;
@@ -742,7 +742,7 @@ int roce_resolve_route_from_path(struct sa_path_rec *rec,
dev_addr.net = &init_net;
dev_addr.sgid_attr = attr;
- ret = addr_resolve(&sgid._sockaddr, &dgid._sockaddr,
+ ret = addr_resolve((struct sockaddr *)&sgid, (struct sockaddr *)&dgid,
&dev_addr, false, true, 0);
if (ret)
return ret;
@@ -814,22 +814,22 @@ int rdma_addr_find_l2_eth_by_grh(const union ib_gid *sgid,
struct rdma_dev_addr dev_addr;
struct resolve_cb_context ctx;
union {
- struct sockaddr _sockaddr;
struct sockaddr_in _sockaddr_in;
struct sockaddr_in6 _sockaddr_in6;
} sgid_addr, dgid_addr;
int ret;
- rdma_gid2ip(&sgid_addr._sockaddr, sgid);
- rdma_gid2ip(&dgid_addr._sockaddr, dgid);
+ rdma_gid2ip((struct sockaddr *)&sgid_addr, sgid);
+ rdma_gid2ip((struct sockaddr *)&dgid_addr, dgid);
memset(&dev_addr, 0, sizeof(dev_addr));
dev_addr.net = &init_net;
dev_addr.sgid_attr = sgid_attr;
init_completion(&ctx.comp);
- ret = rdma_resolve_ip(&sgid_addr._sockaddr, &dgid_addr._sockaddr,
- &dev_addr, 1000, resolve_cb, true, &ctx);
+ ret = rdma_resolve_ip((struct sockaddr *)&sgid_addr,
+ (struct sockaddr *)&dgid_addr, &dev_addr, 1000,
+ resolve_cb, true, &ctx);
if (ret)
return ret;
--
2.21.0
^ permalink raw reply related
* Re: Annoying gcc / rdma / networking warnings
From: Sowmini Varadhan @ 2019-05-11 20:02 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jason Gunthorpe, David Miller, Doug Ledford, linux-rdma,
Linux List Kernel Mailing, Netdev
In-Reply-To: <CAHk-=whbuwm5FbkPSfftZ3oHMWw43ZNFXqvW1b6KFMEj5wBipA@mail.gmail.com>
On (05/11/19 12:52), Linus Torvalds wrote:
>
> So David, arguably the kernel "struct sockaddr" is simply wrong, if it
> can't contain a "struct sockaddr_in6". No? Is extending it a huge
> problem for other users that don't need it (mainly stack, I assume..)?
The ipv6 working group came up with sockaddr_storage to solve this.
See RFC 2553. However, in practice, since sizeof(struct sockaddr_storage)
is much larger than simply creating a union of sockaddr_in and sockaaddr_in6,
most userspace networking applications will do the latter.
The strucut sockaddr is the mereely the generic pointer cast
that is expected to be used for the common posix fucntions like
bind/connect etc.
> Also equally arguably, the rdma code could just use a "struct
> sockaddr_in6 for this use and avoid the gcc issue, couldn't it? It has
Yes, that would be the right solution.
--Sowmini
^ permalink raw reply
* Annoying gcc / rdma / networking warnings
From: Linus Torvalds @ 2019-05-11 16:52 UTC (permalink / raw)
To: Jason Gunthorpe, David Miller
Cc: Doug Ledford, linux-rdma, Linux List Kernel Mailing, Netdev
Jason and Davem,
with gcc-9, I'm now seeing a number of annoying warnings from the
rdma layer. I think it depends on the exact gcc version, because I'm
seeing them on my laptop but didn't see them on my desktop, probably
due to updating at different times.
The warning is because gcc now looks at pointer types for some
allocation sizes, and will do things like this:
In function ‘memset’,
inlined from ‘rdma_gid2ip’ at ./include/rdma/ib_addr.h:168:3,
inlined from ‘roce_resolve_route_from_path’ at
drivers/infiniband/core/addr.c:735:2:
./include/linux/string.h:344:9: warning: ‘__builtin_memset’ offset
[17, 28] from the object at ‘dgid’ is out of the bounds of referenced
subobject ‘_sockaddr’ with type ‘struct sockaddr’ at offset 0
[-Warray-bounds]
344 | return __builtin_memset(p, c, size);
because the "memset()" is done onto a "sockaddr_in6" (where it's not
out of bounds), but the rdma_gid2ip() function was passed a "sockaddr"
type (where it *is* out of bounds.
All the cases I found actually have good *allocations* for the
underlying storage, using a union of the different sockaddr types, and
includes a "sockaddr_in6". So the warning actually looks bogus from an
actual allocation standpoint, but at the same time, I think the
warning does show a real issue in the networking code.
In particular, a "struct sockaddr" is supposed to be a valid superset
of the different sockaddr types, and the rdma use is in that sense the
rdma use of "struct sockaddr *" is entirely sane.
BUT.
The Linux kernel sockaddr is actually just 16 bytes. While a
sockaddr_int is about twice that.
So if you look at the types like gcc does, then the rdma layer really
is passing a pointer to a 16-byte sockaddr, and then filling it with
(much bigger) sockaddr_ip6 data.
Arguably gcc is being stupid, and it should look at the actual
allocation, but that's not what it does. And I do think what gcc does
is at least understandable.
So David, arguably the kernel "struct sockaddr" is simply wrong, if it
can't contain a "struct sockaddr_in6". No? Is extending it a huge
problem for other users that don't need it (mainly stack, I assume..)?
Also equally arguably, the rdma code could just use a "struct
sockaddr_in6 for this use and avoid the gcc issue, couldn't it? It has
the type right there, and rdma_gid2ip() could just take that type
instead, since that's what it actually then uses anyway.
Comments?
Linus
^ permalink raw reply
* Re: [RFC v1 01/19] net/i40e: Add peer register/unregister to struct i40e_netdev_priv
From: Jason Gunthorpe @ 2019-05-10 18:17 UTC (permalink / raw)
To: Shiraz Saleem
Cc: Kirsher, Jeffrey T, Ertman, David M, dledford@redhat.com,
davem@davemloft.net, linux-rdma@vger.kernel.org,
netdev@vger.kernel.org, Ismail, Mustafa, Patil, Kiran
In-Reply-To: <20190510133102.GA13780@ssaleem-MOBL4.amr.corp.intel.com>
On Fri, May 10, 2019 at 08:31:02AM -0500, Shiraz Saleem wrote:
> On Wed, Mar 13, 2019 at 07:28:41AM -0600, Jason Gunthorpe wrote:
> >
> > > > Register a device driver to the driver core and wait for the driver
> > > > core to call that driver's probe method.
> > >
> > > Yes, the LAN PF driver is the software component exposing and managing the
> > > bus, so it is the one who will call probe/remove of the peer driver (RDMA
> > > driver). Although netdev notifiers based approach is needed if the RDMA
> > > driver was loaded first before the LAN PF driver (i40e or ice) is loaded.
> >
> > Why would notifiers be needed? Driver core handles all these ordering
> > things. If you have a device_driver with no device it waits until a
> > device gets plugged in to call probe.
> >
>
> Hi Jason - Your feedback here is much appreciated and we have revisited our design based on it.
> The platform driver/device model is a good fit for us with the addition of RDMA capable devices
> to the virtual platform bus. Here are the highlights of design and how they address your concerns.
>
> (1) irdma driver registers itself as a platform driver with its own probe()/remove() routines.
> It will support RDMA capable platform devices from different Intel HW generations.
> (2) The intel net driver will register RDMA capable devices on the platform bus.
> (3) Exposing a virtual bus type in the netdev driver is redundant and thus removed.
> Additionally, it would require the bus object to be exported in order for irdma to register,
> which doesnt allow irdma to be unified.
> (4) In irdma bus probe(), we are able to reach each platform dev's associated net-specific
> data including the netdev.
> (5) There are no ordering dependencies between net-driver and irdma since it's managed by driver
> core as you stated. Listening to netdev notifiers for attachment is no longer required and
> thus removed.
This sounds a bount right, but you will want to run these details by
Greg KH. I think he will tell you to use the multi-function device
stuff, not a platform device.
Jason
^ permalink raw reply
* Re: [RFC v1 01/19] net/i40e: Add peer register/unregister to struct i40e_netdev_priv
From: Shiraz Saleem @ 2019-05-10 13:31 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Kirsher, Jeffrey T, Ertman, David M, dledford@redhat.com,
davem@davemloft.net, linux-rdma@vger.kernel.org,
netdev@vger.kernel.org, Ismail, Mustafa, Patil, Kiran
In-Reply-To: <20190313132841.GI20037@ziepe.ca>
On Wed, Mar 13, 2019 at 07:28:41AM -0600, Jason Gunthorpe wrote:
>
> > > Register a device driver to the driver core and wait for the driver
> > > core to call that driver's probe method.
> >
> > Yes, the LAN PF driver is the software component exposing and managing the
> > bus, so it is the one who will call probe/remove of the peer driver (RDMA
> > driver). Although netdev notifiers based approach is needed if the RDMA
> > driver was loaded first before the LAN PF driver (i40e or ice) is loaded.
>
> Why would notifiers be needed? Driver core handles all these ordering
> things. If you have a device_driver with no device it waits until a
> device gets plugged in to call probe.
>
Hi Jason - Your feedback here is much appreciated and we have revisited our design based on it.
The platform driver/device model is a good fit for us with the addition of RDMA capable devices
to the virtual platform bus. Here are the highlights of design and how they address your concerns.
(1) irdma driver registers itself as a platform driver with its own probe()/remove() routines.
It will support RDMA capable platform devices from different Intel HW generations.
(2) The intel net driver will register RDMA capable devices on the platform bus.
(3) Exposing a virtual bus type in the netdev driver is redundant and thus removed.
Additionally, it would require the bus object to be exported in order for irdma to register,
which doesnt allow irdma to be unified.
(4) In irdma bus probe(), we are able to reach each platform dev's associated net-specific
data including the netdev.
(5) There are no ordering dependencies between net-driver and irdma since it's managed by driver
core as you stated. Listening to netdev notifiers for attachment is no longer required and
thus removed.
We did a proof-of-concept of this revised design with 'irdma' and 'ice'.
The last 2 commits on github contain the specific changes to the 2 drivers to migrate to the new model.
https://github.com/shirazsaleem/linux-rdma/commits/poc-irdma-platform-driver
eba0979 ("RDMA/irdma: Register irdma as a platform driver")
32a7dea ("ice: Register RDMA peer devices to the virtual platform bus")
Thoughts?
Shiraz
^ permalink raw reply
* Re: [PATCH 5/5] IB/hfi1: Fix improper uses of smp_mb__before_atomic()
From: Andrea Parri @ 2019-05-09 21:12 UTC (permalink / raw)
To: Ruhl, Michael J
Cc: linux-kernel@vger.kernel.org, Dalessandro, Dennis,
Marciniszyn, Mike, Doug Ledford, Jason Gunthorpe,
linux-rdma@vger.kernel.org, Paul E. McKenney, Peter Zijlstra
In-Reply-To: <20190429231657.GA2733@andrea>
On Tue, Apr 30, 2019 at 01:16:57AM +0200, Andrea Parri wrote:
> Hi Mike,
>
> > >This barrier only applies to the read-modify-write operations; in
> > >particular, it does not apply to the atomic_read() primitive.
> > >
> > >Replace the barrier with an smp_mb().
> >
> > This is one of a couple of barrier issues that we are currently looking into.
> >
> > See:
> >
> > [PATCH for-next 6/9] IB/rdmavt: Add new completion inline
> >
> > We will take a look at this one as well.
>
> Thank you for the reference and for looking into this,
So, I'm planning to just drop this patch; or can I do something to help?
Please let me know.
Thanx,
Andrea
>
> Andrea
^ permalink raw reply
* Re: [RFC PATCH 0/5] cgroup support for GPU devices
From: Tejun Heo @ 2019-05-09 16:52 UTC (permalink / raw)
To: Welty, Brian
Cc: Leon Romanovsky, David Airlie, kenny.ho, intel-gfx, dri-devel,
Michal Hocko, linux-mm, Jérôme Glisse, Li Zefan,
Vladimir Davydov, Johannes Weiner, cgroups, Christian König,
RDMA mailing list
In-Reply-To: <cf58b047-d678-ad89-c9b6-96fc6b01c1d7@intel.com>
Hello,
On Tue, May 07, 2019 at 12:50:50PM -0700, Welty, Brian wrote:
> There might still be merit in having a 'device mem' cgroup controller.
> The resource model at least is then no longer mixed up with host memory.
> RDMA community seemed to have some interest in a common controller at
> least for device memory aspects.
> Thoughts on this? I believe could still reuse the 'struct mem_cgroup' data
> structure. There should be some opportunity to reuse charging APIs and
> have some nice integration with HMM for charging to device memory, depending
> on backing store.
Library-ish sharing is fine but in terms of interface, I think it'd be
better to keep them separate at least for now. Down the line maybe
these resources will interact with each other in a more integrated way
but I don't think it's a good idea to try to design and implement
resource models for something like that preemptively.
Thanks.
--
tejun
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [GIT PULL] Please pull RDMA subsystem changes
From: pr-tracker-bot @ 2019-05-09 16:25 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Linus Torvalds, Doug Ledford, linux-rdma@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20190509133711.GA16703@ziepe.ca>
The pull request you sent on Thu, 9 May 2019 13:37:23 +0000:
> git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/dce45af5c2e9e85f22578f2f8065f225f5d11764
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* [GIT PULL] Please pull RDMA subsystem changes
From: Jason Gunthorpe @ 2019-05-09 13:37 UTC (permalink / raw)
To: Linus Torvalds, Doug Ledford
Cc: linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 30454 bytes --]
Hi Linus,
These are the proposed RDMA patches for 5.2.
There is a small conflict with the mlx5-next (net-next) tree resolved with
this hunk:
diff --cc drivers/infiniband/hw/mlx5/main.c
index 687f99172037be,fae6a6a1fbea12..abac70ad5c7c46
--- a/drivers/infiniband/hw/mlx5/main.c
+++ b/drivers/infiniband/hw/mlx5/main.c
@@@ -200,12 -172,18 +200,12 @@@ static int mlx5_netdev_event(struct not
switch (event) {
case NETDEV_REGISTER:
+ /* Should already be registered during the load */
+ if (ibdev->is_rep)
+ break;
write_lock(&roce->netdev_lock);
- if (ndev->dev.parent == &mdev->pdev->dev)
- if (ibdev->rep) {
- struct mlx5_eswitch *esw = ibdev->mdev->priv.eswitch;
- struct net_device *rep_ndev;
-
- rep_ndev = mlx5_ib_get_rep_netdev(esw,
- ibdev->rep->vport);
- if (rep_ndev == ndev)
- roce->netdev = ndev;
- } else if (ndev->dev.parent == mdev->device) {
++ if (ndev->dev.parent == mdev->device)
roce->netdev = ndev;
- }
write_unlock(&roce->netdev_lock);
break;
I also have some notifications from StephenR about minor conflicts with
patches in akpm's tree that you haven't merged yet. Here are his resolutions:
https://lore.kernel.org/lkml/20190509153805.6dfbb8ef@canb.auug.org.au/
https://lore.kernel.org/lkml/20190506204824.11a7b368@canb.auug.org.au/
https://lore.kernel.org/lkml/20190506203710.10b080dc@canb.auug.org.au/
The tag for-linus-merged with my merge resolution for the mlx5-next
branch is also available to pull.
The following changes since commit 96780e4f46b2fc0fc5ae2b95957002e2c42b11d3:
net/mlx5: Introduce new TIR creation core API (2019-04-24 12:33:37 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus
for you to fetch changes up to b79656ed44c6865e17bcd93472ec39488bcc4984:
RDMA/ipoib: Allow user space differentiate between valid dev_port (2019-05-07 16:13:23 -0300)
----------------------------------------------------------------
5.2 Merge Window pull request
This has been a smaller cycle than normal. One new driver was accepted,
which is unusual, and at least one more driver remains in review on the
list.
- Driver fixes for hns, hfi1, nes, rxe, i40iw, mlx5, cxgb4, vmw_pvrdma
- Many patches from MatthewW converting radix tree and IDR users to use
xarray
- Introduction of tracepoints to the MAD layer
- Build large SGLs at the start for DMA mapping and get the driver to
split them
- Generally clean SGL handling code throughout the subsystem
- Support for restricting RDMA devices to net namespaces for containers
- Progress to remove object allocation boilerplate code from drivers
- Change in how the mlx5 driver shows representor ports linked to VFs
- mlx5 uapi feature to access the on chip SW ICM memory
- Add a new driver for 'EFA'. This is HW that supports user space packet
processing through QPs in Amazon's cloud
----------------------------------------------------------------
Ariel Levkovich (5):
IB/mlx5: Expose TIR ICM address to user space
IB/mlx5: Support device memory type attribute
IB/mlx5: Warn on allocated MEMIC buffers during cleanup
IB/mlx5: Add steering SW ICM device memory type
IB/mlx5: Device resource control for privileged DEVX user
Artemy Kovalyov (3):
IB/mlx5: WQE dump jumps over first 16 bytes
IB/mlx5: Compare only index part of a memory window rkey
IB/core: Set qp->real_qp before it may be accessed
Bart Van Assche (6):
RDMA/uverbs: Add a __user annotation to a pointer
RDMA/uverbs: Annotate uverbs_request_next_ptr() return value as a __user pointer
RDMA/uverbs: Allow the compiler to verify declaration and definition consistency
IB/mlx5: Declare devx_async_cmd_event_fops static
IB/hfi1: Fix two format strings
IB/qib: Remove a set-but-not-used variable
Chengguang Xu (1):
infiniband/qib: Fix typo in comment
Colin Ian King (6):
RDMA/nes: remove redundant check on udata
IB/iser: remove uninitialized variable len
opa_vnic: fix check on record->event, incorrect operator used
RDMA/mlx5: Check for error return in flow_rule rather than err
RDMA/cxgb4: Fix null pointer dereference on alloc_skb failure
RDMA/cxgb4: Fix spelling mistake "immedate" -> "immediate"
Dennis Dalessandro (1):
IB/core, ipoib: Do not overreact to SM LID change event
Devesh Sharma (1):
RDMA/ocrdma: Remove use of idr use pci bdf instead
Enrico Weigelt, metux IT consult (1):
drivers: infiniband: Fix whitespace in kconfig
Erez Alfasi (1):
RDMA: Use __packed annotation instead of __attribute__ ((packed))
Gal Pressman (14):
RDMA/core: Introduce RDMA subsystem ibdev_* print functions
RDMA/uverbs: Initialize udata struct on destroy flows
RDMA: Add EFA related definitions
RDMA/efa: Add EFA device definitions
RDMA/efa: Add the efa.h header file
RDMA/efa: Add the efa_com.h file
RDMA/efa: Add the com service API definitions
RDMA/efa: Add the ABI definitions
RDMA/efa: Implement functions that submit and complete admin commands
RDMA/efa: Add common command handlers
RDMA/efa: Add EFA verbs implementation
RDMA/efa: Add the efa module
RDMA/efa: Add driver to Kconfig/Makefile
lib/scatterlist: Remove leftover from sg_page_iter comment
Ira Weiny (7):
IB/core: Ensure an invalidate_range callback on ODP MR
IB/MAD: Add send path trace points
IB/MAD: Add recv path trace point
IB/MAD: Add agent trace points
IB/UMAD: Add umad trace points
IB/MAD: Add SMP details to MAD tracing
BPF: Add sample code for new ib_umad tracepoint
Jack Morgenstein (1):
IB/mlx5: Add missing XRC options to QP optional params mask
Jason Gunthorpe (9):
Merge HFI1 updates into k.o/for-next
IB/mlx5: Remove references to uboject->context
IB: When attrs.udata/ufile is available use that instead of uobject
RDMA/drivers: Convert easy drivers to use ib_device_set_netdev()
Merge branch 'mlx5-next' into rdma.git for-next
RDMA/mlx5: Use get_zeroed_page() for clock_info
RDMA: Remove rdma_user_mmap_page
Merge branch 'rdma_mmap' into rdma.git for-next
Merge branch 'mlx5_tir_icm' into rdma.git for-next
John Fleck (1):
IB/hfi1: Remove reference to RHF.VCRCErr
Josh Collier (1):
IB/hfi1: Add debugfs to control expansion ROM write protect
Kaike Wan (6):
IB/hfi1: Delay the release of destination mr for TID RDMA WRITE DATA
IB/hfi1: Add a function to read next expected psn from hardware flow
IB/hfi1: Unify the software PSN check for TID RDMA READ/WRITE
IB/hfi1: Remove WARN_ON when freeing expected receive groups
IB/hfi1: Implement CCA for TID RDMA protocol
IB/{rdmavt, hfi1): Miscellaneous comment fixes
Kamal Heib (1):
RDMA: Get rid of iw_cm_verbs
Kangjie Lu (1):
RDMA/i40iw: Handle workqueue allocation failure
Leon Romanovsky (19):
RDMA/rxe: Fix slab-out-bounds access which lead to kernel crash later
overflow: Fix -Wtype-limits compilation warnings
RDMA/hns: Limit scope of hns_roce_cmq_send()
RDMA/netlink: Remove unused data structure
RDMA/core: Don't compare specific bit after boolean AND
RDMA/hns: Fix bad endianess of port_pd variable
RDMA/cma: Set proper port number as index
RDMA/mlx5: Cleanup WQE page fault handler
RDMA/cm: Remove useless zeroing of static global variable
RDMA/cm: Move debug counters to be under relevant IB device
RDMA/nldev: Return device protocol
RDMA/core: Support object allocation in atomic context
RDMA: Handle AH allocations by IB/core
RDMA: Handle SRQ allocations by IB/core
RDMA/hns: Remove asynchronic QP destroy
RDMA/rdmavt: Catch use-after-free access of AH structures
RDMA/mlx5: Remove MAYEXEC flag
RDMA/device: Don't fire uevent before device is fully initialized
RDMA/ipoib: Allow user space differentiate between valid dev_port
Lijun Ou (8):
RDMA/hns: Only assign the relatived fields of psn if IB_QP_SQ_PSN is set
RDMA/hns: Only assign the fields of the rq psn if IB_QP_RQ_PSN is set
RDMA/hns: Update the range of raq_psn field of qp context
RDMA/hns: Only assgin some fields if the relatived attr_mask is set
RDMA/hns: Hide error print information with roce vf device
RDMA/hns: Bugfix for sending with invalidate
RDMA/hns: Delete unused variable in hns_roce_v2_modify_qp function
RDMA/hns: Dump detailed driver-specific CQ
Maor Gottlieb (1):
RDMA/mlx5: Add query e-switch vport context to devx white list
Mark Bloch (16):
RDMA/mlx5: Move netdev info into the port struct
RDMA/mlx5: Free IB device on remove
RDMA/mlx5: Move ports allocation to outside of INIT stage
RDMA/mlx5: Use correct size for device resources
RDMA/mlx5: Move rep into port struct
RDMA/mlx5: Move default representors SQ steering to rule to modify QP
RDMA/mlx5: Refactor netdev affinity code
RDMA/mlx5: Move SMI caps logic
RDMA/mlx5: Move to single device multiport ports in switchdev mode
RDMA/mlx5: Remove VF representor profile
RDMA/mlx5: Access the prio bypass inside the FDB flow table namespace
RDMA/mlx5: Create flow table with max size supported
RDMA/mlx5: Allow inserting a steering rule to the FDB
RDMA/mlx5: Allow DEVX and raw creation flow on reps
RDMA/mlx5: Initialize roce port info before multiport master init
RDMA/mlx5: Don't create IB representors when in multiport RoCE mode
Matthew Wilcox (26):
cxgb3: Convert cqidr to XArray
cxgb3: Convert qpidr to XArray
cxgb3: Convert mmidr to XArray
cxgb4: Convert cqidr to XArray
cxgb4: Convert qpidr to XArray
cxgb4: Convert mmidr to XArray
cxgb4: Convert hwtid_idr to XArray
cxgb4: Convert atid_idr to XArray
cxgb4: Convert stid_idr to XArray
mlx5: Convert mlx5_srq_table to XArray
mlx4: Convert pv_id_table to XArray
IB/mad: Convert ib_mad_clients to XArray
RDMA/cm: Convert local_id_table to XArray
ib core: Convert query_idr to XArray
ucm: Convert ctx_id_table to XArray
cma: Convert portspace IDRs to XArray
RDMA/hns: Convert cq_table to XArray
RDMA/hns: Convert qp_table_tree to XArray
hfi1: Convert vesw_idr to XArray
qedr: Convert qpidr to XArray
qedr: Convert srqidr to XArray
hfi1: Convert hfi1_unit_table to XArray
qib: Convert qib_unit_table to XArray
opa_vnic: Convert vport_idr to XArray
ib/bnxt: Remove mention of idr_alloc from comment
uverbs: Convert idr to XArray
Mike Marciniszyn (7):
IB/hfi1: Add running average for adaptive pio
IB/hfi1: Make opfn.h self sufficient
IB/rdmavt: Fix ab/ba include issues
IB/rdmavt: Use more efficient allowed_ops
IB/{rdmavt, qib, hfi1}: Use new routine to release reference counts
IB/hfi1: Add selected Rcv counters
IB/hfi1: Fix WQ_MEM_RECLAIM warning
Parav Pandit (22):
RDMA/core: Introduce ib_core_device to hold device
RDMA/core: Restrict sysfs entries view to init_net
RDMA/core: Implement compat device/sysfs tree in net namespace
RDMA/core: Support core port attributes in non init_net
RDMA/core: Add module param to disable device sharing among net ns
RDMA: Check net namespace access for uverbs, umad, cma and nldev
RDMA/core: Extend ib_device_get_by_index for net namespace
RDMA/core: Add interface to read device namespace sharing mode
RDMA/core: Add command to set ib_core device net namspace sharing mode
RDMA/core: Avoid freeing netdevs in disable_device()
RDMA/core: Introduce a helper function to change net namespace of rdma device
RDMA/core: Add a netlink command to change net namespace of rdma device
IB/core: Allow vlan link local address based RoCE GIDs
RDMA/cma: Consider scope_id while binding to ipv6 ll address
RDMA/core: Do not invoke init_port on compat devices
RDMA/rxe: Consider skb reserve space based on netdev of GID
IB/cm: Reduce dependency on gid attribute ndev check
RDMA: Introduce and use GID attr helper to read RoCE L2 fields
RDMA/cma: Use rdma_read_gid_attr_ndev_rcu to access netdev
RDMA/rxe: Use rdma_read_gid_attr_ndev_rcu to access netdev
net/smc: Use rdma_read_gid_l2_fields to L2 fields
RDMA/core: Allow detaching gid attribute netdevice for RoCE
Potnuri Bharat Teja (2):
iw_cxgb4: Update Maintainer details
RDMA/iw_cxgb4: Always disconnect when QP is transitioning to TERMINATE state
Selvin Xavier (1):
RDMA/bnxt_re: Use correct sizing on buffers holding page DMA addresses
Shamir Rabinovitch (6):
IB: ucontext should be set properly for all cmd & ioctl paths
IB: Pass uverbs_attr_bundle down uobject destroy path
IB: Pass uverbs_attr_bundle down ib_x destroy path
IB: Remove 'uobject->context' dependency in object destroy APIs
IB: Pass only ib_udata in function prototypes
RDMA/uverbs: Initialize uverbs_attr_bundle ucontext in ib_uverbs_get_context
Shiraz Saleem (12):
RDMA/cxbg: Use correct sizing on buffers holding page DMA addresses
RDMA/mthca: Use correct sizing on buffers holding page DMA addresses
RDMA/rxe: Use correct sizing on buffers holding page DMA addresses
RDMA/rdmavt: Use correct sizing on buffers holding page DMA addresses
RDMA/umem: Combine contiguous PAGE_SIZE regions in SGEs
RDMA/umem: Use correct value for SG entries in sg_copy_to_buffer()
RDMA/umem: Handle page combining avoidance correctly in ib_umem_add_sg_table()
RDMA/umem: Add API to find best driver supported page size in an MR
RDMA/verbs: Add a DMA iterator to return aligned contiguous memory blocks
RDMA/i40iw: Use core helpers to get aligned DMA address within a supported page size
RDMA/bnxt_re: Use core helpers to get aligned DMA address
RDMA/umem: Remove hugetlb flag
Steve Wise (1):
RDMA/cxgb4: Use ib_device_set_netdev()
Yuval Shaia (1):
RDMA/vmw_pvrdma: Skip zeroing device attrs
Zhu Yanjun (1):
IB/rxe: Replace av->network_type with skb->protocol
chenglang (1):
RDMA/hns: Support to create 1M srq queue
MAINTAINERS | 17 +-
drivers/infiniband/Kconfig | 1 +
drivers/infiniband/core/addr.c | 1 +
drivers/infiniband/core/cache.c | 145 +-
drivers/infiniband/core/cm.c | 94 +-
drivers/infiniband/core/cm_msgs.h | 22 +-
drivers/infiniband/core/cma.c | 83 +-
drivers/infiniband/core/core_priv.h | 18 +-
drivers/infiniband/core/cq.c | 21 +-
drivers/infiniband/core/device.c | 632 ++++++-
drivers/infiniband/core/iwcm.c | 35 +-
drivers/infiniband/core/mad.c | 87 +-
drivers/infiniband/core/mad_priv.h | 4 +-
drivers/infiniband/core/multicast.c | 1 -
drivers/infiniband/core/nldev.c | 112 +-
drivers/infiniband/core/rdma_core.c | 200 +--
drivers/infiniband/core/rdma_core.h | 11 +-
drivers/infiniband/core/sa_query.c | 44 +-
drivers/infiniband/core/sysfs.c | 93 +-
drivers/infiniband/core/ucm.c | 35 +-
drivers/infiniband/core/umem.c | 179 +-
drivers/infiniband/core/umem_odp.c | 20 +-
drivers/infiniband/core/user_mad.c | 22 +
drivers/infiniband/core/uverbs.h | 7 +-
drivers/infiniband/core/uverbs_cmd.c | 99 +-
drivers/infiniband/core/uverbs_ioctl.c | 29 +-
drivers/infiniband/core/uverbs_main.c | 69 +-
drivers/infiniband/core/uverbs_std_types.c | 52 +-
.../infiniband/core/uverbs_std_types_counters.c | 6 +-
drivers/infiniband/core/uverbs_std_types_cq.c | 12 +-
drivers/infiniband/core/uverbs_std_types_dm.c | 10 +-
.../infiniband/core/uverbs_std_types_flow_action.c | 6 +-
drivers/infiniband/core/uverbs_std_types_mr.c | 9 +-
drivers/infiniband/core/verbs.c | 233 ++-
drivers/infiniband/hw/Makefile | 1 +
drivers/infiniband/hw/bnxt_re/Kconfig | 12 +-
drivers/infiniband/hw/bnxt_re/ib_verbs.c | 194 +--
drivers/infiniband/hw/bnxt_re/ib_verbs.h | 36 +-
drivers/infiniband/hw/bnxt_re/main.c | 8 +-
drivers/infiniband/hw/bnxt_re/qplib_fp.c | 39 +-
drivers/infiniband/hw/bnxt_re/qplib_fp.h | 13 +-
drivers/infiniband/hw/bnxt_re/qplib_rcfw.c | 4 +-
drivers/infiniband/hw/bnxt_re/qplib_res.c | 43 +-
drivers/infiniband/hw/bnxt_re/qplib_res.h | 8 +-
drivers/infiniband/hw/bnxt_re/qplib_sp.c | 16 +-
drivers/infiniband/hw/bnxt_re/qplib_sp.h | 4 +-
drivers/infiniband/hw/cxgb3/cxio_wr.h | 10 +-
drivers/infiniband/hw/cxgb3/iwch.c | 56 +-
drivers/infiniband/hw/cxgb3/iwch.h | 38 +-
drivers/infiniband/hw/cxgb3/iwch_ev.c | 18 +-
drivers/infiniband/hw/cxgb3/iwch_mem.c | 2 +-
drivers/infiniband/hw/cxgb3/iwch_provider.c | 97 +-
drivers/infiniband/hw/cxgb4/cm.c | 69 +-
drivers/infiniband/hw/cxgb4/cq.c | 23 +-
drivers/infiniband/hw/cxgb4/device.c | 210 +--
drivers/infiniband/hw/cxgb4/ev.c | 18 +-
drivers/infiniband/hw/cxgb4/iw_cxgb4.h | 96 +-
drivers/infiniband/hw/cxgb4/mem.c | 25 +-
drivers/infiniband/hw/cxgb4/provider.c | 77 +-
drivers/infiniband/hw/cxgb4/qp.c | 77 +-
drivers/infiniband/hw/efa/Kconfig | 15 +
drivers/infiniband/hw/efa/Makefile | 9 +
drivers/infiniband/hw/efa/efa.h | 163 ++
drivers/infiniband/hw/efa/efa_admin_cmds_defs.h | 794 +++++++++
drivers/infiniband/hw/efa/efa_admin_defs.h | 136 ++
drivers/infiniband/hw/efa/efa_com.c | 1160 +++++++++++++
drivers/infiniband/hw/efa/efa_com.h | 144 ++
drivers/infiniband/hw/efa/efa_com_cmd.c | 692 ++++++++
drivers/infiniband/hw/efa/efa_com_cmd.h | 270 +++
drivers/infiniband/hw/efa/efa_common_defs.h | 18 +
drivers/infiniband/hw/efa/efa_main.c | 533 ++++++
drivers/infiniband/hw/efa/efa_regs_defs.h | 113 ++
drivers/infiniband/hw/efa/efa_verbs.c | 1825 ++++++++++++++++++++
drivers/infiniband/hw/hfi1/chip.c | 54 +-
drivers/infiniband/hw/hfi1/chip.h | 3 +
drivers/infiniband/hw/hfi1/chip_registers.h | 3 +
drivers/infiniband/hw/hfi1/common.h | 2 +-
drivers/infiniband/hw/hfi1/debugfs.c | 82 +-
drivers/infiniband/hw/hfi1/driver.c | 19 +-
drivers/infiniband/hw/hfi1/exp_rcv.c | 3 -
drivers/infiniband/hw/hfi1/hfi.h | 8 +-
drivers/infiniband/hw/hfi1/init.c | 59 +-
drivers/infiniband/hw/hfi1/opfn.h | 6 +-
drivers/infiniband/hw/hfi1/qp.c | 2 +
drivers/infiniband/hw/hfi1/rc.c | 27 +-
drivers/infiniband/hw/hfi1/rc.h | 8 +
drivers/infiniband/hw/hfi1/ruc.c | 2 +-
drivers/infiniband/hw/hfi1/tid_rdma.c | 274 ++-
drivers/infiniband/hw/hfi1/tid_rdma.h | 2 -
drivers/infiniband/hw/hfi1/trace_dbg.h | 4 +-
drivers/infiniband/hw/hfi1/trace_tid.h | 12 +-
drivers/infiniband/hw/hfi1/verbs.c | 15 +-
drivers/infiniband/hw/hfi1/verbs.h | 1 +
drivers/infiniband/hw/hfi1/vnic_main.c | 16 +-
drivers/infiniband/hw/hns/Makefile | 4 +-
drivers/infiniband/hw/hns/hns_roce_ah.c | 36 +-
drivers/infiniband/hw/hns/hns_roce_cmd.h | 1 +
drivers/infiniband/hw/hns/hns_roce_common.h | 33 -
drivers/infiniband/hw/hns/hns_roce_cq.c | 68 +-
drivers/infiniband/hw/hns/hns_roce_device.h | 52 +-
drivers/infiniband/hw/hns/hns_roce_hw_v1.c | 396 +----
drivers/infiniband/hw/hns/hns_roce_hw_v1.h | 14 +-
drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 320 ++--
drivers/infiniband/hw/hns/hns_roce_hw_v2.h | 7 +-
drivers/infiniband/hw/hns/hns_roce_hw_v2_dfx.c | 35 +
drivers/infiniband/hw/hns/hns_roce_main.c | 35 +-
drivers/infiniband/hw/hns/hns_roce_mr.c | 6 +-
drivers/infiniband/hw/hns/hns_roce_pd.c | 7 +-
drivers/infiniband/hw/hns/hns_roce_qp.c | 50 +-
drivers/infiniband/hw/hns/hns_roce_restrack.c | 126 ++
drivers/infiniband/hw/hns/hns_roce_srq.c | 52 +-
drivers/infiniband/hw/i40iw/i40iw.h | 2 +-
drivers/infiniband/hw/i40iw/i40iw_cm.c | 21 +-
drivers/infiniband/hw/i40iw/i40iw_main.c | 5 +-
drivers/infiniband/hw/i40iw/i40iw_verbs.c | 123 +-
drivers/infiniband/hw/i40iw/i40iw_verbs.h | 3 +-
drivers/infiniband/hw/mlx4/ah.c | 103 +-
drivers/infiniband/hw/mlx4/cm.c | 36 +-
drivers/infiniband/hw/mlx4/cq.c | 40 +-
drivers/infiniband/hw/mlx4/doorbell.c | 6 +-
drivers/infiniband/hw/mlx4/mad.c | 33 +-
drivers/infiniband/hw/mlx4/main.c | 13 +-
drivers/infiniband/hw/mlx4/mlx4_ib.h | 41 +-
drivers/infiniband/hw/mlx4/mr.c | 7 +-
drivers/infiniband/hw/mlx4/qp.c | 50 +-
drivers/infiniband/hw/mlx4/srq.c | 59 +-
drivers/infiniband/hw/mlx5/ah.c | 33 +-
drivers/infiniband/hw/mlx5/cmd.c | 155 +-
drivers/infiniband/hw/mlx5/cmd.h | 8 +-
drivers/infiniband/hw/mlx5/cq.c | 47 +-
drivers/infiniband/hw/mlx5/devx.c | 32 +-
drivers/infiniband/hw/mlx5/flow.c | 99 +-
drivers/infiniband/hw/mlx5/ib_rep.c | 109 +-
drivers/infiniband/hw/mlx5/ib_rep.h | 13 +-
drivers/infiniband/hw/mlx5/main.c | 662 ++++---
drivers/infiniband/hw/mlx5/mlx5_ib.h | 118 +-
drivers/infiniband/hw/mlx5/mr.c | 52 +-
drivers/infiniband/hw/mlx5/odp.c | 132 +-
drivers/infiniband/hw/mlx5/qp.c | 161 +-
drivers/infiniband/hw/mlx5/srq.c | 76 +-
drivers/infiniband/hw/mlx5/srq.h | 7 +-
drivers/infiniband/hw/mlx5/srq_cmd.c | 35 +-
drivers/infiniband/hw/mthca/mthca_cq.c | 2 +-
drivers/infiniband/hw/mthca/mthca_eq.c | 16 +-
drivers/infiniband/hw/mthca/mthca_mr.c | 2 +-
drivers/infiniband/hw/mthca/mthca_provider.c | 179 +-
drivers/infiniband/hw/mthca/mthca_qp.c | 6 +-
drivers/infiniband/hw/nes/nes_cm.c | 3 +-
drivers/infiniband/hw/nes/nes_verbs.c | 168 +-
drivers/infiniband/hw/ocrdma/ocrdma_ah.c | 32 +-
drivers/infiniband/hw/ocrdma/ocrdma_ah.h | 6 +-
drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 18 +-
drivers/infiniband/hw/ocrdma/ocrdma_hw.h | 6 +-
drivers/infiniband/hw/ocrdma/ocrdma_main.c | 25 +-
drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 128 +-
drivers/infiniband/hw/ocrdma/ocrdma_verbs.h | 24 +-
drivers/infiniband/hw/qedr/main.c | 57 +-
drivers/infiniband/hw/qedr/qedr.h | 11 +-
drivers/infiniband/hw/qedr/qedr_iw_cm.c | 10 +-
drivers/infiniband/hw/qedr/qedr_roce_cm.c | 11 +-
drivers/infiniband/hw/qedr/verbs.c | 129 +-
drivers/infiniband/hw/qedr/verbs.h | 27 +-
drivers/infiniband/hw/qib/qib.h | 4 +-
drivers/infiniband/hw/qib/qib_common.h | 2 +-
drivers/infiniband/hw/qib/qib_driver.c | 20 +-
drivers/infiniband/hw/qib/qib_fs.c | 12 +-
drivers/infiniband/hw/qib/qib_iba7322.c | 4 +-
drivers/infiniband/hw/qib/qib_init.c | 56 +-
drivers/infiniband/hw/qib/qib_rc.c | 4 +-
drivers/infiniband/hw/qib/qib_user_sdma.c | 5 +-
drivers/infiniband/hw/qib/qib_verbs.h | 2 +-
drivers/infiniband/hw/usnic/usnic_ib_verbs.c | 15 +-
drivers/infiniband/hw/usnic/usnic_ib_verbs.h | 12 +-
drivers/infiniband/hw/usnic/usnic_uiom.c | 3 +-
drivers/infiniband/hw/usnic/usnic_uiom.h | 3 +-
drivers/infiniband/hw/vmw_pvrdma/pvrdma_cq.c | 17 +-
drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c | 28 +-
drivers/infiniband/hw/vmw_pvrdma/pvrdma_mr.c | 15 +-
drivers/infiniband/hw/vmw_pvrdma/pvrdma_qp.c | 3 +-
drivers/infiniband/hw/vmw_pvrdma/pvrdma_srq.c | 43 +-
drivers/infiniband/hw/vmw_pvrdma/pvrdma_verbs.c | 56 +-
drivers/infiniband/hw/vmw_pvrdma/pvrdma_verbs.h | 27 +-
drivers/infiniband/sw/rdmavt/ah.c | 38 +-
drivers/infiniband/sw/rdmavt/ah.h | 8 +-
drivers/infiniband/sw/rdmavt/cq.c | 7 +-
drivers/infiniband/sw/rdmavt/cq.h | 3 +-
drivers/infiniband/sw/rdmavt/mmap.c | 16 +-
drivers/infiniband/sw/rdmavt/mmap.h | 6 +-
drivers/infiniband/sw/rdmavt/mr.c | 9 +-
drivers/infiniband/sw/rdmavt/mr.h | 7 +-
drivers/infiniband/sw/rdmavt/pd.c | 7 +-
drivers/infiniband/sw/rdmavt/pd.h | 5 +-
drivers/infiniband/sw/rdmavt/qp.c | 27 +-
drivers/infiniband/sw/rdmavt/qp.h | 4 +-
drivers/infiniband/sw/rdmavt/rc.c | 2 +-
drivers/infiniband/sw/rdmavt/srq.c | 49 +-
drivers/infiniband/sw/rdmavt/srq.h | 7 +-
drivers/infiniband/sw/rdmavt/trace_qp.h | 2 +-
drivers/infiniband/sw/rdmavt/trace_rc.h | 2 +-
drivers/infiniband/sw/rdmavt/trace_tx.h | 2 +-
drivers/infiniband/sw/rdmavt/vt.c | 3 +
drivers/infiniband/sw/rxe/rxe_cq.c | 10 +-
drivers/infiniband/sw/rxe/rxe_hdr.h | 2 +-
drivers/infiniband/sw/rxe/rxe_loc.h | 16 +-
drivers/infiniband/sw/rxe/rxe_mmap.c | 14 +-
drivers/infiniband/sw/rxe/rxe_mr.c | 13 +-
drivers/infiniband/sw/rxe/rxe_net.c | 46 +-
drivers/infiniband/sw/rxe/rxe_pool.c | 4 +-
drivers/infiniband/sw/rxe/rxe_qp.c | 15 +-
drivers/infiniband/sw/rxe/rxe_queue.c | 22 +-
drivers/infiniband/sw/rxe/rxe_queue.h | 15 +-
drivers/infiniband/sw/rxe/rxe_srq.c | 14 +-
drivers/infiniband/sw/rxe/rxe_verbs.c | 90 +-
drivers/infiniband/sw/rxe/rxe_verbs.h | 4 +-
drivers/infiniband/ulp/ipoib/ipoib_main.c | 13 +-
drivers/infiniband/ulp/ipoib/ipoib_verbs.c | 3 +-
drivers/infiniband/ulp/iser/Kconfig | 4 +-
drivers/infiniband/ulp/iser/iscsi_iser.c | 7 +-
drivers/infiniband/ulp/iser/iscsi_iser.h | 2 +-
drivers/infiniband/ulp/opa_vnic/opa_vnic_vema.c | 60 +-
.../net/ethernet/mellanox/mlx5/core/lib/clock.c | 30 +-
include/linux/dynamic_debug.h | 11 +
include/linux/mlx5/driver.h | 1 -
include/linux/overflow.h | 12 +-
include/linux/scatterlist.h | 10 +-
include/rdma/ib_cache.h | 4 +
include/rdma/ib_mad.h | 4 +-
include/rdma/ib_smi.h | 2 +-
include/rdma/ib_umem.h | 12 +-
include/rdma/ib_umem_odp.h | 1 +
include/rdma/ib_verbs.h | 430 ++++-
include/rdma/iw_cm.h | 25 -
include/rdma/opa_port_info.h | 2 +-
include/rdma/opa_smi.h | 4 +-
include/rdma/rdma_vt.h | 78 +-
include/rdma/rdmavt_qp.h | 89 +-
include/rdma/uverbs_std_types.h | 42 +-
include/rdma/uverbs_types.h | 18 +-
include/trace/events/ib_mad.h | 390 +++++
include/trace/events/ib_umad.h | 126 ++
include/uapi/rdma/efa-abi.h | 101 ++
include/uapi/rdma/mlx5-abi.h | 2 +
include/uapi/rdma/mlx5_user_ioctl_cmds.h | 2 +
include/uapi/rdma/mlx5_user_ioctl_verbs.h | 7 +
include/uapi/rdma/rdma_netlink.h | 31 +-
include/uapi/rdma/rdma_user_ioctl_cmds.h | 1 +
lib/dynamic_debug.c | 37 +
net/smc/smc_ib.c | 16 +-
samples/bpf/Makefile | 3 +
samples/bpf/ibumad_kern.c | 144 ++
samples/bpf/ibumad_user.c | 122 ++
251 files changed, 12535 insertions(+), 4571 deletions(-)
(diffstat from merge'd tree)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 0/5] cgroup support for GPU devices
From: Welty, Brian @ 2019-05-07 19:50 UTC (permalink / raw)
To: Tejun Heo
Cc: Leon Romanovsky, David Airlie, kenny.ho, intel-gfx, dri-devel,
Michal Hocko, linux-mm, Jérôme Glisse, Li Zefan,
Vladimir Davydov, Johannes Weiner, cgroups, Christian König,
RDMA mailing list
In-Reply-To: <20190506152643.GL374014@devbig004.ftw2.facebook.com>
On 5/6/2019 8:26 AM, Tejun Heo wrote:
> Hello,
>
> On Wed, May 01, 2019 at 10:04:33AM -0400, Brian Welty wrote:
>> The patch series enables device drivers to use cgroups to control the
>> following resources within a GPU (or other accelerator device):
>> * control allocation of device memory (reuse of memcg)
>> and with future work, we could extend to:
>> * track and control share of GPU time (reuse of cpu/cpuacct)
>> * apply mask of allowed execution engines (reuse of cpusets)
>>
>> Instead of introducing a new cgroup subsystem for GPU devices, a new
>> framework is proposed to allow devices to register with existing cgroup
>> controllers, which creates per-device cgroup_subsys_state within the
>> cgroup. This gives device drivers their own private cgroup controls
>> (such as memory limits or other parameters) to be applied to device
>> resources instead of host system resources.
>> Device drivers (GPU or other) are then able to reuse the existing cgroup
>> controls, instead of inventing similar ones.
>
> I'm really skeptical about this approach. When creating resource
> controllers, I think what's the most important and challenging is
> establishing resource model - what resources are and how they can be
> distributed. This patchset is going the other way around - building
> out core infrastructure for bolierplates at a significant risk of
> mixing up resource models across different types of resources.
>
> IO controllers already implement per-device controls. I'd suggest
> following the same interface conventions and implementing a dedicated
> controller for the subsystem.
>
Okay, thanks for feedback. Preference is clear to see this done as
dedicated cgroup controller.
Part of my proposal was an attempt for devices with "mem like" and "cpu
like" attributes to be managed by common controller. We can ignore this
idea for cpu attributes, as those can just go in a GPU controller.
There might still be merit in having a 'device mem' cgroup controller.
The resource model at least is then no longer mixed up with host memory.
RDMA community seemed to have some interest in a common controller at
least for device memory aspects.
Thoughts on this? I believe could still reuse the 'struct mem_cgroup' data
structure. There should be some opportunity to reuse charging APIs and
have some nice integration with HMM for charging to device memory, depending
on backing store.
-Brian
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [Qemu-devel] [RFC 0/3] VirtIO RDMA
From: Jason Gunthorpe @ 2019-05-07 19:43 UTC (permalink / raw)
To: Yuval Shaia; +Cc: mst, linux-rdma, Cornelia Huck, qemu-devel, virtualization
In-Reply-To: <20190430171350.GA2763@lap1>
On Tue, Apr 30, 2019 at 08:13:54PM +0300, Yuval Shaia wrote:
> On Mon, Apr 22, 2019 at 01:45:27PM -0300, Jason Gunthorpe wrote:
> > On Fri, Apr 19, 2019 at 01:16:06PM +0200, Hannes Reinecke wrote:
> > > On 4/15/19 12:35 PM, Yuval Shaia wrote:
> > > > On Thu, Apr 11, 2019 at 07:02:15PM +0200, Cornelia Huck wrote:
> > > > > On Thu, 11 Apr 2019 14:01:54 +0300
> > > > > Yuval Shaia <yuval.shaia@oracle.com> wrote:
> > > > >
> > > > > > Data center backends use more and more RDMA or RoCE devices and more and
> > > > > > more software runs in virtualized environment.
> > > > > > There is a need for a standard to enable RDMA/RoCE on Virtual Machines.
> > > > > >
> > > > > > Virtio is the optimal solution since is the de-facto para-virtualizaton
> > > > > > technology and also because the Virtio specification
> > > > > > allows Hardware Vendors to support Virtio protocol natively in order to
> > > > > > achieve bare metal performance.
> > > > > >
> > > > > > This RFC is an effort to addresses challenges in defining the RDMA/RoCE
> > > > > > Virtio Specification and a look forward on possible implementation
> > > > > > techniques.
> > > > > >
> > > > > > Open issues/Todo list:
> > > > > > List is huge, this is only start point of the project.
> > > > > > Anyway, here is one example of item in the list:
> > > > > > - Multi VirtQ: Every QP has two rings and every CQ has one. This means that
> > > > > > in order to support for example 32K QPs we will need 64K VirtQ. Not sure
> > > > > > that this is reasonable so one option is to have one for all and
> > > > > > multiplex the traffic on it. This is not good approach as by design it
> > > > > > introducing an optional starvation. Another approach would be multi
> > > > > > queues and round-robin (for example) between them.
> > > > > >
> > > Typically there will be a one-to-one mapping between QPs and CPUs (on the
> > > guest).
> >
> > Er we are really overloading words here.. The typical expectation is
> > that a 'RDMA QP' will have thousands and thousands of instances on a
> > system.
> >
> > Most likely I think mapping 1:1 a virtio queue to a 'RDMA QP, CQ, SRQ,
> > etc' is a bad idea...
>
> We have three options, no virtqueue for QP, 1 to 1 or multiplexing. What
> would be your vote on that?
> I think you are for option #1, right? but in this case there is actually no
> use of having a virtio-driver, isn't it?
The virtio driver is supposed to be a standard, like a hardware
standard, for doing the operation.
It doesn't mean that every single element under the driver needs to
use the virtio format QP.
Jason
^ permalink raw reply
* Re: [PATCH v15 12/17] drm/radeon, arm64: untag user pointers in radeon_gem_userptr_ioctl
From: Kuehling, Felix @ 2019-05-07 16:44 UTC (permalink / raw)
To: Andrey Konovalov,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kselftest-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Mark Rutland, Szabolcs Nagy, Catalin Marinas, Will Deacon,
Kostya Serebryany, Vincenzo Frascino, Jacob Bramley,
Leon Romanovsky, Dave Martin, Evgeniy Stepanov, Kevin Brodsky,
Kees Cook, Ruben Ayrapetyan, Lee Smith, Alex Williamson,
Mauro Carvalho Chehab, Dmitry Vyukov, Greg Kroah-Hartman,
Yishai Hadas, Koenig, Christian, Ramana Radhakrishnan,
"Deucher, Alexander" <Alexander.D>
In-Reply-To: <03fe9d923db75cf72678f3ce103838e67390751a.1557160186.git.andreyknvl-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
On 2019-05-06 12:30 p.m., Andrey Konovalov wrote:
> [CAUTION: External Email]
>
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> In radeon_gem_userptr_ioctl() an MMU notifier is set up with a (tagged)
> userspace pointer. The untagged address should be used so that MMU
> notifiers for the untagged address get correctly matched up with the right
> BO. This funcation also calls radeon_ttm_tt_pin_userptr(), which uses
> provided user pointers for vma lookups, which can only by done with
> untagged pointers.
>
> This patch untags user pointers in radeon_gem_userptr_ioctl().
>
> Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Acked-by: Felix Kuehling <Felix.Kuehling@amd.com>
> ---
> drivers/gpu/drm/radeon/radeon_gem.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c
> index 44617dec8183..90eb78fb5eb2 100644
> --- a/drivers/gpu/drm/radeon/radeon_gem.c
> +++ b/drivers/gpu/drm/radeon/radeon_gem.c
> @@ -291,6 +291,8 @@ int radeon_gem_userptr_ioctl(struct drm_device *dev, void *data,
> uint32_t handle;
> int r;
>
> + args->addr = untagged_addr(args->addr);
> +
> if (offset_in_page(args->addr | args->size))
> return -EINVAL;
>
> --
> 2.21.0.1020.gf2820cf01a-goog
>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* Re: [PATCH v15 11/17] drm/amdgpu, arm64: untag user pointers
From: Kuehling, Felix @ 2019-05-07 16:43 UTC (permalink / raw)
To: Andrey Konovalov, linux-arm-kernel@lists.infradead.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
linux-rdma@vger.kernel.org, linux-media@vger.kernel.org,
kvm@vger.kernel.org, linux-kselftest@vger.kernel.org
Cc: Catalin Marinas, Vincenzo Frascino, Will Deacon, Mark Rutland,
Andrew Morton, Greg Kroah-Hartman, Kees Cook, Yishai Hadas,
Deucher, Alexander, Koenig, Christian, Mauro Carvalho Chehab,
Jens Wiklander, Alex Williamson, Leon Romanovsky, Dmitry Vyukov,
Kostya Serebryany, Evgeniy Stepanov, Lee Smith, Ramana
In-Reply-To: <84676a97cec129eb7a10559ceae2bec526160ad6.1557160186.git.andreyknvl@google.com>
On 2019-05-06 12:30 p.m., Andrey Konovalov wrote:
> [CAUTION: External Email]
>
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> In amdgpu_gem_userptr_ioctl() and amdgpu_amdkfd_gpuvm.c/init_user_pages()
> an MMU notifier is set up with a (tagged) userspace pointer. The untagged
> address should be used so that MMU notifiers for the untagged address get
> correctly matched up with the right BO. This patch untag user pointers in
> amdgpu_gem_userptr_ioctl() for the GEM case and in amdgpu_amdkfd_gpuvm_
> alloc_memory_of_gpu() for the KFD case. This also makes sure that an
> untagged pointer is passed to amdgpu_ttm_tt_get_user_pages(), which uses
> it for vma lookups.
>
> Suggested-by: Kuehling, Felix <Felix.Kuehling@amd.com>
> Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Acked-by: Felix Kuehling <Felix.Kuehling@amd.com>
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 2 ++
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> index 1921dec3df7a..20cac44ed449 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> @@ -1121,7 +1121,7 @@ int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
> alloc_flags = 0;
> if (!offset || !*offset)
> return -EINVAL;
> - user_addr = *offset;
> + user_addr = untagged_addr(*offset);
> } else if (flags & ALLOC_MEM_FLAGS_DOORBELL) {
> domain = AMDGPU_GEM_DOMAIN_GTT;
> alloc_domain = AMDGPU_GEM_DOMAIN_CPU;
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> index d21dd2f369da..985cb82b2aa6 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> @@ -286,6 +286,8 @@ int amdgpu_gem_userptr_ioctl(struct drm_device *dev, void *data,
> uint32_t handle;
> int r;
>
> + args->addr = untagged_addr(args->addr);
> +
> if (offset_in_page(args->addr | args->size))
> return -EINVAL;
>
> --
> 2.21.0.1020.gf2820cf01a-goog
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox