[PATCH for-next v3 0/2] Introduce rdma_set_min_rnr_timer() and use it in RDS

ib_modify_qp() is an expensive operation on some HCAs running virtualized. This series removes two ib_modify_qp() calls from RDS. I am sending this as a v3, even though it is the first sent to net. This because the IB Core commit has reach v3. Håkon Bugge (2): IB/cma: Introduce

[PATCH for-next v3 2/2] rds: ib: Remove two ib_modify_qp() calls

ace to shave off another ib_modify_qp(). Fixes: ec16227e1414 ("RDS/IB: Infiniband transport") Signed-off-by: Håkon Bugge --- net/rds/ib_cm.c | 35 +-- net/rds/rdma_transport.c | 1 + 2 files changed, 2 insertions(+), 34 deletions(-) diff --git a/net/

[PATCH for-next v3 1/2] IB/cma: Introduce rdma_set_min_rnr_timer()

ime value before retrying the send. The 5-bit value to be supplied to the rdma_set_min_rnr_timer() is documented in IBTA Table 45: "Encoding for RNR NAK Timer Field". Signed-off-by: Håkon Bugge Acked-by: Jason Gunthorpe --- drivers/infiniband/core/cm

Re: [PATCH] IB/uverbs: Fix memleak in ib_uverbs_add_one

> On 21 Aug 2020, at 10:10, Dinghao Liu wrote: > > When ida_alloc_max() fails, uverbs_dev should be freed > just like when init_srcu_struct() fails. It's the same > for the error paths after this call. > > Signed-off-by: Dinghao Liu > --- > drivers/infiniband/core/uverbs_main.c | 1 + > 1

Re: [Linux-kernel-mentees] [PATCH net] rds: Prevent kernel-infoleak in rds_notify_queue_get()

> On 31 Jul 2020, at 13:59, Greg Kroah-Hartman > wrote: > > On Fri, Jul 31, 2020 at 01:14:09PM +0200, Håkon Bugge wrote: >> >> >>> On 31 Jul 2020, at 11:59, Dan Carpenter wrote: >>> >>> On Fri, Jul 31, 2020 at 07:53:01AM +0300, Leon R

Re: [Linux-kernel-mentees] [PATCH net] rds: Prevent kernel-infoleak in rds_notify_queue_get()

> On 31 Jul 2020, at 11:59, Dan Carpenter wrote: > > On Fri, Jul 31, 2020 at 07:53:01AM +0300, Leon Romanovsky wrote: >> On Thu, Jul 30, 2020 at 03:20:26PM -0400, Peilin Ye wrote: >>> rds_notify_queue_get() is potentially copying uninitialized kernel stack >>> memory to userspace since the

[PATCH] RDMA/cma: fix false error message

In addr_handler(), assuming status == 0 and the device already has been acquired (id_priv->cma_dev != NULL), we get the following incorrect "error" message: RDMA CM: ADDR_ERROR: failed to resolve IP. status 0 Signed-off-by: Håkon Bugge --- drivers/infiniband/core/cma.c | 2 +- 1

Re: [PATCH v2] RDMA/cma: Make CM response timeout and # CM retries configurable

> On 13 Jun 2019, at 22:25, Doug Ledford wrote: > > On Thu, 2019-06-13 at 18:58 +0200, Håkon Bugge wrote: >>> On 13 Jun 2019, at 16:25, Doug Ledford wrote: >>> >>> On Tue, 2019-02-26 at 08:57 +0100, Håkon Bugge wrote: >>>> During certain w

Re: [PATCH v2] RDMA/cma: Make CM response timeout and # CM retries configurable

> On 13 Jun 2019, at 16:25, Doug Ledford wrote: > > On Tue, 2019-02-26 at 08:57 +0100, Håkon Bugge wrote: >> During certain workloads, the default CM response timeout is too >> short, leading to excessive retries. Hence, make it configurable >> through sysctl. Wh

Re: [PATCH v2] RDMA/cma: Make CM response timeout and # CM retries configurable

> On 13 Jun 2019, at 19:23, Jason Gunthorpe wrote: > > On Thu, Jun 13, 2019 at 06:58:30PM +0200, Håkon Bugge wrote: > >> If you refer to the backlog parameter in rdma_listen(), I cannot see >> it being used at all for IB. >> >> For CX-3, which

Re: [PATCH] RDMA/mlx4: Spread completion vectors for proxy CQs

> On 10 Jun 2019, at 19:53, Jason Gunthorpe wrote: > > On Mon, Feb 18, 2019 at 07:33:02PM +0100, Håkon Bugge wrote: >> MAD packet sending/receiving is not properly virtualized in >> CX-3. Hence, these are proxied through the PF driver. The proxying >> uses

[PATCH v2] RDMA/cma: Make CM response timeout and # CM retries configurable

During certain workloads, the default CM response timeout is too short, leading to excessive retries. Hence, make it configurable through sysctl. While at it, also make number of CM retries configurable. The defaults are not changed. Signed-off-by: Håkon Bugge --- v1 -> v2: * Ad

Re: [PATCH] RDMA/cma: Make CM response timeout and # CM retries configurable

son Gunthorpe wrote: >>>> On Sun, Feb 17, 2019 at 06:09:09PM +0100, Håkon Bugge wrote: >>>>> During certain workloads, the default CM response timeout is too >>>>> short, leading to excessive retries. Hence, make it configurable >>>>>

Re: [PATCH] RDMA/mlx4: Spread completion vectors for proxy CQs

> On 20 Feb 2019, at 18:14, Jason Gunthorpe wrote: > > On Tue, Feb 19, 2019 at 06:32:50PM +0100, Håkon Bugge wrote: >> Anyway, Jason mentioned in a private email that maybe we could use the >> new completion API or something? I am not familiar with that one >>

[PATCH] RDMA/mlx4: Spread completion vectors for proxy CQs

:4, num_comp_vectors:62 create_pv_resources: slave:1 port:2, vector:5, num_comp_vectors:62 [] create_pv_resources: slave:8 port:2, vector:18, num_comp_vectors:62 create_pv_resources: slave:8 port:1, vector:19, num_comp_vectors:62 Signed-off-by: Håkon Bugge --- drivers/infiniband/hw/mlx4/mad.c | 4

[PATCH] RDMA/cma: Make CM response timeout and # CM retries configurable

During certain workloads, the default CM response timeout is too short, leading to excessive retries. Hence, make it configurable through sysctl. While at it, also make number of CM retries configurable. The defaults are not changed. Signed-off-by: Håkon Bugge --- drivers/infiniband/core/cma.c

[PATCH v2] IB/mlx4: Increase the timeout for CM cache

help, as these duplicates and retries stems from a too short CMA timeout, which was 20 (~4 seconds) on the systems. By increasing the CMA timeout to 22 (~17 seconds), the numbers fell down to about 10 for both of them. Adjustment of the CMA timeout is not part of this commit. Signed-off-by: Håkon

Re: [PATCH] mlx4_ib: Increase the timeout for CM cache

> On 6 Feb 2019, at 19:02, jackm wrote: > > On Wed, 6 Feb 2019 16:40:14 +0100 > Håkon Bugge wrote: > >> Jack, >> >> A major contributor to the long processing time in the PF driver >> proxying QP1 packets is: >> >> c

Re: [PATCH] mlx4_ib: Increase the timeout for CM cache

> On 6 Feb 2019, at 09:50, Håkon Bugge wrote: > > > >> On 5 Feb 2019, at 23:36, Jason Gunthorpe wrote: >> >> On Thu, Jan 31, 2019 at 06:09:51PM +0100, Håkon Bugge wrote: >>> Using CX-3 virtual functions, either from a bare-metal machine or

Re: [PATCH] mlx4_ib: Increase the timeout for CM cache

> On 5 Feb 2019, at 23:36, Jason Gunthorpe wrote: > > On Thu, Jan 31, 2019 at 06:09:51PM +0100, Håkon Bugge wrote: >> Using CX-3 virtual functions, either from a bare-metal machine or >> pass-through from a VM, MAD packets are proxied through the PF driver. >> >

Re: [PATCH] mlx4_ib: Increase the timeout for CM cache

Sorry, I posted this as if it a net patch. It isn't, hence resend with correct recipients. Thxs, Håkon > On 31 Jan 2019, at 18:09, Håkon Bugge wrote: > > Using CX-3 virtual functions, either from a bare-metal machine or > pass-through from a VM, MAD packets are proxied th

[PATCH] mlx4_ib: Increase the timeout for CM cache

fell down to about one hundred for both of them. Adjustment of the CMA timeout is _not_ part of this commit. Signed-off-by: Håkon Bugge --- drivers/infiniband/hw/mlx4/cm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/infiniband/hw/mlx4/cm.c b/drivers/infiniband/hw

[PATCH v2 2/2] net: if_arp: use define instead of hard-coded value

Let uapi/linux/if_arp.h include uapi/linux/if.h, where IFNAMSIZ is defined. Then, use it in this file instead of hard-coded value. This way, we are using an uapi defined constant, and as such, user-space should be good. Signed-off-by: Håkon Bugge Tested-by: Stephen Hemminger --- v1 ->

[PATCH v2 2/2] net: if_arp: use define instead of hard-coded value

Let uapi/linux/if_arp.h include uapi/linux/if.h, where IFNAMSIZ is defined. Then, use it in this file instead of hard-coded value. This way, we are using an uapi defined constant, and as such, user-space should be good. Signed-off-by: Håkon Bugge Tested-by: Stephen Hemminger --- v1 ->

[PATCH v3 2/2] IB/mlx4: Add port and TID to MAD debug print

Add said information and make the debug print format consistent. Signed-off-by: Håkon Bugge Acked-by: Leon Romanovsky --- v1 -> v2: * Fixed incorrect format for printing the TID v2 -> v3: * Added Leon's a-b --- drivers/infiniband/hw/mlx4/mad.c | 18 ++ 1 file c

[PATCH v3 2/2] IB/mlx4: Add port and TID to MAD debug print

Add said information and make the debug print format consistent. Signed-off-by: Håkon Bugge Acked-by: Leon Romanovsky --- v1 -> v2: * Fixed incorrect format for printing the TID v2 -> v3: * Added Leon's a-b --- drivers/infiniband/hw/mlx4/mad.c | 18 ++ 1 file c

[PATCH v3 1/2] IB/mlx4: Enable debug print of SMPs

IB Subnet Management Packets (SMPs) were excluded from debug prints. Fixed by enabling print even on QP0 MADs. Signed-off-by: Håkon Bugge --- v1 -> v3: * No changes --- drivers/infiniband/hw/mlx4/mad.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/infinib

[PATCH v3 1/2] IB/mlx4: Enable debug print of SMPs

IB Subnet Management Packets (SMPs) were excluded from debug prints. Fixed by enabling print even on QP0 MADs. Signed-off-by: Håkon Bugge --- v1 -> v3: * No changes --- drivers/infiniband/hw/mlx4/mad.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/infinib

[PATCH v3 0/2] IB/mlx4: Enable debug print of SMPs and enhance output for MADs

SMPs were not printed at all. Added printing of port number and TID to all MADs Håkon Bugge (2): IB/mlx4: Enable debug print of SMPs IB/mlx4: Add port and TID to MAD debug print drivers/infiniband/hw/mlx4/mad.c | 20 +++- 1 file changed, 11 insertions(+), 9 deletions

[PATCH v3 0/2] IB/mlx4: Enable debug print of SMPs and enhance output for MADs

SMPs were not printed at all. Added printing of port number and TID to all MADs Håkon Bugge (2): IB/mlx4: Enable debug print of SMPs IB/mlx4: Add port and TID to MAD debug print drivers/infiniband/hw/mlx4/mad.c | 20 +++- 1 file changed, 11 insertions(+), 9 deletions

Bug introduced by commit ebeeb1ad9b8a

Hi Greg, I hope you will find this note appropriate. The stable cherry-pick of upstream commit ebeeb1ad9b8a ("rds: tcp: use rds_destroy_pending() to synchronize netns/module teardown and rds connection/workq management") provokes the following stack trace when running with debug: kernel:

Bug introduced by commit ebeeb1ad9b8a

Hi Greg, I hope you will find this note appropriate. The stable cherry-pick of upstream commit ebeeb1ad9b8a ("rds: tcp: use rds_destroy_pending() to synchronize netns/module teardown and rds connection/workq management") provokes the following stack trace when running with debug: kernel:

[PATCH v2 0/2] IB/mlx4: Enable debug print of SMPs and enhance output for MADs

SMPs were not printed at all. Added printing of port number and TID to all MADs Håkon Bugge (2): IB/mlx4: Enable debug print of SMPs IB/mlx4: Add port and TID to MAD debug print drivers/infiniband/hw/mlx4/mad.c | 20 +++- 1 file changed, 11 insertions(+), 9 deletions

[PATCH v2 0/2] IB/mlx4: Enable debug print of SMPs and enhance output for MADs

SMPs were not printed at all. Added printing of port number and TID to all MADs Håkon Bugge (2): IB/mlx4: Enable debug print of SMPs IB/mlx4: Add port and TID to MAD debug print drivers/infiniband/hw/mlx4/mad.c | 20 +++- 1 file changed, 11 insertions(+), 9 deletions

[PATCH v2 2/2] IB/mlx4: Add port and TID to MAD debug print

Add said information and make the debug print format consistent. Signed-off-by: Håkon Bugge -- v1 -> v2 * Fixed incorrect format for printing the TID --- drivers/infiniband/hw/mlx4/mad.c | 18 ++ 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/driv

[PATCH 1/2] IB/mlx4: Enable debug print of SMPs

IB Subnet Management Packets (SMPs) were excluded from debug prints. Fixed by enabling print even on QP0 MADs. Signed-off-by: Håkon Bugge --- drivers/infiniband/hw/mlx4/mad.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/infiniband/hw/mlx4/mad.c b/drivers

[PATCH v2 2/2] IB/mlx4: Add port and TID to MAD debug print

Add said information and make the debug print format consistent. Signed-off-by: Håkon Bugge -- v1 -> v2 * Fixed incorrect format for printing the TID --- drivers/infiniband/hw/mlx4/mad.c | 18 ++ 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/driv

[PATCH 1/2] IB/mlx4: Enable debug print of SMPs

IB Subnet Management Packets (SMPs) were excluded from debug prints. Fixed by enabling print even on QP0 MADs. Signed-off-by: Håkon Bugge --- drivers/infiniband/hw/mlx4/mad.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/infiniband/hw/mlx4/mad.c b/drivers

[PATCH 0/2] IB/mlx4: Enable debug print of SMPs and enhance output for MADs

SMPs were not printed at all. Added printing of port number and TID to all MADs Håkon Bugge (2): IB/mlx4: Enable debug print of SMPs IB/mlx4: Add port and TID to MAD debug print drivers/infiniband/hw/mlx4/mad.c | 20 +++- 1 file changed, 11 insertions(+), 9 deletions

[PATCH 0/2] IB/mlx4: Enable debug print of SMPs and enhance output for MADs

SMPs were not printed at all. Added printing of port number and TID to all MADs Håkon Bugge (2): IB/mlx4: Enable debug print of SMPs IB/mlx4: Add port and TID to MAD debug print drivers/infiniband/hw/mlx4/mad.c | 20 +++- 1 file changed, 11 insertions(+), 9 deletions

[PATCH 1/2] IB/mlx4: Enable debug print of SMPs

IB Subnet Management Packets (SMPs) were excluded from debug prints. Fixed by enabling print even on QP0 MADs. Signed-off-by: Håkon Bugge --- drivers/infiniband/hw/mlx4/mad.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/infiniband/hw/mlx4/mad.c b/drivers

[PATCH 2/2] IB/mlx4: Add port and TID to MAD debug print

Add said information and make the debug print format consistent. Signed-off-by: Håkon Bugge --- drivers/infiniband/hw/mlx4/mad.c | 18 ++ 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/drivers/infiniband/hw/mlx4/mad.c b/drivers/infiniband/hw/mlx4/mad.c index

[PATCH 1/2] IB/mlx4: Enable debug print of SMPs

IB Subnet Management Packets (SMPs) were excluded from debug prints. Fixed by enabling print even on QP0 MADs. Signed-off-by: Håkon Bugge --- drivers/infiniband/hw/mlx4/mad.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/infiniband/hw/mlx4/mad.c b/drivers

[PATCH 2/2] IB/mlx4: Add port and TID to MAD debug print

Add said information and make the debug print format consistent. Signed-off-by: Håkon Bugge --- drivers/infiniband/hw/mlx4/mad.c | 18 ++ 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/drivers/infiniband/hw/mlx4/mad.c b/drivers/infiniband/hw/mlx4/mad.c index

[PATCH] RDMA/i40iw: Fix incorrect iterator type

Commit f27b4746f378 ("i40iw: add connection management code") uses an incorrect rcu iterator, whilst holding the rtnl_lock. Since the critical region invokes i40iw_manage_qhash(), which is a sleeping function, the rcu locking and traversal cannot be used. Signed-off-by: Håkon Bugge --

[PATCH] RDMA/i40iw: Fix incorrect iterator type

Commit f27b4746f378 ("i40iw: add connection management code") uses an incorrect rcu iterator, whilst holding the rtnl_lock. Since the critical region invokes i40iw_manage_qhash(), which is a sleeping function, the rcu locking and traversal cannot be used. Signed-off-by: Håkon Bugge --

mutex and rcu list traversal idiosyncrasy

Hi Faisal, In commit f27b4746f378 ("i40iw: add connection management code") you have in i40iw_add_mqh_6(): rtnl_lock(); for_each_netdev_rcu(...) { [] } rtnl_unlock(); Shouldn't this read: rtnl_lock(); for_each_netdev(...) { [] } rtnl_unlock(); or rcu_read_lock();

mutex and rcu list traversal idiosyncrasy

Hi Faisal, In commit f27b4746f378 ("i40iw: add connection management code") you have in i40iw_add_mqh_6(): rtnl_lock(); for_each_netdev_rcu(...) { [] } rtnl_unlock(); Shouldn't this read: rtnl_lock(); for_each_netdev(...) { [] } rtnl_unlock(); or rcu_read_lock();

Re: [PATCH] IPoIB: use kvzalloc to allocate an array of bucket pointers

tion and could be >> safely allocated by vmalloc. >> >> Signed-off-by: Jan Dakinevich lgtm, Reviewed-by: Håkon Bugge Thxs, Håkon >> --- >> drivers/infiniband/ulp/ipoib/ipoib_main.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> &

Re: [PATCH] IPoIB: use kvzalloc to allocate an array of bucket pointers

tion and could be >> safely allocated by vmalloc. >> >> Signed-off-by: Jan Dakinevich lgtm, Reviewed-by: Håkon Bugge Thxs, Håkon >> --- >> drivers/infiniband/ulp/ipoib/ipoib_main.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> &

[PATCH] IB/cm: Remove unused and erroneous msg sequence encoding

Signed-off-by: Håkon Bugge --- drivers/infiniband/core/cm.c | 14 ++ drivers/infiniband/core/cm_msgs.h | 7 --- 2 files changed, 6 insertions(+), 15 deletions(-) diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c index de699f67a755..4724cb09b69d 100644 ---

[PATCH] IB/cm: Remove unused and erroneous msg sequence encoding

Signed-off-by: Håkon Bugge --- drivers/infiniband/core/cm.c | 14 ++ drivers/infiniband/core/cm_msgs.h | 7 --- 2 files changed, 6 insertions(+), 15 deletions(-) diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c index de699f67a755..4724cb09b69d 100644 ---

Re: [PATCH v3 2/2] IB/mad: Use ID allocator routines to allocate agent number

> On 7 Jun 2018, at 17:37, Matthew Wilcox wrote: > > Why do you need the ID to increment like this? Why can't you just use a > unique ID? Hans first patch did that, but it was "beaten" up. Turns out, MAD packets can be hiding and lingering in the fabric, hence, when an ID is released

Re: [PATCH v3 2/2] IB/mad: Use ID allocator routines to allocate agent number

> On 7 Jun 2018, at 17:37, Matthew Wilcox wrote: > > Why do you need the ID to increment like this? Why can't you just use a > unique ID? Hans first patch did that, but it was "beaten" up. Turns out, MAD packets can be hiding and lingering in the fabric, hence, when an ID is released

Re: [PATCH] IB/mad: Use ID allocator routines to allocate agent number

> On 31 May 2018, at 00:09, Jason Gunthorpe wrote: > > On Wed, May 30, 2018 at 10:07:16PM +0200, Håkon Bugge wrote: >> >> >>> On 30 May 2018, at 17:10, Jason Gunthorpe wrote: >>> >>> On Wed, May 30, 2018 at 02:22:56PM +0200, Hans Westgaa

Re: [PATCH] IB/mad: Use ID allocator routines to allocate agent number

> On 31 May 2018, at 00:09, Jason Gunthorpe wrote: > > On Wed, May 30, 2018 at 10:07:16PM +0200, Håkon Bugge wrote: >> >> >>> On 30 May 2018, at 17:10, Jason Gunthorpe wrote: >>> >>> On Wed, May 30, 2018 at 02:22:56PM +0200, Hans Westgaa

Re: [PATCH] IB/mad: Use ID allocator routines to allocate agent number

> On 30 May 2018, at 17:10, Jason Gunthorpe wrote: > > On Wed, May 30, 2018 at 02:22:56PM +0200, Hans Westgaard Ry wrote: > >> We came up with this code snippet which we think handles both preventing >> immediate re-use and too big/wrapping... > > Isn't this basically the same as

Re: [PATCH] IB/mad: Use ID allocator routines to allocate agent number

> On 30 May 2018, at 17:10, Jason Gunthorpe wrote: > > On Wed, May 30, 2018 at 02:22:56PM +0200, Hans Westgaard Ry wrote: > >> We came up with this code snippet which we think handles both preventing >> immediate re-use and too big/wrapping... > > Isn't this basically the same as

Re: [PATCH] IB/mad: Use ID allocator routines to allocate agent number

> On 29 May 2018, at 18:40, Jason Gunthorpe wrote: > > On Tue, May 29, 2018 at 06:16:14PM +0200, Håkon Bugge wrote: >> >>> On 29 May 2018, at 17:49, Jason Gunthorpe wrote: >>> >>> On Tue, May 29, 2018 at 09:38:08AM +0200, Hans Westgaard Ry wrote:

Re: [PATCH] IB/mad: Use ID allocator routines to allocate agent number

> On 29 May 2018, at 18:40, Jason Gunthorpe wrote: > > On Tue, May 29, 2018 at 06:16:14PM +0200, Håkon Bugge wrote: >> >>> On 29 May 2018, at 17:49, Jason Gunthorpe wrote: >>> >>> On Tue, May 29, 2018 at 09:38:08AM +0200, Hans Westgaard Ry wrote:

Re: [PATCH] IB/mad: Use ID allocator routines to allocate agent number

> On 29 May 2018, at 17:49, Jason Gunthorpe wrote: > > On Tue, May 29, 2018 at 09:38:08AM +0200, Hans Westgaard Ry wrote: >> The agent TID is a 64 bit value split in two dwords. The least >> significant dword is the TID running counter. The most significant >> dword is the agent number. In

Re: [PATCH] IB/mad: Use ID allocator routines to allocate agent number

> On 29 May 2018, at 17:49, Jason Gunthorpe wrote: > > On Tue, May 29, 2018 at 09:38:08AM +0200, Hans Westgaard Ry wrote: >> The agent TID is a 64 bit value split in two dwords. The least >> significant dword is the TID running counter. The most significant >> dword is the agent number. In

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

> On 16 May 2018, at 20:01, Jason Gunthorpe <j...@ziepe.ca> wrote: > > On Wed, May 16, 2018 at 07:46:10PM +0200, Håkon Bugge wrote: > >> OK. Lets take one example. The pkey table contains 0x, 0x8001, >> 0x0001. >> >> The wce.pkey_index is

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

> On 16 May 2018, at 20:01, Jason Gunthorpe wrote: > > On Wed, May 16, 2018 at 07:46:10PM +0200, Håkon Bugge wrote: > >> OK. Lets take one example. The pkey table contains 0x, 0x8001, >> 0x0001. >> >> The wce.pkey_index is 1 (i.e

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

> On 15 May 2018, at 21:04, Jason Gunthorpe <j...@ziepe.ca> wrote: > > On Tue, May 15, 2018 at 08:11:09PM +0200, Håkon Bugge wrote: >>> On 15 May 2018, at 02:38, Hal Rosenstock <h...@dev.mellanox.co.il> wrote: >>> >>> On 5/14/2018 5:02 PM, Jason

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

> On 15 May 2018, at 21:04, Jason Gunthorpe wrote: > > On Tue, May 15, 2018 at 08:11:09PM +0200, Håkon Bugge wrote: >>> On 15 May 2018, at 02:38, Hal Rosenstock wrote: >>> >>> On 5/14/2018 5:02 PM, Jason Gunthorpe wrote: >>>> On Thu, May

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

> On 15 May 2018, at 02:38, Hal Rosenstock <h...@dev.mellanox.co.il> wrote: > > On 5/14/2018 5:02 PM, Jason Gunthorpe wrote: >> On Thu, May 10, 2018 at 05:16:28PM +0200, Håkon Bugge wrote: >> >>> We are talking about two things here. The PKey in the BTH an

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

> On 15 May 2018, at 02:38, Hal Rosenstock wrote: > > On 5/14/2018 5:02 PM, Jason Gunthorpe wrote: >> On Thu, May 10, 2018 at 05:16:28PM +0200, Håkon Bugge wrote: >> >>> We are talking about two things here. The PKey in the BTH and the >>> PKey in the

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

> On 10 May 2018, at 18:54, Hal Rosenstock <h...@dev.mellanox.co.il> wrote: > > On 5/10/2018 11:16 AM, Håkon Bugge wrote: >> >> >>> On 10 May 2018, at 16:01, Hal Rosenstock <h...@dev.mellanox.co.il> wrote: >>> >>> On 5/10/2018

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

> On 10 May 2018, at 18:54, Hal Rosenstock wrote: > > On 5/10/2018 11:16 AM, Håkon Bugge wrote: >> >> >>> On 10 May 2018, at 16:01, Hal Rosenstock wrote: >>> >>> On 5/10/2018 5:16 AM, Håkon Bugge wrote: >>>> >>>> &

Re: [PATCH] mlx4_core: allocate 4KB ICM chunks

> On 11 May 2018, at 01:31, Qing Huang wrote: > > When a system is under memory presure (high usage with fragments), > the original 256KB ICM chunk allocations will likely trigger kernel > memory management to enter slow path doing memory compact/migration > ops in order

Re: [PATCH] mlx4_core: allocate 4KB ICM chunks

> On 11 May 2018, at 01:31, Qing Huang wrote: > > When a system is under memory presure (high usage with fragments), > the original 256KB ICM chunk allocations will likely trigger kernel > memory management to enter slow path doing memory compact/migration > ops in order to complete high order

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

> On 10 May 2018, at 16:01, Hal Rosenstock <h...@dev.mellanox.co.il> wrote: > > On 5/10/2018 5:16 AM, Håkon Bugge wrote: >> >> >>> On 9 May 2018, at 13:28, Hal Rosenstock <h...@dev.mellanox.co.il> wrote: >>> >>> On 5/9/2018 5:30 AM

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

> On 10 May 2018, at 16:01, Hal Rosenstock wrote: > > On 5/10/2018 5:16 AM, Håkon Bugge wrote: >> >> >>> On 9 May 2018, at 13:28, Hal Rosenstock wrote: >>> >>> On 5/9/2018 5:30 AM, Håkon Bugge wrote: >>>> There is no point in

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

> On 9 May 2018, at 13:28, Hal Rosenstock <h...@dev.mellanox.co.il> wrote: > > On 5/9/2018 5:30 AM, Håkon Bugge wrote: >> There is no point in using RDMA CM to establish a connection between >> two QPs that cannot possible communicate. Particularly, if both the >

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

> On 9 May 2018, at 13:28, Hal Rosenstock wrote: > > On 5/9/2018 5:30 AM, Håkon Bugge wrote: >> There is no point in using RDMA CM to establish a connection between >> two QPs that cannot possible communicate. Particularly, if both the >> active and pas

[PATCH IB/core 0/2] Do not form IB connections between limited partition members

to the first commit in the second commit message with a correct 12 chars SHA] Håkon Bugge (2): IB/core: A full pkey is required to match a limited one IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys drivers/infiniband/core/cache.c | 32

[PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

s the full-member bit. In the limited-to-limited case, this will prohibit the connection to be formed, and thus, Pkey Violation Traps will not be sent to the SM. Signed-off-by: Håkon Bugge <haakon.bu...@oracle.com> --- drivers/infiniband/core/cm.c | 39 -

[PATCH IB/core 0/2] Do not form IB connections between limited partition members

to the first commit in the second commit message with a correct 12 chars SHA] Håkon Bugge (2): IB/core: A full pkey is required to match a limited one IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys drivers/infiniband/core/cache.c | 32

[PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

s the full-member bit. In the limited-to-limited case, this will prohibit the connection to be formed, and thus, Pkey Violation Traps will not be sent to the SM. Signed-off-by: Håkon Bugge --- drivers/infiniband/core/cm.c | 39 --- include/rdma/ib_cm.h |

[PATCH IB/core 1/2] IB/core: A full pkey is required to match a limited one

() is introduced, which requires at least one of the pkeys to be a full member, in order to return success. Signed-off-by: Håkon Bugge <haakon.bu...@oracle.com> --- drivers/infiniband/core/cache.c | 32 +++- include/rdma/ib_cache.h | 18 ++ 2 files c

[PATCH IB/core 1/2] IB/core: A full pkey is required to match a limited one

() is introduced, which requires at least one of the pkeys to be a full member, in order to return success. Signed-off-by: Håkon Bugge --- drivers/infiniband/core/cache.c | 32 +++- include/rdma/ib_cache.h | 18 ++ 2 files changed, 45 insertions(+), 5

Re: [PATCH] IB/core: Make ib_mad_client_id atomic

D >> usage), and as the rdma-core user space API for /dev/umad devices >> implies unique TIDs even across ports, make the TID an atomic type so >> that no two allocations, regardless of port number, will be the same. >> >> Signed-off-by: Håkon Bugge <haakon.bu...@oracle.com

Re: [PATCH] IB/core: Make ib_mad_client_id atomic

le for two threads on different ports to end up with the same >> TID. >> >> As this can be confusing (regardless of it being legal according to >> the IB Spec 1.3, C13-18.1.1, in section 13.4.6.4 - TransactionID >> usage), and as the rdma-core user space API for /de

Re: [PATCH] IB/core: Make ib_mad_client_id atomic

> On 27 Apr 2018, at 21:08, Doug Ledford <dledf...@redhat.com> wrote: > > On Thu, 2018-04-26 at 20:51 +0200, Håkon Bugge wrote: >>> Jason is out this week. I'll end up processing this one (probably later >>> today). But I’ll fix up the commit message to suit

Re: [PATCH] IB/core: Make ib_mad_client_id atomic

> On 27 Apr 2018, at 21:08, Doug Ledford wrote: > > On Thu, 2018-04-26 at 20:51 +0200, Håkon Bugge wrote: >>> Jason is out this week. I'll end up processing this one (probably later >>> today). But I’ll fix up the commit message to suit my tastes when I do. >

Re: [PATCH] IB/core: Make ib_mad_client_id atomic

> On 23 Apr 2018, at 21:16, jackm <ja...@dev.mellanox.co.il> wrote: > > On Mon, 23 Apr 2018 16:19:57 +0200 > Håkon Bugge <haakon.bu...@oracle.com> wrote: > > >>> >>> This actually looks like a genuine bug, why is it described only as >>

Re: [PATCH] IB/core: Make ib_mad_client_id atomic

> On 23 Apr 2018, at 21:16, jackm wrote: > > On Mon, 23 Apr 2018 16:19:57 +0200 > Håkon Bugge wrote: > > >>> >>> This actually looks like a genuine bug, why is it described only as >>> 'confusing'? ib_register_mad_agent is callable from usersp

Re: [PATCH] rds: ib: Fix missing call to rds_ib_dev_put in rds_ib_setup_qp

ling done in > commit 3b12f73a5c29 ("rds: ib: add error handle") > > Signed-off-by: Dag Moxnes <dag.mox...@oracle.com> Reviewed-by: Håkon Bugge <haakon.bu...@oracle.com> Thxs, Håkon > --- > net/rds/ib_cm.c |3 ++- > 1 files changed, 2 insertions(+), 1 del

Re: [PATCH] rds: ib: Fix missing call to rds_ib_dev_put in rds_ib_setup_qp

c29 ("rds: ib: add error handle") > > Signed-off-by: Dag Moxnes Reviewed-by: Håkon Bugge Thxs, Håkon > --- > net/rds/ib_cm.c |3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/net/rds/ib_cm.c b/net/rds/ib_cm.c > index eea1d86..13

Re: [PATCH] IB/core: Make ib_mad_client_id atomic

+Jack > On 20 Apr 2018, at 17:34, Jason Gunthorpe <j...@ziepe.ca> wrote: > > On Thu, Apr 19, 2018 at 11:55:55PM -0400, Doug Ledford wrote: >> On Wed, 2018-04-18 at 16:24 +0200, Håkon Bugge wrote: >>> Two kernel threads may get the same value for agent.hi_tid, if

Re: [PATCH] IB/core: Make ib_mad_client_id atomic

+Jack > On 20 Apr 2018, at 17:34, Jason Gunthorpe wrote: > > On Thu, Apr 19, 2018 at 11:55:55PM -0400, Doug Ledford wrote: >> On Wed, 2018-04-18 at 16:24 +0200, Håkon Bugge wrote: >>> Two kernel threads may get the same value for agent.hi_tid, if the >>> ag

[PATCH] IB/core: Make ib_mad_client_id atomic

Two kernel threads may get the same value for agent.hi_tid, if the agents are registered for different ports. As of now, this works, as the agent list is per port. It is however confusing and not future robust. Hence, making it atomic. Signed-off-by: Håkon Bugge <haakon.bu...@oracle.

[PATCH] IB/core: Make ib_mad_client_id atomic

Two kernel threads may get the same value for agent.hi_tid, if the agents are registered for different ports. As of now, this works, as the agent list is per port. It is however confusing and not future robust. Hence, making it atomic. Signed-off-by: Håkon Bugge Reviewed-by: Jack Morgenstein

[PATCH net] rds: Fix NULL pointer dereference in __rds_rdma_map

02 00 00 48 89 55 d0 48 89 4d c8 85 c0 0f 84 2d 03 00 00 48 8b 87 00 03 00 00 <48> 83 b8 c0 00 00 00 00 0f 84 25 03 00 0 0 48 8b 06 48 8b 56 08 The fix is to check the existence of an underlying transport in __rds_rdma_map(). Signed-off-by: Håkon Bugge <haakon.bu...@oracle.com> Reporte

[PATCH net] rds: Fix NULL pointer dereference in __rds_rdma_map

02 00 00 48 89 55 d0 48 89 4d c8 85 c0 0f 84 2d 03 00 00 48 8b 87 00 03 00 00 <48> 83 b8 c0 00 00 00 00 0f 84 25 03 00 0 0 48 8b 06 48 8b 56 08 The fix is to check the existence of an underlying transport in __rds_rdma_map(). Signed-off-by: Håkon Bugge Reported-by: syzbot --- net/rds/rdma

[PATCH net] rds: ib: Fix NULL pointer dereference in debug code

The fix is simply to move the rdsdebug() statement up before the ib_post_recv() and remove the printing of ret, which is taken care of anyway by the non-debug code. Signed-off-by: Håkon Bugge <haakon.bu...@oracle.com> Reviewed-by: Knut Omang <knut.om...@oracle.com> Reviewed-by: Wei Lin Gua

[PATCH net] rds: ib: Fix NULL pointer dereference in debug code

The fix is simply to move the rdsdebug() statement up before the ib_post_recv() and remove the printing of ret, which is taken care of anyway by the non-debug code. Signed-off-by: Håkon Bugge Reviewed-by: Knut Omang Reviewed-by: Wei Lin Guay --- net/rds/ib_recv.c | 10 +- 1 file changed, 5 inser

[PATCH] rds: ib: Fix uninitialized variable

send_flags needs to be initialized before calling rds_ib_set_wr_signal_state(). Signed-off-by: Håkon Bugge <haakon.bu...@oracle.com> Acked-by: Santosh Shilimkar <santosh.shilim...@oracle.com> --- net/rds/ib_send.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/rds/ib_send

[PATCH] rds: ib: Fix uninitialized variable

send_flags needs to be initialized before calling rds_ib_set_wr_signal_state(). Signed-off-by: Håkon Bugge Acked-by: Santosh Shilimkar --- net/rds/ib_send.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/rds/ib_send.c b/net/rds/ib_send.c index 6ab39db..8f46755 100644 --- a/net/rds

  1   2   >