* [PATCH rdma-next 01/15] rds: Don't check return value from destroy CQ
From: Leon Romanovsky @ 2019-05-20 6:54 UTC (permalink / raw)
To: Doug Ledford, Jason Gunthorpe, Santosh Shilimkar
Cc: Leon Romanovsky, RDMA mailing list, Glenn Streiff, Steve Wise,
David S. Miller, netdev
In-Reply-To: <20190520065433.8734-1-leon@kernel.org>
From: Leon Romanovsky <leonro@mellanox.com>
There is no value in checking ib_destroy_cq() result and skipping
to clear struct ic fields. This connection needs to be reinitialized
anyway.
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
---
net/rds/ib_cm.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/rds/ib_cm.c b/net/rds/ib_cm.c
index 66c6eb56072b..5a42ebb892cd 100644
--- a/net/rds/ib_cm.c
+++ b/net/rds/ib_cm.c
@@ -611,11 +611,11 @@ static int rds_ib_setup_qp(struct rds_connection *conn)
qp_out:
rdma_destroy_qp(ic->i_cm_id);
recv_cq_out:
- if (!ib_destroy_cq(ic->i_recv_cq))
- ic->i_recv_cq = NULL;
+ ib_destroy_cq(ic->i_recv_cq);
+ ic->i_recv_cq = NULL;
send_cq_out:
- if (!ib_destroy_cq(ic->i_send_cq))
- ic->i_send_cq = NULL;
+ ib_destroy_cq(ic->i_send_cq);
+ ic->i_send_cq = NULL;
rds_ibdev_out:
rds_ib_remove_conn(rds_ibdev, conn);
out:
^ permalink raw reply related
* Re: [PATCH v15 00/17] arm64: untag user pointers passed to the kernel
From: Catalin Marinas @ 2019-05-17 14:49 UTC (permalink / raw)
To: Andrey Konovalov
Cc: linux-arm-kernel, linux-mm, linux-kernel, amd-gfx, dri-devel,
linux-rdma, linux-media, kvm, linux-kselftest, Vincenzo Frascino,
Will Deacon, Mark Rutland, Andrew Morton, Greg Kroah-Hartman,
Kees Cook, Yishai Hadas, Felix Kuehling, Alexander Deucher,
Christian Koenig, Mauro Carvalho Chehab, Jens Wiklander
In-Reply-To: <cover.1557160186.git.andreyknvl@google.com>
Hi Andrey,
On Mon, May 06, 2019 at 06:30:46PM +0200, Andrey Konovalov wrote:
> One of the alternative approaches to untagging that was considered is to
> completely strip the pointer tag as the pointer enters the kernel with
> some kind of a syscall wrapper, but that won't work with the countless
> number of different ioctl calls. With this approach we would need a custom
> wrapper for each ioctl variation, which doesn't seem practical.
The more I look at this problem, the less convinced I am that we can
solve it in a way that results in a stable ABI covering ioctls(). While
for the Android kernel codebase it could be simpler as you don't upgrade
the kernel version every 2.5 months, for the mainline kernel this
doesn't scale. Any run-time checks are relatively limited in terms of
drivers covered. Better static checking would be nice as a long term
solution but we didn't get anywhere with the discussion last year.
IMO (RFC for now), I see two ways forward:
1. Make this a user space problem and do not allow tagged pointers into
the syscall ABI. A libc wrapper would have to convert structures,
parameters before passing them into the kernel. Note that we can
still support the hardware MTE in the kernel by enabling tagged
memory ranges, saving/restoring tags etc. but not allowing tagged
addresses at the syscall boundary.
2. Similar shim to the above libc wrapper but inside the kernel
(arch/arm64 only; most pointer arguments could be covered with an
__SC_CAST similar to the s390 one). There are two differences from
what we've discussed in the past:
a) this is an opt-in by the user which would have to explicitly call
prctl(). If it returns -ENOTSUPP etc., the user won't be allowed
to pass tagged pointers to the kernel. This would probably be the
responsibility of the C lib to make sure it doesn't tag heap
allocations. If the user did not opt-in, the syscalls are routed
through the normal path (no untagging address shim).
b) ioctl() and other blacklisted syscalls (prctl) will not accept
tagged pointers (to be documented in Vicenzo's ABI patches).
It doesn't solve the problems we are trying to address but 2.a saves us
from blindly relaxing the ABI without knowing how to easily assess new
code being merged (over 500K lines between kernel versions). Existing
applications (who don't opt-in) won't inadvertently start using the new
ABI which could risk becoming de-facto ABI that we need to support on
the long run.
Option 1 wouldn't solve the ioctl() problem either and while it makes
things simpler for the kernel, I am aware that it's slightly more
complicated in user space (but I really don't mind if you prefer option
1 ;)).
The tagged pointers (whether hwasan or MTE) should ideally be a
transparent feature for the application writer but I don't think we can
solve it entirely and make it seamless for the multitude of ioctls().
I'd say you only opt in to such feature if you know what you are doing
and the user code takes care of specific cases like ioctl(), hence the
prctl() proposal even for the hwasan.
Comments welcomed.
--
Catalin
^ permalink raw reply
* Re: [PATCH v2] RDMA: Directly cast the sockaddr union to sockaddr
From: Simon Horman @ 2019-05-17 11:32 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Linus Torvalds, David Miller, Doug Ledford, linux-rdma,
Linux List Kernel Mailing, Netdev
In-Reply-To: <20190516152148.GD22587@ziepe.ca>
On Thu, May 16, 2019 at 12:21:48PM -0300, Jason Gunthorpe wrote:
> On Thu, May 16, 2019 at 02:44:28PM +0200, Simon Horman wrote:
> > On Mon, May 13, 2019 at 09:55:21PM -0300, Jason Gunthorpe wrote:
> > > 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.
> >
> > <2c>
> > I would be very happy to see this revisited in such a way
> > that some use is made of the C type system (instead of casts).
> > </2c>
>
> Well, I was thinking of swapping the union to sockaddr_storage ..
>
> Do you propose to add a union to the kernel's sockaddr storage?
I understand you have been down that rabbit hole before but,
yes, in an ideal world that would be my preference.
^ permalink raw reply
* Re: [PATCH v2] RDMA: Directly cast the sockaddr union to sockaddr
From: Jason Gunthorpe @ 2019-05-16 15:21 UTC (permalink / raw)
To: Simon Horman
Cc: Linus Torvalds, David Miller, Doug Ledford, linux-rdma,
Linux List Kernel Mailing, Netdev
In-Reply-To: <20190516124428.hytvkwfltfi24lrv@verge.net.au>
On Thu, May 16, 2019 at 02:44:28PM +0200, Simon Horman wrote:
> On Mon, May 13, 2019 at 09:55:21PM -0300, Jason Gunthorpe wrote:
> > 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.
>
> <2c>
> I would be very happy to see this revisited in such a way
> that some use is made of the C type system (instead of casts).
> </2c>
Well, I was thinking of swapping the union to sockaddr_storage ..
Do you propose to add a union to the kernel's sockaddr storage?
Jason
^ permalink raw reply
* Re: [PATCH] RDMA/nldev: add check for null return from call to nlmsg_put
From: Leon Romanovsky @ 2019-05-16 13:56 UTC (permalink / raw)
To: Colin King
Cc: Doug Ledford, Jason Gunthorpe, linux-rdma, kernel-janitors,
linux-kernel
In-Reply-To: <20190516131215.20411-1-colin.king@canonical.com>
On Thu, May 16, 2019 at 02:12:15PM +0100, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> It is possible that nlmsg_put can return a null pointer, currently
> this will lead to a null pointer dereference when passing a null
> nlh pointer to nlmsg_end. Fix this by adding a null pointer check.
>
> Addresses-Coverity: ("Dereference null return value")
> Fixes: cb7e0e130503 ("RDMA/core: Add interface to read device namespace sharing mode")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/infiniband/core/nldev.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/infiniband/core/nldev.c b/drivers/infiniband/core/nldev.c
> index 69188cbbd99b..4dc43b6c5a28 100644
> --- a/drivers/infiniband/core/nldev.c
> +++ b/drivers/infiniband/core/nldev.c
> @@ -1367,6 +1367,10 @@ static int nldev_sys_get_doit(struct sk_buff *skb, struct nlmsghdr *nlh,
> RDMA_NL_GET_TYPE(RDMA_NL_NLDEV,
> RDMA_NLDEV_CMD_SYS_GET),
> 0, 0);
It is impossible situation due to "0" in payload field above.
> + if (!nlh) {
> + nlmsg_free(msg);
> + return -EMSGSIZE;
> + }
>
> err = nla_put_u8(msg, RDMA_NLDEV_SYS_ATTR_NETNS_MODE,
> (u8)ib_devices_shared_netns);
> --
> 2.20.1
>
^ permalink raw reply
* [PATCH] RDMA/nldev: add check for null return from call to nlmsg_put
From: Colin King @ 2019-05-16 13:12 UTC (permalink / raw)
To: Doug Ledford, Jason Gunthorpe, linux-rdma; +Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
It is possible that nlmsg_put can return a null pointer, currently
this will lead to a null pointer dereference when passing a null
nlh pointer to nlmsg_end. Fix this by adding a null pointer check.
Addresses-Coverity: ("Dereference null return value")
Fixes: cb7e0e130503 ("RDMA/core: Add interface to read device namespace sharing mode")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/infiniband/core/nldev.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/infiniband/core/nldev.c b/drivers/infiniband/core/nldev.c
index 69188cbbd99b..4dc43b6c5a28 100644
--- a/drivers/infiniband/core/nldev.c
+++ b/drivers/infiniband/core/nldev.c
@@ -1367,6 +1367,10 @@ static int nldev_sys_get_doit(struct sk_buff *skb, struct nlmsghdr *nlh,
RDMA_NL_GET_TYPE(RDMA_NL_NLDEV,
RDMA_NLDEV_CMD_SYS_GET),
0, 0);
+ if (!nlh) {
+ nlmsg_free(msg);
+ return -EMSGSIZE;
+ }
err = nla_put_u8(msg, RDMA_NLDEV_SYS_ATTR_NETNS_MODE,
(u8)ib_devices_shared_netns);
--
2.20.1
^ permalink raw reply related
* Re: undefined reference to `__aeabi_uldivmod' after 25c13324d03d ("IB/mlx5: Add steering SW ICM device memory type")
From: Chen, Rong A @ 2019-05-16 12:57 UTC (permalink / raw)
To: Fengguang Wu, Nathan Chancellor
Cc: Arnd Bergmann, Leon Romanovsky, Jason Gunthorpe, kbuild@01.org,
Ariel Levkovich, Eli Cohen, Mark Bloch, Doug Ledford,
linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org,
Philip Li
In-Reply-To: <20190516022135.6tnf3xx5mzctutxz@wfg-t540p.sh.intel.com>
Hi,
On 5/16/2019 10:21 AM, Fengguang Wu wrote:
> CC current 0day kbuild test maintainers Philip and Rong. -fengguang
>
> On Tue, May 14, 2019 at 11:49:18PM -0700, Nathan Chancellor wrote:
>> On Wed, May 15, 2019 at 08:42:13AM +0200, Arnd Bergmann wrote:
>>> On Wed, May 15, 2019 at 8:40 AM Nathan Chancellor
>>> <natechancellor@gmail.com> wrote:
>>> > On Wed, May 15, 2019 at 08:31:49AM +0200, Arnd Bergmann wrote:
>>> > > On Wed, May 15, 2019 at 7:04 AM Leon Romanovsky
>>> <leonro@mellanox.com> wrote:
>>> > > > On Tue, May 14, 2019 at 09:32:02PM -0300, Jason Gunthorpe wrote:
>>> > > > > 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..
>>> > > >
>>> > > > I got many successful emails after I pushed this patch to
>>> 0-day testing.
>>> > >
>>> > > The long division warnings can compiler specific, and depend on
>>> certain
>>> > > optimization options, as compilers can optimize out certain
>>> divisions and
>>> > > replace them with multiplications and/or shifts, or prove that
>>> they can be
>>> > > replaced with a 32-bit division. If this is a case that gcc
>>> manages to
>>> > > optimize but clang does not, it might be worth looking into
>>> whether an
>>> > > optimization can be added to clang, in addition to improving the
>>> source.
>>> >
>>> > While I did run initially run into this with clang, the errors
>>> above are
>>> > with gcc (mainly to show this was going to be a universal problem and
>>> > not just something with clang).
>>>
>>> Which gcc version did you use here? Anything particularly old or
>>> particularly
>>> new? I think 0-day is on a fairly recent gcc-8, but not the latest
>>> gcc-9
>>> release.
>>
>> 8.2.0 it seems (I've been meaning to build from the 9.x branch though
>> since it appears that Arch's arm-linux-gnueabi-gcc isn't going to get
>> updated since it's in the AUR).
>>
Thanks for the reminding, we met some problems with gcc 8.1.0 once,
then we uses "arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0" as the
default gcc for arm,
It seems we have missed some build issues detected by new gcc. we're
going to upgrade gcc ASAP.
Best Regards,
Rong Chen
^ permalink raw reply
* Re: [PATCH v2] RDMA: Directly cast the sockaddr union to sockaddr
From: Simon Horman @ 2019-05-16 12:44 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Linus Torvalds, David Miller, Doug Ledford, linux-rdma,
Linux List Kernel Mailing, Netdev
In-Reply-To: <20190514005521.GA18085@ziepe.ca>
On Mon, May 13, 2019 at 09:55:21PM -0300, Jason Gunthorpe wrote:
> 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.
<2c>
I would be very happy to see this revisited in such a way
that some use is made of the C type system (instead of casts).
</2c>
^ permalink raw reply
* Re: CFP: 4th RDMA Mini-Summit at LPC 2019
From: Leon Romanovsky @ 2019-05-16 7:41 UTC (permalink / raw)
To: Kamal Heib
Cc: Yuval Shaia, RDMA mailing list, linux-netdev, linux-mm,
Jason Gunthorpe, Doug Ledford, Marcel Apfelbaum
In-Reply-To: <df639315-e13c-9a20-caf5-a66b009a8aa1@redhat.com>
On Thu, May 16, 2019 at 10:08:32AM +0300, Kamal Heib wrote:
>
>
> On 5/15/19 9:15 PM, Yuval Shaia wrote:
> > On Wed, May 15, 2019 at 07:36:26PM +0300, Leon Romanovsky wrote:
> >> On Wed, May 15, 2019 at 06:30:51PM +0300, Yuval Shaia wrote:
> >>> On Tue, May 14, 2019 at 03:23:21PM +0300, Leon Romanovsky wrote:
> >>>> 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.
> >>>
> >>> Abstract: Expand the virtio portfolio with RDMA
> >>>
> >>> Description:
> >>> 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 talk addresses challenges in defining the RDMA/RoCE Virtio
> >>> Specification and a look forward on possible implementation techniques.
> >>
> >> Yuval,
> >>
> >> Who is going to implement it?
> >>
> >> Thanks
> >
> > It is going to be an open source effort by an open source contributors.
> > Probably as with qemu-pvrdma it would be me and Marcel and i have an
> > unofficial approval from extra person that gave promise to join (can't say
> > his name but since he is also on this list then he welcome to raise a
> > hand).
>
> That person is me.
> Leon: Is Mellanox willing to join too?
I have no mandate to publicly commit to any future plans
on behalf of my employer.
Thanks
^ permalink raw reply
* Re: CFP: 4th RDMA Mini-Summit at LPC 2019
From: Kamal Heib @ 2019-05-16 7:08 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Yuval Shaia, RDMA mailing list, linux-netdev, linux-mm,
Jason Gunthorpe, Doug Ledford, Marcel Apfelbaum
In-Reply-To: <20190515181537.GA5720@lap1>
On 5/15/19 9:15 PM, Yuval Shaia wrote:
> On Wed, May 15, 2019 at 07:36:26PM +0300, Leon Romanovsky wrote:
>> On Wed, May 15, 2019 at 06:30:51PM +0300, Yuval Shaia wrote:
>>> On Tue, May 14, 2019 at 03:23:21PM +0300, Leon Romanovsky wrote:
>>>> 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.
>>>
>>> Abstract: Expand the virtio portfolio with RDMA
>>>
>>> Description:
>>> 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 talk addresses challenges in defining the RDMA/RoCE Virtio
>>> Specification and a look forward on possible implementation techniques.
>>
>> Yuval,
>>
>> Who is going to implement it?
>>
>> Thanks
>
> It is going to be an open source effort by an open source contributors.
> Probably as with qemu-pvrdma it would be me and Marcel and i have an
> unofficial approval from extra person that gave promise to join (can't say
> his name but since he is also on this list then he welcome to raise a
> hand).
That person is me.
Leon: Is Mellanox willing to join too?
> I also recall once someone from Mellanox wanted to join but not sure about
> his availability now.
>
>>
>>>
>>>>
>>>> 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
* Re: undefined reference to `__aeabi_uldivmod' after 25c13324d03d ("IB/mlx5: Add steering SW ICM device memory type")
From: Fengguang Wu @ 2019-05-16 2:21 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Arnd Bergmann, Leon Romanovsky, Jason Gunthorpe, kbuild@01.org,
Ariel Levkovich, Eli Cohen, Mark Bloch, Doug Ledford,
linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org,
Philip Li, Rong Chen
In-Reply-To: <20190515064918.GA4807@archlinux-i9>
CC current 0day kbuild test maintainers Philip and Rong. -fengguang
On Tue, May 14, 2019 at 11:49:18PM -0700, Nathan Chancellor wrote:
>On Wed, May 15, 2019 at 08:42:13AM +0200, Arnd Bergmann wrote:
>> On Wed, May 15, 2019 at 8:40 AM Nathan Chancellor
>> <natechancellor@gmail.com> wrote:
>> > On Wed, May 15, 2019 at 08:31:49AM +0200, Arnd Bergmann wrote:
>> > > On Wed, May 15, 2019 at 7:04 AM Leon Romanovsky <leonro@mellanox.com> wrote:
>> > > > On Tue, May 14, 2019 at 09:32:02PM -0300, Jason Gunthorpe wrote:
>> > > > > 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..
>> > > >
>> > > > I got many successful emails after I pushed this patch to 0-day testing.
>> > >
>> > > The long division warnings can compiler specific, and depend on certain
>> > > optimization options, as compilers can optimize out certain divisions and
>> > > replace them with multiplications and/or shifts, or prove that they can be
>> > > replaced with a 32-bit division. If this is a case that gcc manages to
>> > > optimize but clang does not, it might be worth looking into whether an
>> > > optimization can be added to clang, in addition to improving the source.
>> >
>> > While I did run initially run into this with clang, the errors above are
>> > with gcc (mainly to show this was going to be a universal problem and
>> > not just something with clang).
>>
>> Which gcc version did you use here? Anything particularly old or particularly
>> new? I think 0-day is on a fairly recent gcc-8, but not the latest gcc-9
>> release.
>
>8.2.0 it seems (I've been meaning to build from the 9.x branch though
>since it appears that Arch's arm-linux-gnueabi-gcc isn't going to get
>updated since it's in the AUR).
>
^ permalink raw reply
* Re: CFP: 4th RDMA Mini-Summit at LPC 2019
From: Yuval Shaia @ 2019-05-15 18:15 UTC (permalink / raw)
To: Leon Romanovsky
Cc: RDMA mailing list, linux-netdev, linux-mm, Jason Gunthorpe,
Doug Ledford, Marcel Apfelbaum
In-Reply-To: <20190515163626.GO5225@mtr-leonro.mtl.com>
On Wed, May 15, 2019 at 07:36:26PM +0300, Leon Romanovsky wrote:
> On Wed, May 15, 2019 at 06:30:51PM +0300, Yuval Shaia wrote:
> > On Tue, May 14, 2019 at 03:23:21PM +0300, Leon Romanovsky wrote:
> > > 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.
> >
> > Abstract: Expand the virtio portfolio with RDMA
> >
> > Description:
> > 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 talk addresses challenges in defining the RDMA/RoCE Virtio
> > Specification and a look forward on possible implementation techniques.
>
> Yuval,
>
> Who is going to implement it?
>
> Thanks
It is going to be an open source effort by an open source contributors.
Probably as with qemu-pvrdma it would be me and Marcel and i have an
unofficial approval from extra person that gave promise to join (can't say
his name but since he is also on this list then he welcome to raise a
hand).
I also recall once someone from Mellanox wanted to join but not sure about
his availability now.
>
> >
> > >
> > > 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
* Re: CFP: 4th RDMA Mini-Summit at LPC 2019
From: Leon Romanovsky @ 2019-05-15 16:36 UTC (permalink / raw)
To: Yuval Shaia
Cc: RDMA mailing list, linux-netdev, linux-mm, Jason Gunthorpe,
Doug Ledford
In-Reply-To: <20190515153050.GB2356@lap1>
On Wed, May 15, 2019 at 06:30:51PM +0300, Yuval Shaia wrote:
> On Tue, May 14, 2019 at 03:23:21PM +0300, Leon Romanovsky wrote:
> > 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.
>
> Abstract: Expand the virtio portfolio with RDMA
>
> Description:
> 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 talk addresses challenges in defining the RDMA/RoCE Virtio
> Specification and a look forward on possible implementation techniques.
Yuval,
Who is going to implement it?
Thanks
>
> >
> > 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
* Re: CFP: 4th RDMA Mini-Summit at LPC 2019
From: Yuval Shaia @ 2019-05-15 15:30 UTC (permalink / raw)
To: Leon Romanovsky
Cc: RDMA mailing list, linux-netdev, linux-mm, Jason Gunthorpe,
Doug Ledford
In-Reply-To: <20190514122321.GH6425@mtr-leonro.mtl.com>
On Tue, May 14, 2019 at 03:23:21PM +0300, Leon Romanovsky wrote:
> 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.
Abstract: Expand the virtio portfolio with RDMA
Description:
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 talk addresses challenges in defining the RDMA/RoCE Virtio
Specification and a look forward on possible implementation techniques.
>
> 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
* Re: undefined reference to `__aeabi_uldivmod' after 25c13324d03d ("IB/mlx5: Add steering SW ICM device memory type")
From: Nathan Chancellor @ 2019-05-15 6:49 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Leon Romanovsky, Jason Gunthorpe, fengguang.wu@intel.com,
kbuild@01.org, Ariel Levkovich, Eli Cohen, Mark Bloch,
Doug Ledford, linux-rdma@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CAK8P3a1r3QD=pwZqG+SfDkVr_V3P7ueRT8SLss9z+M6OEQst4A@mail.gmail.com>
On Wed, May 15, 2019 at 08:42:13AM +0200, Arnd Bergmann wrote:
> On Wed, May 15, 2019 at 8:40 AM Nathan Chancellor
> <natechancellor@gmail.com> wrote:
> > On Wed, May 15, 2019 at 08:31:49AM +0200, Arnd Bergmann wrote:
> > > On Wed, May 15, 2019 at 7:04 AM Leon Romanovsky <leonro@mellanox.com> wrote:
> > > > On Tue, May 14, 2019 at 09:32:02PM -0300, Jason Gunthorpe wrote:
> > > > > 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..
> > > >
> > > > I got many successful emails after I pushed this patch to 0-day testing.
> > >
> > > The long division warnings can compiler specific, and depend on certain
> > > optimization options, as compilers can optimize out certain divisions and
> > > replace them with multiplications and/or shifts, or prove that they can be
> > > replaced with a 32-bit division. If this is a case that gcc manages to
> > > optimize but clang does not, it might be worth looking into whether an
> > > optimization can be added to clang, in addition to improving the source.
> >
> > While I did run initially run into this with clang, the errors above are
> > with gcc (mainly to show this was going to be a universal problem and
> > not just something with clang).
>
> Which gcc version did you use here? Anything particularly old or particularly
> new? I think 0-day is on a fairly recent gcc-8, but not the latest gcc-9
> release.
8.2.0 it seems (I've been meaning to build from the 9.x branch though
since it appears that Arch's arm-linux-gnueabi-gcc isn't going to get
updated since it's in the AUR).
^ permalink raw reply
* Re: undefined reference to `__aeabi_uldivmod' after 25c13324d03d ("IB/mlx5: Add steering SW ICM device memory type")
From: Arnd Bergmann @ 2019-05-15 6:42 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Leon Romanovsky, Jason Gunthorpe, fengguang.wu@intel.com,
kbuild@01.org, Ariel Levkovich, Eli Cohen, Mark Bloch,
Doug Ledford, linux-rdma@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20190515064043.GA944@archlinux-i9>
On Wed, May 15, 2019 at 8:40 AM Nathan Chancellor
<natechancellor@gmail.com> wrote:
> On Wed, May 15, 2019 at 08:31:49AM +0200, Arnd Bergmann wrote:
> > On Wed, May 15, 2019 at 7:04 AM Leon Romanovsky <leonro@mellanox.com> wrote:
> > > On Tue, May 14, 2019 at 09:32:02PM -0300, Jason Gunthorpe wrote:
> > > > 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..
> > >
> > > I got many successful emails after I pushed this patch to 0-day testing.
> >
> > The long division warnings can compiler specific, and depend on certain
> > optimization options, as compilers can optimize out certain divisions and
> > replace them with multiplications and/or shifts, or prove that they can be
> > replaced with a 32-bit division. If this is a case that gcc manages to
> > optimize but clang does not, it might be worth looking into whether an
> > optimization can be added to clang, in addition to improving the source.
>
> While I did run initially run into this with clang, the errors above are
> with gcc (mainly to show this was going to be a universal problem and
> not just something with clang).
Which gcc version did you use here? Anything particularly old or particularly
new? I think 0-day is on a fairly recent gcc-8, but not the latest gcc-9
release.
Arnd
^ permalink raw reply
* Re: undefined reference to `__aeabi_uldivmod' after 25c13324d03d ("IB/mlx5: Add steering SW ICM device memory type")
From: Nathan Chancellor @ 2019-05-15 6:40 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Leon Romanovsky, Jason Gunthorpe, fengguang.wu@intel.com,
kbuild@01.org, Ariel Levkovich, Eli Cohen, Mark Bloch,
Doug Ledford, linux-rdma@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CAK8P3a0aH9Ezur3r7TDVMPreVKMip2HMEWhUsC_pKhOq7mE+3A@mail.gmail.com>
On Wed, May 15, 2019 at 08:31:49AM +0200, Arnd Bergmann wrote:
> On Wed, May 15, 2019 at 7:04 AM Leon Romanovsky <leonro@mellanox.com> wrote:
> > On Tue, May 14, 2019 at 09:32:02PM -0300, Jason Gunthorpe wrote:
> > > 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..
> >
> > I got many successful emails after I pushed this patch to 0-day testing.
>
> The long division warnings can compiler specific, and depend on certain
> optimization options, as compilers can optimize out certain divisions and
> replace them with multiplications and/or shifts, or prove that they can be
> replaced with a 32-bit division. If this is a case that gcc manages to
> optimize but clang does not, it might be worth looking into whether an
> optimization can be added to clang, in addition to improving the source.
>
> Arnd
While I did run initially run into this with clang, the errors above are
with gcc (mainly to show this was going to be a universal problem and
not just something with clang).
Nathan
^ permalink raw reply
* Re: undefined reference to `__aeabi_uldivmod' after 25c13324d03d ("IB/mlx5: Add steering SW ICM device memory type")
From: Arnd Bergmann @ 2019-05-15 6:31 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Jason Gunthorpe, Nathan Chancellor, fengguang.wu@intel.com,
kbuild@01.org, Ariel Levkovich, Eli Cohen, Mark Bloch,
Doug Ledford, linux-rdma@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20190515050331.GC5225@mtr-leonro.mtl.com>
On Wed, May 15, 2019 at 7:04 AM Leon Romanovsky <leonro@mellanox.com> wrote:
> On Tue, May 14, 2019 at 09:32:02PM -0300, Jason Gunthorpe wrote:
> > 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..
>
> I got many successful emails after I pushed this patch to 0-day testing.
The long division warnings can compiler specific, and depend on certain
optimization options, as compilers can optimize out certain divisions and
replace them with multiplications and/or shifts, or prove that they can be
replaced with a 32-bit division. If this is a case that gcc manages to
optimize but clang does not, it might be worth looking into whether an
optimization can be added to clang, in addition to improving the source.
Arnd
^ permalink raw reply
* Re: undefined reference to `__aeabi_uldivmod' after 25c13324d03d ("IB/mlx5: Add steering SW ICM device memory type")
From: Leon Romanovsky @ 2019-05-15 5:04 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Nathan Chancellor, Ariel Levkovich, Eli Cohen, Mark Bloch,
Doug Ledford, linux-rdma@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20190515003355.GB14522@ziepe.ca>
On Wed, May 15, 2019 at 12:34:00AM +0000, Jason Gunthorpe wrote:
> On Tue, May 14, 2019 at 12:45:10PM -0700, Nathan Chancellor wrote:
> > 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.
>
> Hmm. Most likely those u64 length's should really be size_t.
Indeed, it should be size_t.
>
> Ariel?
>
> Jason
^ permalink raw reply
* Re: undefined reference to `__aeabi_uldivmod' after 25c13324d03d ("IB/mlx5: Add steering SW ICM device memory type")
From: Leon Romanovsky @ 2019-05-15 5:03 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Nathan Chancellor, fengguang.wu@intel.com, kbuild@01.org,
Ariel Levkovich, Eli Cohen, Mark Bloch, Doug Ledford,
linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20190515003202.GA14522@ziepe.ca>
On Tue, May 14, 2019 at 09:32:02PM -0300, Jason Gunthorpe wrote:
> 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..
I got many successful emails after I pushed this patch to 0-day testing.
>
> 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: [GIT PULL] Please pull RDMA subsystem changes
From: pr-tracker-bot @ 2019-05-15 4:05 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Linus Torvalds, Doug Ledford, linux-rdma@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20190515004652.GA17171@ziepe.ca>
The pull request you sent on Wed, 15 May 2019 00:46:58 +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/5ac94332248ee017964ba368cdda4ce647e3aba7
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-15 0:46 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: 1991 bytes --]
Hi Linus,
These are the 2nd proposed RDMA patches for 5.2.
As requested the main reason to send this is to fix the gcc 9.1
warnings that many people may hit now that FC30 is out.
Thanks,
Jason
The following changes since commit b79656ed44c6865e17bcd93472ec39488bcc4984:
RDMA/ipoib: Allow user space differentiate between valid dev_port (2019-05-07 16:13:23 -0300)
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 c191f93454bcc92810b9c8cdb895a452a57948c2:
net/mlx5: Set completion EQs as shared resources (2019-05-14 10:22:09 -0300)
----------------------------------------------------------------
5.2 Merge Window second pull request
This is being sent to get a fix for the gcc 9.1 build warnings, and I've
also pulled in some bug fix patches that were posted in the last two
weeks.
- Avoid the gcc 9.1 warning about overflowing a union member
- Fix the wrong callback type for a single response netlink to doit
- Bug fixes from more usage of the mlx5 devx interface
----------------------------------------------------------------
Jason Gunthorpe (1):
RDMA: Directly cast the sockaddr union to sockaddr
Parav Pandit (1):
RDMA/core: Change system parameters callback from dumpit to doit
Yishai Hadas (2):
IB/mlx5: Verify DEVX general object type correctly
net/mlx5: Set completion EQs as shared resources
drivers/infiniband/core/addr.c | 16 ++++++++--------
drivers/infiniband/core/nldev.c | 27 +++++++++++++++------------
drivers/infiniband/hw/mlx5/devx.c | 13 ++++++++++---
drivers/infiniband/hw/ocrdma/ocrdma_ah.c | 5 ++---
drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 5 ++---
drivers/net/ethernet/mellanox/mlx5/core/eq.c | 3 +++
include/linux/mlx5/mlx5_ifc.h | 2 +-
include/uapi/rdma/rdma_netlink.h | 2 +-
8 files changed, 42 insertions(+), 31 deletions(-)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH rdma-next 0/2] DevX fixes
From: Jason Gunthorpe @ 2019-05-15 0:36 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, Leon Romanovsky, RDMA mailing list, Saeed Mahameed,
Yishai Hadas, linux-netdev
In-Reply-To: <20190514114412.30604-1-leon@kernel.org>
On Tue, May 14, 2019 at 02:44:10PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@mellanox.com>
>
> Hi,
>
> There are two very short but important fixes to DevX flows.
applied to for-next
Jason
^ permalink raw reply
* Re: undefined reference to `__aeabi_uldivmod' after 25c13324d03d ("IB/mlx5: Add steering SW ICM device memory type")
From: Jason Gunthorpe @ 2019-05-15 0:34 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Ariel Levkovich, Eli Cohen, Mark Bloch, Leon Romanovsky,
Doug Ledford, linux-rdma@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20190514194510.GA15465@archlinux-i9>
On Tue, May 14, 2019 at 12:45:10PM -0700, Nathan Chancellor wrote:
> 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.
Hmm. Most likely those u64 length's should really be size_t.
Ariel?
Jason
^ permalink raw reply
* 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
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