* Re: failed armel build of rdma-core 24.0-1
From: Gal Pressman @ 2019-07-11 8:00 UTC (permalink / raw)
To: Leon Romanovsky; +Cc: Jason Gunthorpe, Benjamin Drung, linux-rdma
In-Reply-To: <20190711070744.GD23598@mtr-leonro.mtl.com>
On 11/07/2019 10:07, Leon Romanovsky wrote:
> On Thu, Jul 11, 2019 at 09:35:59AM +0300, Gal Pressman wrote:
>> On 10/07/2019 22:23, Jason Gunthorpe wrote:
>>> Benjamin,
>>>
>>> Can you confirm that something like this fixes these build problems?
>>>
>>> diff --git a/debian/rules b/debian/rules
>>> index 07c9c145ff090c..facb45170eacfc 100755
>>> --- a/debian/rules
>>> +++ b/debian/rules
>>> @@ -63,6 +63,7 @@ ifneq (,$(filter-out $(COHERENT_DMA_ARCHS),$(DEB_HOST_ARCH)))
>>> test -e debian/$$package.install.backup || cp debian/$$package.install debian/$$package.install.backup; \
>>> done
>>> sed -i '/mlx[45]/d' debian/ibverbs-providers.install debian/libibverbs-dev.install debian/rdma-core.install
>>> + sed -i '/efa/d' debian/ibverbs-providers.install debian/libibverbs-dev.install debian/rdma-core.install
>>> endif
>>> DESTDIR=$(CURDIR)/debian/tmp ninja -C build-deb install
>>>
>>>
>>>
>>> On Wed, Jul 10, 2019 at 11:37:01AM -0000, Debian buildds wrote:
>>>> * Source package: rdma-core
>>>> * Version: 24.0-1
>>>> * Architecture: armel
>>>> * State: failed
>>>> * Suite: sid
>>>> * Builder: antheil.debian.org
>>>> * Build log: https://buildd.debian.org/status/fetch.php?pkg=rdma-core&arch=armel&ver=24.0-1&stamp=1562758620&file=log
>>>>
>>>> Please note that these notifications do not necessarily mean bug reports
>>>> in your package but could also be caused by other packages, temporary
>>>> uninstallabilities and arch-specific breakages. A look at the build log
>>>> despite this disclaimer would be appreciated however.
>>
>> Was this error supposed to be reported by travis as well? I'm pretty sure all
>> tests passed.
>
> Did you get any build failure email from debian? I didn't.
I didn't, who is supposed to get these?
^ permalink raw reply
* Re: [PATCH -next] rdma/siw: Add missing dependencies on LIBCRC32C and DMA_VIRT_OPS
From: Geert Uytterhoeven @ 2019-07-11 7:58 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Bernard Metzler, Doug Ledford, linux-rdma,
Linux Kernel Mailing List, Linux-Next
In-Reply-To: <20190710144636.GC4051@ziepe.ca>
Hi Jason,
On Wed, Jul 10, 2019 at 4:46 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> On Wed, Jul 10, 2019 at 03:39:30PM +0200, Geert Uytterhoeven wrote:
> > If LIBCRC32C and DMA_VIRT_OPS are not enabled:
> >
> > drivers/infiniband/sw/siw/siw_main.o: In function `siw_newlink':
> > siw_main.c:(.text+0x35c): undefined reference to `dma_virt_ops'
> > drivers/infiniband/sw/siw/siw_qp_rx.o: In function `siw_csum_update':
> > siw_qp_rx.c:(.text+0x16): undefined reference to `crc32c'
> >
> > Fix the first issue by adding a select of DMA_VIRT_OPS.
> > Fix the second issue by replacing the unneeded dependency on
> > CRYPTO_CRC32 by a dependency on LIBCRC32C.
> >
> > Reported-by: noreply@ellerman.id.au (first issue)
> > Fixes: c0cf5bdde46c664d ("rdma/siw: addition to kernel build environment")
> > Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> > drivers/infiniband/sw/siw/Kconfig | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/infiniband/sw/siw/Kconfig b/drivers/infiniband/sw/siw/Kconfig
> > index 94f684174ce3556e..b622fc62f2cd6d46 100644
> > +++ b/drivers/infiniband/sw/siw/Kconfig
> > @@ -1,6 +1,7 @@
> > config RDMA_SIW
> > tristate "Software RDMA over TCP/IP (iWARP) driver"
> > - depends on INET && INFINIBAND && CRYPTO_CRC32
> > + depends on INET && INFINIBAND && LIBCRC32C
>
> Is this the best practice?
>
> siw is using both the libcrc32c API and the
> 'crypto_alloc_shash("crc32c", 0, 0);' version. Is it right to get that
> transitively through LIBCRC32C?
Yes, I think so.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] rdma/siw: Use proper enumerated type in map_cqe_status
From: Bernard Metzler @ 2019-07-11 7:44 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Doug Ledford, Jason Gunthorpe, linux-rdma, linux-kernel,
clang-built-linux
In-Reply-To: <20190710174800.34451-1-natechancellor@gmail.com>
-----"Nathan Chancellor" <natechancellor@gmail.com> wrote: -----
>To: "Bernard Metzler" <bmt@zurich.ibm.com>, "Doug Ledford"
><dledford@redhat.com>, "Jason Gunthorpe" <jgg@ziepe.ca>
>From: "Nathan Chancellor" <natechancellor@gmail.com>
>Date: 07/10/2019 07:48PM
>Cc: linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org,
>clang-built-linux@googlegroups.com, "Nathan Chancellor"
><natechancellor@gmail.com>
>Subject: [EXTERNAL] [PATCH] rdma/siw: Use proper enumerated type in
>map_cqe_status
>
>clang warns several times:
>
>drivers/infiniband/sw/siw/siw_cq.c:31:4: warning: implicit conversion
>from enumeration type 'enum siw_wc_status' to different enumeration
>type
>'enum siw_opcode' [-Wenum-conversion]
> { SIW_WC_SUCCESS, IB_WC_SUCCESS },
> ~ ^~~~~~~~~~~~~~
>
>Fixes: b0fff7317bb4 ("rdma/siw: completion queue methods")
>Link:
>https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Clang
>BuiltLinux_linux_issues_596&d=DwIDAg&c=jf_iaSHvJObTbx-siA1ZOg&r=2TaYX
>Q0T-r8ZO1PP1alNwU_QJcRRLfmYTAgd3QCvqSc&m=1dqKSwiEVgePsLNbxXRmdhXDxww4
>AEGxKq-g-MmQHBo&s=IFwaU5yLu598NLBtKkAxLXzRNmACfnhxCpg3QVeJpB0&e=
>Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
>---
> drivers/infiniband/sw/siw/siw_cq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/infiniband/sw/siw/siw_cq.c
>b/drivers/infiniband/sw/siw/siw_cq.c
>index e2a0ee40d5b5..e381ae9b7d62 100644
>--- a/drivers/infiniband/sw/siw/siw_cq.c
>+++ b/drivers/infiniband/sw/siw/siw_cq.c
>@@ -25,7 +25,7 @@ static int map_wc_opcode[SIW_NUM_OPCODES] = {
> };
>
> static struct {
>- enum siw_opcode siw;
>+ enum siw_wc_status siw;
> enum ib_wc_status ib;
> } map_cqe_status[SIW_NUM_WC_STATUS] = {
> { SIW_WC_SUCCESS, IB_WC_SUCCESS },
>--
>2.22.0
>
>
>
Nathan, thanks very much. That's correct.
I don't know how this could pass w/o warning.
Many thanks,
Bernard.
^ permalink raw reply
* Re: [PATCH v4 00/25] InfiniBand Transport (IBTRS) and Network Block Device (IBNBD)
From: Danil Kipnis @ 2019-07-11 7:27 UTC (permalink / raw)
To: Sagi Grimberg
Cc: Jason Gunthorpe, Jack Wang, linux-block, linux-rdma, axboe,
Christoph Hellwig, bvanassche, dledford, Roman Pen, gregkh
In-Reply-To: <930e0bc6-8c5c-97b5-c500-0bd1706b32c1@grimberg.me>
Hi Sagi,
thanks a lot for the analysis. I didn't know about about the
inline_data_size parameter in nvmet. It is at PAGE_SIZE on our
systems.
Will rerun our benchmarks with
echo 2097152 > /sys/kernel/config/nvmet/ports/1/param_inline_data_size
echo 2097152 > /sys/kernel/config/nvmet/ports/2/param_inline_data_size
before enabling the port.
Best
Danil.
On Wed, Jul 10, 2019 at 9:11 PM Sagi Grimberg <sagi@grimberg.me> wrote:
>
>
> >> I still do not understand why this should give any notice-able
> >> performance advantage.
> >
> > Usually omitting invalidations gives a healthy bump.
> >
> > Also, RDMA WRITE is generally faster than READ at the HW level in
> > various ways.
>
> Yes, but this should be essentially identical to running nvme-rdma
> with 512KB of immediate-data (the nvme term is in-capsule data).
>
> In the upstream nvme target we have inline_data_size port attribute
> that is tunable for that (defaults to PAGE_SIZE).
--
Danil Kipnis
Linux Kernel Developer
1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: danil.kipnis@cloud.ionos.com | Web: www.ionos.de
Head Office: Berlin, Germany
District Court Berlin Charlottenburg, Registration number: HRB 125506 B
Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss
Member of United Internet
This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient of this e-mail, you are hereby
notified that saving, distribution or use of the content of this
e-mail in any way is prohibited. If you have received this e-mail in
error, please notify the sender and delete the e-mail.
^ permalink raw reply
* RE: [PATCH v6 rdma-next 0/6] RDMA/qedr: Use the doorbell overflow recovery mechanism for RDMA
From: Michal Kalderon @ 2019-07-11 7:23 UTC (permalink / raw)
To: Gal Pressman, Ariel Elior, jgg@ziepe.ca, dledford@redhat.com
Cc: linux-rdma@vger.kernel.org, davem@davemloft.net,
netdev@vger.kernel.org, sleybo@amazon.com
In-Reply-To: <7b2f2205-6b5d-c9e7-2d59-296367e517ac@amazon.com>
> From: linux-rdma-owner@vger.kernel.org <linux-rdma-
> owner@vger.kernel.org> On Behalf Of Gal Pressman
>
> On 09/07/2019 17:17, Michal Kalderon wrote:
> > This patch series uses the doorbell overflow recovery mechanism
> > introduced in commit 36907cd5cd72 ("qed: Add doorbell overflow
> > recovery mechanism") for rdma ( RoCE and iWARP )
> >
> > The first three patches modify the core code to contain helper
> > functions for managing mmap_xa inserting, getting and freeing entries.
> > The code was taken almost as is from the efa driver.
> > There is still an open discussion on whether we should take this even
> > further and make the entire mmap generic. Until a decision is made, I
> > only created the database API and modified the efa and qedr driver to
> > use it. The doorbell recovery code will be based on the common code.
> >
> > Efa driver was compile tested only.
>
> For the whole series:
> Tested-by: Gal Pressman <galpress@amazon.com>
Thanks Gal!
^ permalink raw reply
* [PATCH -next] rdma/siw: remove set but not used variable 's'
From: YueHaibing @ 2019-07-11 7:12 UTC (permalink / raw)
To: bmt, dledford, jgg; +Cc: linux-kernel, linux-rdma, YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/infiniband/sw/siw/siw_cm.c: In function siw_cm_llp_state_change:
drivers/infiniband/sw/siw/siw_cm.c:1278:17: warning: variable s set but not used [-Wunused-but-set-variable]
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/infiniband/sw/siw/siw_cm.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/infiniband/sw/siw/siw_cm.c b/drivers/infiniband/sw/siw/siw_cm.c
index c883bf5..7d87a78 100644
--- a/drivers/infiniband/sw/siw/siw_cm.c
+++ b/drivers/infiniband/sw/siw/siw_cm.c
@@ -1275,7 +1275,6 @@ static void siw_cm_llp_error_report(struct sock *sk)
static void siw_cm_llp_state_change(struct sock *sk)
{
struct siw_cep *cep;
- struct socket *s;
void (*orig_state_change)(struct sock *s);
read_lock(&sk->sk_callback_lock);
@@ -1288,8 +1287,6 @@ static void siw_cm_llp_state_change(struct sock *sk)
}
orig_state_change = cep->sk_state_change;
- s = sk->sk_socket;
-
siw_dbg_cep(cep, "state: %d\n", cep->state);
switch (sk->sk_state) {
--
2.7.4
^ permalink raw reply related
* Re: failed armel build of rdma-core 24.0-1
From: Leon Romanovsky @ 2019-07-11 7:07 UTC (permalink / raw)
To: Gal Pressman; +Cc: Jason Gunthorpe, Benjamin Drung, linux-rdma
In-Reply-To: <92fc16f9-d9f2-a05f-b049-137550ab4bfd@amazon.com>
On Thu, Jul 11, 2019 at 09:35:59AM +0300, Gal Pressman wrote:
> On 10/07/2019 22:23, Jason Gunthorpe wrote:
> > Benjamin,
> >
> > Can you confirm that something like this fixes these build problems?
> >
> > diff --git a/debian/rules b/debian/rules
> > index 07c9c145ff090c..facb45170eacfc 100755
> > --- a/debian/rules
> > +++ b/debian/rules
> > @@ -63,6 +63,7 @@ ifneq (,$(filter-out $(COHERENT_DMA_ARCHS),$(DEB_HOST_ARCH)))
> > test -e debian/$$package.install.backup || cp debian/$$package.install debian/$$package.install.backup; \
> > done
> > sed -i '/mlx[45]/d' debian/ibverbs-providers.install debian/libibverbs-dev.install debian/rdma-core.install
> > + sed -i '/efa/d' debian/ibverbs-providers.install debian/libibverbs-dev.install debian/rdma-core.install
> > endif
> > DESTDIR=$(CURDIR)/debian/tmp ninja -C build-deb install
> >
> >
> >
> > On Wed, Jul 10, 2019 at 11:37:01AM -0000, Debian buildds wrote:
> >> * Source package: rdma-core
> >> * Version: 24.0-1
> >> * Architecture: armel
> >> * State: failed
> >> * Suite: sid
> >> * Builder: antheil.debian.org
> >> * Build log: https://buildd.debian.org/status/fetch.php?pkg=rdma-core&arch=armel&ver=24.0-1&stamp=1562758620&file=log
> >>
> >> Please note that these notifications do not necessarily mean bug reports
> >> in your package but could also be caused by other packages, temporary
> >> uninstallabilities and arch-specific breakages. A look at the build log
> >> despite this disclaimer would be appreciated however.
>
> Was this error supposed to be reported by travis as well? I'm pretty sure all
> tests passed.
Did you get any build failure email from debian? I didn't.
Thanks
^ permalink raw reply
* Re: failed armel build of rdma-core 24.0-1
From: Gal Pressman @ 2019-07-11 6:35 UTC (permalink / raw)
To: Jason Gunthorpe, Benjamin Drung; +Cc: linux-rdma
In-Reply-To: <20190710192316.GH4051@ziepe.ca>
On 10/07/2019 22:23, Jason Gunthorpe wrote:
> Benjamin,
>
> Can you confirm that something like this fixes these build problems?
>
> diff --git a/debian/rules b/debian/rules
> index 07c9c145ff090c..facb45170eacfc 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -63,6 +63,7 @@ ifneq (,$(filter-out $(COHERENT_DMA_ARCHS),$(DEB_HOST_ARCH)))
> test -e debian/$$package.install.backup || cp debian/$$package.install debian/$$package.install.backup; \
> done
> sed -i '/mlx[45]/d' debian/ibverbs-providers.install debian/libibverbs-dev.install debian/rdma-core.install
> + sed -i '/efa/d' debian/ibverbs-providers.install debian/libibverbs-dev.install debian/rdma-core.install
> endif
> DESTDIR=$(CURDIR)/debian/tmp ninja -C build-deb install
>
>
>
> On Wed, Jul 10, 2019 at 11:37:01AM -0000, Debian buildds wrote:
>> * Source package: rdma-core
>> * Version: 24.0-1
>> * Architecture: armel
>> * State: failed
>> * Suite: sid
>> * Builder: antheil.debian.org
>> * Build log: https://buildd.debian.org/status/fetch.php?pkg=rdma-core&arch=armel&ver=24.0-1&stamp=1562758620&file=log
>>
>> Please note that these notifications do not necessarily mean bug reports
>> in your package but could also be caused by other packages, temporary
>> uninstallabilities and arch-specific breakages. A look at the build log
>> despite this disclaimer would be appreciated however.
Was this error supposed to be reported by travis as well? I'm pretty sure all
tests passed.
^ permalink raw reply
* Re: [PATCH] net/mlx5e: Move priv variable into case statement in mlx5e_setup_tc
From: Nathan Chancellor @ 2019-07-11 6:09 UTC (permalink / raw)
To: Saeed Mahameed
Cc: Saeed Mahameed, Leon Romanovsky, David S. Miller,
Linux Netdev List, RDMA mailing list, linux-kernel,
clang-built-linux
In-Reply-To: <CALzJLG9Aw=sVPDiewHr+4Jiuaod_1q=10vzMzCUVg-rCCXD6cQ@mail.gmail.com>
On Wed, Jul 10, 2019 at 11:02:00PM -0700, Saeed Mahameed wrote:
> On Wed, Jul 10, 2019 at 12:05 PM Nathan Chancellor
> <natechancellor@gmail.com> wrote:
> >
> > There is an unused variable warning on arm64 defconfig when
> > CONFIG_MLX5_ESWITCH is unset:
> >
> > drivers/net/ethernet/mellanox/mlx5/core/en_main.c:3467:21: warning:
> > unused variable 'priv' [-Wunused-variable]
> > struct mlx5e_priv *priv = netdev_priv(dev);
> > ^
> > 1 warning generated.
> >
> > Move it down into the case statement where it is used.
> >
> > Fixes: 4e95bc268b91 ("net: flow_offload: add flow_block_cb_setup_simple()")
> > Link: https://github.com/ClangBuiltLinux/linux/issues/597
> > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> > ---
> > drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 7 ++++---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> > index 6d0ae87c8ded..651eb714eb5b 100644
> > --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> > +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> > @@ -3464,15 +3464,16 @@ static LIST_HEAD(mlx5e_block_cb_list);
> > static int mlx5e_setup_tc(struct net_device *dev, enum tc_setup_type type,
> > void *type_data)
> > {
> > - struct mlx5e_priv *priv = netdev_priv(dev);
> > -
> > switch (type) {
> > #ifdef CONFIG_MLX5_ESWITCH
> > - case TC_SETUP_BLOCK:
> > + case TC_SETUP_BLOCK: {
> > + struct mlx5e_priv *priv = netdev_priv(dev);
> > +
> > return flow_block_cb_setup_simple(type_data,
> > &mlx5e_block_cb_list,
> > mlx5e_setup_tc_block_cb,
> > priv, priv, true);
> > + }
>
> Hi Nathan,
>
> We have another patch internally that fixes this, and it is already
> queued up in my queue.
> it works differently as we want to pass priv instead of netdev to
> mlx5e_setup_tc_mqprio below,
> which will also solve warning ..
>
> So i would like to submit that patch if it is ok with you ?
Hi Saeed,
Whatever works best for you, I just care that the warning gets fixed,
not how it is done :) I wouldn't mind being put on CC so I can pick it
up for my local tests.
Thanks for the follow up!
Nathan
^ permalink raw reply
* Re: [PATCH] net/mlx5e: Move priv variable into case statement in mlx5e_setup_tc
From: Saeed Mahameed @ 2019-07-11 6:02 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Saeed Mahameed, Leon Romanovsky, David S. Miller,
Linux Netdev List, RDMA mailing list, linux-kernel,
clang-built-linux
In-Reply-To: <20190710190502.104010-1-natechancellor@gmail.com>
On Wed, Jul 10, 2019 at 12:05 PM Nathan Chancellor
<natechancellor@gmail.com> wrote:
>
> There is an unused variable warning on arm64 defconfig when
> CONFIG_MLX5_ESWITCH is unset:
>
> drivers/net/ethernet/mellanox/mlx5/core/en_main.c:3467:21: warning:
> unused variable 'priv' [-Wunused-variable]
> struct mlx5e_priv *priv = netdev_priv(dev);
> ^
> 1 warning generated.
>
> Move it down into the case statement where it is used.
>
> Fixes: 4e95bc268b91 ("net: flow_offload: add flow_block_cb_setup_simple()")
> Link: https://github.com/ClangBuiltLinux/linux/issues/597
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> index 6d0ae87c8ded..651eb714eb5b 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> @@ -3464,15 +3464,16 @@ static LIST_HEAD(mlx5e_block_cb_list);
> static int mlx5e_setup_tc(struct net_device *dev, enum tc_setup_type type,
> void *type_data)
> {
> - struct mlx5e_priv *priv = netdev_priv(dev);
> -
> switch (type) {
> #ifdef CONFIG_MLX5_ESWITCH
> - case TC_SETUP_BLOCK:
> + case TC_SETUP_BLOCK: {
> + struct mlx5e_priv *priv = netdev_priv(dev);
> +
> return flow_block_cb_setup_simple(type_data,
> &mlx5e_block_cb_list,
> mlx5e_setup_tc_block_cb,
> priv, priv, true);
> + }
Hi Nathan,
We have another patch internally that fixes this, and it is already
queued up in my queue.
it works differently as we want to pass priv instead of netdev to
mlx5e_setup_tc_mqprio below,
which will also solve warning ..
So i would like to submit that patch if it is ok with you ?
> #endif
> case TC_SETUP_QDISC_MQPRIO:
> return mlx5e_setup_tc_mqprio(dev, type_data);
> --
> 2.22.0
>
^ permalink raw reply
* Re: [PATCH] rdma/siw: Use proper enumerated type in map_cqe_status
From: Nathan Chancellor @ 2019-07-11 3:02 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Jason Gunthorpe, Bernard Metzler, Doug Ledford, linux-rdma, LKML,
clang-built-linux
In-Reply-To: <CAKwvOd=yJQgzjQBKW7=en_YnF6OCAg0MXy5c6c9tBLSjGgorPA@mail.gmail.com>
On Wed, Jul 10, 2019 at 04:53:50PM -0700, Nick Desaulniers wrote:
> On Wed, Jul 10, 2019 at 11:26 AM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> >
> > On Wed, Jul 10, 2019 at 10:48:00AM -0700, Nathan Chancellor wrote:
> > > clang warns several times:
> > >
> > > drivers/infiniband/sw/siw/siw_cq.c:31:4: warning: implicit conversion
> > > from enumeration type 'enum siw_wc_status' to different enumeration type
> > > 'enum siw_opcode' [-Wenum-conversion]
> > Weird that gcc doesn't warn on this by default..
>
> Based on the sheer number of -Wenum-conversion that Nathan has fixed,
> I don't think gcc has -Wenum-conversion (or it's somehow disabled just
> for gcc).
> --
> Thanks,
> ~Nick Desaulniers
Yes, as far as I am aware, GCC does not warn on implicit enum
conversions (which I think defeats the purpose of enumerated types
*shrugs*).
Cheers,
Nathan
^ permalink raw reply
* [rdma-core patch] srp_daemon: improve the debug message for is_enabled_by_rules_file
From: Honggang Li @ 2019-07-11 2:40 UTC (permalink / raw)
To: bvanassche; +Cc: linux-rdma, Honggang Li
Signed-off-by: Honggang Li <honli@redhat.com>
---
srp_daemon/srp_daemon.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/srp_daemon/srp_daemon.c b/srp_daemon/srp_daemon.c
index a004f6a4..f27dd569 100644
--- a/srp_daemon/srp_daemon.c
+++ b/srp_daemon/srp_daemon.c
@@ -349,10 +349,11 @@ static int is_enabled_by_rules_file(struct target_details *target)
int rule;
struct config_t *conf = config;
- if (NULL == conf->rules)
+ if (NULL == conf->rules) {
+ pr_debug("SRP target with id_ext %s allowed by rules file\n", target->id_ext);
return 1;
+ }
- pr_debug("Found an SRP target with id_ext %s - check if it allowed by rules file\n", target->id_ext);
rule = -1;
do {
rule++;
@@ -392,6 +393,9 @@ static int is_enabled_by_rules_file(struct target_details *target)
target->options = conf->rules[rule].options;
+ pr_debug("SRP target with id_ext %s %s by rules file\n",
+ target->id_ext,
+ conf->rules[rule].allow == 1 ? "allowed" : "disallowed");
return conf->rules[rule].allow;
} while (1);
--
2.20.1
^ permalink raw reply related
* [PATCH for-rc] RDMA/hns: Fix sg offset non-zero issue
From: Lijun Ou @ 2019-07-11 1:32 UTC (permalink / raw)
To: dledford, jgg; +Cc: leon, linux-rdma, linuxarm
From: Xi Wang <wangxi11@huawei.com>
When run perftest in many times, the system will report a BUG as follows:
[ 2312.559759] BUG: Bad rss-counter state mm:(____ptrval____) idx:0 val:-1
[ 2312.574803] BUG: Bad rss-counter state mm:(____ptrval____) idx:1 val:1
We tested with different kernel version and found it started from the the
following commit:
commit d10bcf947a3e ("RDMA/umem: Combine contiguous PAGE_SIZE regions in
SGEs")
In this commit, the sg->offset is always 0 when sg_set_page() is called in
ib_umem_get() and the drivers are not allowed to change the sgl, otherwise
it will get bad page descriptor when unfolding SGEs in __ib_umem_release()
as sg_page_count() will get wrong result while sgl->offset is not 0.
However, there is a weird sgl usage in the current hns driver, the driver
modified sg->offset after calling ib_umem_get(), which caused we iterate
past the wrong number of pages in for_each_sg_page iterator.
This patch fixes it by correcting the non-standard sgl usage found in the
hns_roce_db_map_user() function.
Fixes: 0425e3e6e0c7 ("RDMA/hns: Support flush cqe for hip08 in kernel space")
Signed-off-by: Xi Wang <wangxi11@huawei.com>
---
drivers/infiniband/hw/hns/hns_roce_db.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/infiniband/hw/hns/hns_roce_db.c b/drivers/infiniband/hw/hns/hns_roce_db.c
index 0c6c1fe..d60453e 100644
--- a/drivers/infiniband/hw/hns/hns_roce_db.c
+++ b/drivers/infiniband/hw/hns/hns_roce_db.c
@@ -12,13 +12,15 @@ int hns_roce_db_map_user(struct hns_roce_ucontext *context,
struct ib_udata *udata, unsigned long virt,
struct hns_roce_db *db)
{
+ unsigned long page_addr = virt & PAGE_MASK;
struct hns_roce_user_db_page *page;
+ unsigned int offset;
int ret = 0;
mutex_lock(&context->page_mutex);
list_for_each_entry(page, &context->page_list, list)
- if (page->user_virt == (virt & PAGE_MASK))
+ if (page->user_virt == page_addr)
goto found;
page = kmalloc(sizeof(*page), GFP_KERNEL);
@@ -28,8 +30,8 @@ int hns_roce_db_map_user(struct hns_roce_ucontext *context,
}
refcount_set(&page->refcount, 1);
- page->user_virt = (virt & PAGE_MASK);
- page->umem = ib_umem_get(udata, virt & PAGE_MASK, PAGE_SIZE, 0, 0);
+ page->user_virt = page_addr;
+ page->umem = ib_umem_get(udata, page_addr, PAGE_SIZE, 0, 0);
if (IS_ERR(page->umem)) {
ret = PTR_ERR(page->umem);
kfree(page);
@@ -39,10 +41,9 @@ int hns_roce_db_map_user(struct hns_roce_ucontext *context,
list_add(&page->list, &context->page_list);
found:
- db->dma = sg_dma_address(page->umem->sg_head.sgl) +
- (virt & ~PAGE_MASK);
- page->umem->sg_head.sgl->offset = virt & ~PAGE_MASK;
- db->virt_addr = sg_virt(page->umem->sg_head.sgl);
+ offset = virt - page_addr;
+ db->dma = sg_dma_address(page->umem->sg_head.sgl) + offset;
+ db->virt_addr = sg_virt(page->umem->sg_head.sgl) + offset;
db->u.user_page = page;
refcount_inc(&page->refcount);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] rdma/siw: Use proper enumerated type in map_cqe_status
From: Nick Desaulniers @ 2019-07-10 23:53 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Nathan Chancellor, Bernard Metzler, Doug Ledford, linux-rdma,
LKML, clang-built-linux
In-Reply-To: <20190710182624.GG4051@ziepe.ca>
On Wed, Jul 10, 2019 at 11:26 AM Jason Gunthorpe <jgg@ziepe.ca> wrote:
>
> On Wed, Jul 10, 2019 at 10:48:00AM -0700, Nathan Chancellor wrote:
> > clang warns several times:
> >
> > drivers/infiniband/sw/siw/siw_cq.c:31:4: warning: implicit conversion
> > from enumeration type 'enum siw_wc_status' to different enumeration type
> > 'enum siw_opcode' [-Wenum-conversion]
> Weird that gcc doesn't warn on this by default..
Based on the sheer number of -Wenum-conversion that Nathan has fixed,
I don't think gcc has -Wenum-conversion (or it's somehow disabled just
for gcc).
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* Re: failed armel build of rdma-core 24.0-1
From: Jason Gunthorpe @ 2019-07-10 19:23 UTC (permalink / raw)
To: Benjamin Drung, Gal Pressman; +Cc: linux-rdma
In-Reply-To: <156275862123.1841.4329369138979653018@wuiet.debian.org>
Benjamin,
Can you confirm that something like this fixes these build problems?
diff --git a/debian/rules b/debian/rules
index 07c9c145ff090c..facb45170eacfc 100755
--- a/debian/rules
+++ b/debian/rules
@@ -63,6 +63,7 @@ ifneq (,$(filter-out $(COHERENT_DMA_ARCHS),$(DEB_HOST_ARCH)))
test -e debian/$$package.install.backup || cp debian/$$package.install debian/$$package.install.backup; \
done
sed -i '/mlx[45]/d' debian/ibverbs-providers.install debian/libibverbs-dev.install debian/rdma-core.install
+ sed -i '/efa/d' debian/ibverbs-providers.install debian/libibverbs-dev.install debian/rdma-core.install
endif
DESTDIR=$(CURDIR)/debian/tmp ninja -C build-deb install
On Wed, Jul 10, 2019 at 11:37:01AM -0000, Debian buildds wrote:
> * Source package: rdma-core
> * Version: 24.0-1
> * Architecture: armel
> * State: failed
> * Suite: sid
> * Builder: antheil.debian.org
> * Build log: https://buildd.debian.org/status/fetch.php?pkg=rdma-core&arch=armel&ver=24.0-1&stamp=1562758620&file=log
>
> Please note that these notifications do not necessarily mean bug reports
> in your package but could also be caused by other packages, temporary
> uninstallabilities and arch-specific breakages. A look at the build log
> despite this disclaimer would be appreciated however.
^ permalink raw reply related
* Re: [PATCH v4 00/25] InfiniBand Transport (IBTRS) and Network Block Device (IBNBD)
From: Sagi Grimberg @ 2019-07-10 19:11 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Danil Kipnis, Jack Wang, linux-block, linux-rdma, axboe,
Christoph Hellwig, bvanassche, dledford, Roman Pen, gregkh
In-Reply-To: <20190710172505.GD4051@ziepe.ca>
>> I still do not understand why this should give any notice-able
>> performance advantage.
>
> Usually omitting invalidations gives a healthy bump.
>
> Also, RDMA WRITE is generally faster than READ at the HW level in
> various ways.
Yes, but this should be essentially identical to running nvme-rdma
with 512KB of immediate-data (the nvme term is in-capsule data).
In the upstream nvme target we have inline_data_size port attribute
that is tunable for that (defaults to PAGE_SIZE).
^ permalink raw reply
* [PATCH] net/mlx5e: Move priv variable into case statement in mlx5e_setup_tc
From: Nathan Chancellor @ 2019-07-10 19:05 UTC (permalink / raw)
To: Saeed Mahameed, Leon Romanovsky, David S. Miller
Cc: netdev, linux-rdma, linux-kernel, clang-built-linux,
Nathan Chancellor
There is an unused variable warning on arm64 defconfig when
CONFIG_MLX5_ESWITCH is unset:
drivers/net/ethernet/mellanox/mlx5/core/en_main.c:3467:21: warning:
unused variable 'priv' [-Wunused-variable]
struct mlx5e_priv *priv = netdev_priv(dev);
^
1 warning generated.
Move it down into the case statement where it is used.
Fixes: 4e95bc268b91 ("net: flow_offload: add flow_block_cb_setup_simple()")
Link: https://github.com/ClangBuiltLinux/linux/issues/597
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index 6d0ae87c8ded..651eb714eb5b 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -3464,15 +3464,16 @@ static LIST_HEAD(mlx5e_block_cb_list);
static int mlx5e_setup_tc(struct net_device *dev, enum tc_setup_type type,
void *type_data)
{
- struct mlx5e_priv *priv = netdev_priv(dev);
-
switch (type) {
#ifdef CONFIG_MLX5_ESWITCH
- case TC_SETUP_BLOCK:
+ case TC_SETUP_BLOCK: {
+ struct mlx5e_priv *priv = netdev_priv(dev);
+
return flow_block_cb_setup_simple(type_data,
&mlx5e_block_cb_list,
mlx5e_setup_tc_block_cb,
priv, priv, true);
+ }
#endif
case TC_SETUP_QDISC_MQPRIO:
return mlx5e_setup_tc_mqprio(dev, type_data);
--
2.22.0
^ permalink raw reply related
* Re: [PATCH] rdma/siw: Use proper enumerated type in map_cqe_status
From: Jason Gunthorpe @ 2019-07-10 18:26 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Bernard Metzler, Doug Ledford, linux-rdma, linux-kernel,
clang-built-linux
In-Reply-To: <20190710174800.34451-1-natechancellor@gmail.com>
On Wed, Jul 10, 2019 at 10:48:00AM -0700, Nathan Chancellor wrote:
> clang warns several times:
>
> drivers/infiniband/sw/siw/siw_cq.c:31:4: warning: implicit conversion
> from enumeration type 'enum siw_wc_status' to different enumeration type
> 'enum siw_opcode' [-Wenum-conversion]
> { SIW_WC_SUCCESS, IB_WC_SUCCESS },
> ~ ^~~~~~~~~~~~~~
>
> Fixes: b0fff7317bb4 ("rdma/siw: completion queue methods")
> Link: https://github.com/ClangBuiltLinux/linux/issues/596
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> drivers/infiniband/sw/siw/siw_cq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Weird that gcc doesn't warn on this by default..
Applied to for-next, thanks
Jason
^ permalink raw reply
* [PATCH] rdma/siw: Use proper enumerated type in map_cqe_status
From: Nathan Chancellor @ 2019-07-10 17:48 UTC (permalink / raw)
To: Bernard Metzler, Doug Ledford, Jason Gunthorpe
Cc: linux-rdma, linux-kernel, clang-built-linux, Nathan Chancellor
clang warns several times:
drivers/infiniband/sw/siw/siw_cq.c:31:4: warning: implicit conversion
from enumeration type 'enum siw_wc_status' to different enumeration type
'enum siw_opcode' [-Wenum-conversion]
{ SIW_WC_SUCCESS, IB_WC_SUCCESS },
~ ^~~~~~~~~~~~~~
Fixes: b0fff7317bb4 ("rdma/siw: completion queue methods")
Link: https://github.com/ClangBuiltLinux/linux/issues/596
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
drivers/infiniband/sw/siw/siw_cq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/sw/siw/siw_cq.c b/drivers/infiniband/sw/siw/siw_cq.c
index e2a0ee40d5b5..e381ae9b7d62 100644
--- a/drivers/infiniband/sw/siw/siw_cq.c
+++ b/drivers/infiniband/sw/siw/siw_cq.c
@@ -25,7 +25,7 @@ static int map_wc_opcode[SIW_NUM_OPCODES] = {
};
static struct {
- enum siw_opcode siw;
+ enum siw_wc_status siw;
enum ib_wc_status ib;
} map_cqe_status[SIW_NUM_WC_STATUS] = {
{ SIW_WC_SUCCESS, IB_WC_SUCCESS },
--
2.22.0
^ permalink raw reply related
* Re: Re: [PATCH] RDMA/siw: Print error code while kthread_create failed
From: Jason Gunthorpe @ 2019-07-10 17:31 UTC (permalink / raw)
To: Bernard Metzler
Cc: Leon Romanovsky, YueHaibing, dledford, linux-kernel, linux-rdma
In-Reply-To: <OFB29B4146.7E46891A-ON00258433.002BBAD4-00258433.002F6CB8@notes.na.collabserv.com>
On Wed, Jul 10, 2019 at 08:38:00AM +0000, Bernard Metzler wrote:
> Right, I agree with Leon. Better remove all those printouts. We
> already have a warning if we cannot start any thread. Also
> stopping those threads is not worth spamming the console. I just
> forgot to remove after Leon's comment. Would it be possible
> to apply the following?
>
> Thanks a lot!
> Bernard.
>
> From e4ca3d4dec86bb5731f8e3cb0cdd01e84b315d80 Mon Sep 17 00:00:00 2001
> From: Bernard Metzler <bmt@zurich.ibm.com>
> Date: Wed, 10 Jul 2019 10:03:17 +0200
> Subject: [PATCH] remove kthread create/destroy printouts
>
> Signed-off-by: Bernard Metzler <bmt@zurich.ibm.com>
> drivers/infiniband/sw/siw/siw_main.c | 4 +---
> drivers/infiniband/sw/siw/siw_qp_tx.c | 4 ----
> 2 files changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/drivers/infiniband/sw/siw/siw_main.c b/drivers/infiniband/sw/siw/siw_main.c
> index fd2552a9091d..f55c4e80aea4 100644
> +++ b/drivers/infiniband/sw/siw/siw_main.c
> @@ -88,7 +88,7 @@ static void siw_device_cleanup(struct ib_device *base_dev)
>
> static int siw_create_tx_threads(void)
> {
> - int cpu, rv, assigned = 0;
> + int cpu, assigned = 0;
>
> for_each_online_cpu(cpu) {
> /* Skip HT cores */
> @@ -99,9 +99,7 @@ static int siw_create_tx_threads(void)
> kthread_create(siw_run_sq, (unsigned long *)(long)cpu,
> "siw_tx/%d", cpu);
> if (IS_ERR(siw_tx_thread[cpu])) {
> - rv = PTR_ERR(siw_tx_thread[cpu]);
> siw_tx_thread[cpu] = NULL;
> - pr_info("Creating TX thread for CPU %d failed", cpu);
> continue;
> }
> kthread_bind(siw_tx_thread[cpu], cpu);
> diff --git a/drivers/infiniband/sw/siw/siw_qp_tx.c b/drivers/infiniband/sw/siw/siw_qp_tx.c
> index 2c3d250ee57c..fff02b56d38a 100644
> +++ b/drivers/infiniband/sw/siw/siw_qp_tx.c
> @@ -1200,8 +1200,6 @@ int siw_run_sq(void *data)
> init_llist_head(&tx_task->active);
> init_waitqueue_head(&tx_task->waiting);
>
> - pr_info("Started siw TX thread on CPU %u\n", nr_cpu);
> -
> while (1) {
> struct llist_node *fifo_list = NULL;
>
> @@ -1239,8 +1237,6 @@ int siw_run_sq(void *data)
> siw_sq_resume(qp);
> }
> }
> - pr_info("Stopped siw TX thread on CPU %u\n", nr_cpu);
> -
> return 0;
> }
Okay, I took this patch to for-next, thanks
Jason
^ permalink raw reply
* Re: [PATCH v4 00/25] InfiniBand Transport (IBTRS) and Network Block Device (IBNBD)
From: Jason Gunthorpe @ 2019-07-10 17:25 UTC (permalink / raw)
To: Sagi Grimberg
Cc: Danil Kipnis, Jack Wang, linux-block, linux-rdma, axboe,
Christoph Hellwig, bvanassche, dledford, Roman Pen, gregkh
In-Reply-To: <c49bf227-5274-9d13-deba-a405c75d1358@grimberg.me>
On Wed, Jul 10, 2019 at 09:25:05AM -0700, Sagi Grimberg wrote:
>
> > > Another question, from what I understand from the code, the client
> > > always rdma_writes data on writes (with imm) from a remote pool of
> > > server buffers dedicated to it. Essentially all writes are immediate (no
> > > rdma reads ever). How is that different than using send wrs to a set of
> > > pre-posted recv buffers (like all others are doing)? Is it faster?
> >
> > RDMA WRITE only is generally a bit faster, and if you use a buffer
> > pool in a smart way it is possible to get very good data packing.
>
> There is no packing, its used exactly as send/recv, but with a remote
> buffer pool (pool of 512K buffers) and the client selects one and rdma
> write with imm to it.
Well that makes little sense then:)
> > Maybe this is fine, but it needs to be made very clear that it uses
> > this insecure operating model to get higher performance..
>
> I still do not understand why this should give any notice-able
> performance advantage.
Usually omitting invalidations gives a healthy bump.
Also, RDMA WRITE is generally faster than READ at the HW level in
various ways.
Jason
^ permalink raw reply
* Re: [PATCH v2] IB/rdmavt: Fix variable shadowing issue in rvt_create_cq
From: Ira Weiny @ 2019-07-10 17:17 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Dennis Dalessandro, Mike Marciniszyn, Doug Ledford,
Jason Gunthorpe, Kamenee Arumugam, linux-rdma, linux-kernel,
clang-built-linux, Nick Desaulniers
In-Reply-To: <20190710170711.GA80444@archlinux-threadripper>
On Wed, Jul 10, 2019 at 10:07:11AM -0700, Nathan Chancellor wrote:
> On Wed, Jul 10, 2019 at 10:03:23AM -0700, Ira Weiny wrote:
> > What version of the kernel was this found on?
> >
> > I don't see the problem with 5.2. AFAICS there is no 'err' in the function
> > scope and the if scoped 'err' is initialized properly on line 239.
> >
> > Ira
> >
>
> $ git describe --contains 239b0e52d8aa
> next-20190709~84^2~57
>
> I should probably be better about adding 'PATCH -next' to my patches,
> sorry for the confusion!
Ah I see it now... Sorry I was just not up to date on the rdma tree. Sorry
about the noise.
Thanks,
Ira
>
> Cheers,
> Nathan
^ permalink raw reply
* Re: [PATCH] [net-next] net/mlx5e: avoid uninitialized variable use
From: Nathan Chancellor @ 2019-07-10 17:14 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Saeed Mahameed, Leon Romanovsky, David S. Miller, Tariq Toukan,
Eran Ben Elisha, Boris Pismenny, netdev, linux-rdma, linux-kernel,
clang-built-linux
In-Reply-To: <20190710130638.1846846-1-arnd@arndb.de>
On Wed, Jul 10, 2019 at 03:06:25PM +0200, Arnd Bergmann wrote:
> clang points to a variable being used in an unexpected
> code path:
>
> drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_tx.c:251:2: warning: variable 'rec_seq_sz' is used uninitialized whenever switch default is taken [-Wsometimes-uninitialized]
> default:
> ^~~~~~~
> drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_tx.c:255:46: note: uninitialized use occurs here
> skip_static_post = !memcmp(rec_seq, &rn_be, rec_seq_sz);
> ^~~~~~~~~~
>
> From looking at the function logic, it seems that there is no
> sensible way to continue here, so just return early and hope
> for the best.
>
> Fixes: d2ead1f360e8 ("net/mlx5e: Add kTLS TX HW offload support")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_tx.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_tx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_tx.c
> index 3f5f4317a22b..5c08891806f0 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_tx.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_tx.c
> @@ -250,6 +250,7 @@ tx_post_resync_params(struct mlx5e_txqsq *sq,
> }
> default:
> WARN_ON(1);
> + return;
> }
>
> skip_static_post = !memcmp(rec_seq, &rn_be, rec_seq_sz);
> --
> 2.20.0
>
Looks like my identical patch got picked up in net-next:
https://git.kernel.org/davem/net-next/c/1ff2f0fa450ea4e4f87793d9ed513098ec6e12be
Good to know the fix was the same.
Cheers,
Nathan
^ permalink raw reply
* Re: [PATCH v2] IB/rdmavt: Fix variable shadowing issue in rvt_create_cq
From: Nathan Chancellor @ 2019-07-10 17:07 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Mike Marciniszyn, Dennis Dalessandro, Doug Ledford,
Kamenee Arumugam, linux-rdma, linux-kernel, clang-built-linux,
Nick Desaulniers
In-Reply-To: <20190710170216.GA15103@ziepe.ca>
On Wed, Jul 10, 2019 at 02:02:16PM -0300, Jason Gunthorpe wrote:
>
> Applied to for-next with Mike's ack
>
> Thanks,
> Jason
Thank you Jason, much appreciated!
Nathan
^ permalink raw reply
* Re: [PATCH v2] IB/rdmavt: Fix variable shadowing issue in rvt_create_cq
From: Nathan Chancellor @ 2019-07-10 17:07 UTC (permalink / raw)
To: Ira Weiny
Cc: Dennis Dalessandro, Mike Marciniszyn, Doug Ledford,
Jason Gunthorpe, Kamenee Arumugam, linux-rdma, linux-kernel,
clang-built-linux, Nick Desaulniers
In-Reply-To: <20190710170322.GA5072@iweiny-DESK2.sc.intel.com>
On Wed, Jul 10, 2019 at 10:03:23AM -0700, Ira Weiny wrote:
> What version of the kernel was this found on?
>
> I don't see the problem with 5.2. AFAICS there is no 'err' in the function
> scope and the if scoped 'err' is initialized properly on line 239.
>
> Ira
>
$ git describe --contains 239b0e52d8aa
next-20190709~84^2~57
I should probably be better about adding 'PATCH -next' to my patches,
sorry for the confusion!
Cheers,
Nathan
^ 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