RE: [PATCH] [net-next] IB/hfi1: removed shadowed 'err' variable

> Subject: [PATCH] [net-next] IB/hfi1: removed shadowed 'err' variable > > I can't think of any reason for the inner variable declaration, so > remove it to avoid the issue. > I agree! > Fixes: 239b0e52d8aa ("IB/hfi1: Move rvt_cq_wc struct into uapi directory") Thanks for catching this!

RE: [PATCH -next] IB/qib: Add missing err handle for qib_user_sdma_rb_insert

> diff --git a/drivers/infiniband/hw/qib/qib_user_sdma.c > b/drivers/infiniband/hw/qib/qib_user_sdma.c > index 31c523b..e87c0a7 100644 > --- a/drivers/infiniband/hw/qib/qib_user_sdma.c > +++ b/drivers/infiniband/hw/qib/qib_user_sdma.c > @@ -237,6 +237,8 @@ qib_user_sdma_queue_create(struct device

RE: [PATCH] IB/qib: remove redundant setting of any in for-loop

> > Doug, do you want a tested patch from me? > > Preferably, yes :-) > These patches are in a two patch series: https://marc.info/?l=linux-rdma=151069497506923=2 The first is Colin's warning fix and the second is Joe's cleanup. My value add is the testing. :) They pass our psm testing.

RE: [PATCH] IB/qib: remove redundant setting of any in for-loop

> > Doug, do you want a tested patch from me? > > Preferably, yes :-) > These patches are in a two patch series: https://marc.info/?l=linux-rdma=151069497506923=2 The first is Colin's warning fix and the second is Joe's cleanup. My value add is the testing. :) They pass our psm testing.

RE: [PATCH] IB/qib: remove redundant setting of any in for-loop

> > On Fri, 2017-10-20 at 09:21 +0200, Colin King wrote: > > > From: Colin Ian King > > > > > > The variable all is being set but is never read after this > > > hence it can be removed from the for loop initialization. > > > Cleans up clang warning: > > > > any is really

RE: [PATCH] IB/qib: remove redundant setting of any in for-loop

> > On Fri, 2017-10-20 at 09:21 +0200, Colin King wrote: > > > From: Colin Ian King > > > > > > The variable all is being set but is never read after this > > > hence it can be removed from the for loop initialization. > > > Cleans up clang warning: > > > > any is really used as bool and is

RE: [PATCH 4.4 29/57] RDMA/uverbs: Check port number supplied by user verbs cmds

> it should be broken, see the patches submitted already to fix it :) I saw that and responded with Tested-by: Mike

RE: [PATCH 4.4 29/57] RDMA/uverbs: Check port number supplied by user verbs cmds

> it should be broken, see the patches submitted already to fix it :) I saw that and responded with Tested-by: Mike

RE: [PATCH v2 2/2] RDMA/core: Initialize port_num in qp_attr

> Subject: [PATCH v2 2/2] RDMA/core: Initialize port_num in qp_attr > > Initialize the port_num for iWARP in rdma_init_qp_attr. > > Fixes: 5ecce4c9b17b("Check port number supplied by user verbs cmds") > Cc: # v2.6.14+ > Reviewed-by: Steve Wise

RE: [PATCH v2 2/2] RDMA/core: Initialize port_num in qp_attr

> Subject: [PATCH v2 2/2] RDMA/core: Initialize port_num in qp_attr > > Initialize the port_num for iWARP in rdma_init_qp_attr. > > Fixes: 5ecce4c9b17b("Check port number supplied by user verbs cmds") > Cc: # v2.6.14+ > Reviewed-by: Steve Wise > Signed-off-by: Mustafa Ismail Tested-by: Mike

RE: [PATCH v2 1/2] RDMA/uverbs: Fix the check for port number

> Subject: [PATCH v2 1/2] RDMA/uverbs: Fix the check for port number > > The port number is only valid if IB_QP_PORT is set in the mask. > So only check port number if it is valid to prevent modify_qp from > failing due to an invalid port number. > > Fixes: 5ecce4c9b17b("Check port number

RE: [PATCH v2 1/2] RDMA/uverbs: Fix the check for port number

> Subject: [PATCH v2 1/2] RDMA/uverbs: Fix the check for port number > > The port number is only valid if IB_QP_PORT is set in the mask. > So only check port number if it is valid to prevent modify_qp from > failing due to an invalid port number. > > Fixes: 5ecce4c9b17b("Check port number

RE: [PATCH 4.4 29/57] RDMA/uverbs: Check port number supplied by user verbs cmds

> Subject: Re: [PATCH 4.4 29/57] RDMA/uverbs: Check port number supplied > by user verbs cmds > > On Thu, Jul 13, 2017 at 03:54:28PM +, Ismail, Mustafa wrote: > > > Subject: [PATCH 4.4 29/57] RDMA/uverbs: Check port number supplied > by > > > user verbs cmds > > > > > > 4.4-stable review

RE: [PATCH 4.4 29/57] RDMA/uverbs: Check port number supplied by user verbs cmds

> Subject: Re: [PATCH 4.4 29/57] RDMA/uverbs: Check port number supplied > by user verbs cmds > > On Thu, Jul 13, 2017 at 03:54:28PM +, Ismail, Mustafa wrote: > > > Subject: [PATCH 4.4 29/57] RDMA/uverbs: Check port number supplied > by > > > user verbs cmds > > > > > > 4.4-stable review

RE: [PATCH] IB/qib: use rb_entry()

> Subject: [PATCH] IB/qib: use rb_entry() > > To make the code clearer, use rb_entry() instead of container_of() to deal > with rbtree. > > Signed-off-by: Geliang Tang Thanks for the patch! Mike Acked-by: Mike Marciniszyn

RE: [PATCH] IB/qib: use rb_entry()

> Subject: [PATCH] IB/qib: use rb_entry() > > To make the code clearer, use rb_entry() instead of container_of() to deal > with rbtree. > > Signed-off-by: Geliang Tang Thanks for the patch! Mike Acked-by: Mike Marciniszyn

false checkpatch finding?

<4.8 tree>/scripts/checkpatch.pl -F foo.h WARNING: Missing a blank line after declarations #3: FILE: foo.h:3: + unsigned long f1; + volatile __le64 f2. WARNING: Use of volatile is usually wrong: see Documentation/volatile-considered-harmful.txt #3: FILE: foo.h:3: + volatile

false checkpatch finding?

<4.8 tree>/scripts/checkpatch.pl -F foo.h WARNING: Missing a blank line after declarations #3: FILE: foo.h:3: + unsigned long f1; + volatile __le64 f2. WARNING: Use of volatile is usually wrong: see Documentation/volatile-considered-harmful.txt #3: FILE: foo.h:3: + volatile

RE: [PATCH] IB/qib: Use memdup_user() rather than duplicating its implementation

> > > > The bail_tmp: label is then not needed. > > You still need to free tmp allocation if qib_eeprom_write failed and this is > your bail_tmp. > Typo. The bail: label is not needed. Mike

RE: [PATCH] IB/qib: Use memdup_user() rather than duplicating its implementation

> > > > The bail_tmp: label is then not needed. > > You still need to free tmp allocation if qib_eeprom_write failed and this is > your bail_tmp. > Typo. The bail: label is not needed. Mike

RE: [PATCH] IB/qib: Use memdup_user() rather than duplicating its implementation

> Subject: [PATCH] IB/qib: Use memdup_user() rather than duplicating its > diff --git a/drivers/infiniband/hw/qib/qib_fs.c I would be even more aggressive at reducing lines of code. For example do direct returns when ok to do: if (pos != 0 || count != sizeof(struct qib_flash))

RE: [PATCH] IB/qib: Use memdup_user() rather than duplicating its implementation

> Subject: [PATCH] IB/qib: Use memdup_user() rather than duplicating its > diff --git a/drivers/infiniband/hw/qib/qib_fs.c I would be even more aggressive at reducing lines of code. For example do direct returns when ok to do: if (pos != 0 || count != sizeof(struct qib_flash))

RE: [PATCH 09/22] IB/qib: Remove deprecated create_singlethread_workqueue

> Subject: [PATCH 09/22] IB/qib: Remove deprecated > create_singlethread_workqueue > Looks and tests good! Tested-by: Mike Marciniszyn Acked-by: Mike Marciniszyn

RE: [PATCH 09/22] IB/qib: Remove deprecated create_singlethread_workqueue

> Subject: [PATCH 09/22] IB/qib: Remove deprecated > create_singlethread_workqueue > Looks and tests good! Tested-by: Mike Marciniszyn Acked-by: Mike Marciniszyn

RE: [PATCH RESEND] qib:Fix concurrent access in the function, qib_init_iba6120_funcs

> From: nick [mailto:xerofo...@gmail.com] > Sent: Monday, March 7, 2016 2:21 PM > To: Marciniszyn, Mike <mike.marcinis...@intel.com> > Cc: dledf...@redhat.com; Hefty, Sean <sean.he...@intel.com>; > hal.rosenst...@gmail.com; linux-r...@vger.kernel.org; linux- > ker...

RE: [PATCH RESEND] qib:Fix concurrent access in the function, qib_init_iba6120_funcs

> From: nick [mailto:xerofo...@gmail.com] > Sent: Monday, March 7, 2016 2:21 PM > To: Marciniszyn, Mike > Cc: dledf...@redhat.com; Hefty, Sean ; > hal.rosenst...@gmail.com; linux-r...@vger.kernel.org; linux- > ker...@vger.kernel.org > Subject: Re: [PATCH RESEND] qib:

RE: [PATCH RESEND] qib:Fix concurrent access in the function, qib_init_iba6120_funcs

> This fixes concurrent access in the function, qib_init_iba6120_funcs by > locking > around the calls to when setting up f_sendctrl and f_set_armlauch function > pointers to the functions, sendctrl_6120_mod qib_set_6120_armlaunch due to > these functions needing to have their caller to hold the

RE: [PATCH RESEND] qib:Fix concurrent access in the function, qib_init_iba6120_funcs

> This fixes concurrent access in the function, qib_init_iba6120_funcs by > locking > around the calls to when setting up f_sendctrl and f_set_armlauch function > pointers to the functions, sendctrl_6120_mod qib_set_6120_armlaunch due to > these functions needing to have their caller to hold the

RE: [PATCH] staging: rdma: hfi1: diag: constify hfi1_filter_array structure

> From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On > Behalf Of Julia Lawall > Subject: [PATCH] staging: rdma: hfi1: diag: constify hfi1_filter_array > structure > > The hfi1_filter_array structure is never modified, so declare it as const. > > Done with the help of

RE: [PATCH] staging: rdma: hfi1: diag: constify hfi1_filter_array structure

> From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On > Behalf Of Julia Lawall > Subject: [PATCH] staging: rdma: hfi1: diag: constify hfi1_filter_array > structure > > The hfi1_filter_array structure is never modified, so declare it as const. > > Done with the help of

RE: [PATCH 1/3] staging/rdma/hfi1: consolidate kmalloc_array+memset into kcalloc

> --- a/drivers/staging/rdma/hfi1/chip.c > +++ b/drivers/staging/rdma/hfi1/chip.c > @@ -10128,8 +10128,7 @@ static void init_qos(struct hfi1_devdata *dd, > u32 first_ctxt) > goto bail; > if (num_vls * qpns_per_vl > dd->chip_rcv_contexts) > goto bail; > -

RE: [PATCH 2/3] staging/rdma/hfi1: check return value of kcalloc

> @@ -10129,6 +10129,9 @@ static void init_qos(struct hfi1_devdata *dd, > u32 first_ctxt) > if (num_vls * qpns_per_vl > dd->chip_rcv_contexts) > goto bail; > rsmmap = kcalloc(NUM_MAP_REGS, sizeof(u64), GFP_KERNEL); > + if (!rsmmap) > + goto bail; > + I

RE: [PATCH 2/3] staging/rdma/hfi1: check return value of kcalloc

> @@ -10129,6 +10129,9 @@ static void init_qos(struct hfi1_devdata *dd, > u32 first_ctxt) > if (num_vls * qpns_per_vl > dd->chip_rcv_contexts) > goto bail; > rsmmap = kcalloc(NUM_MAP_REGS, sizeof(u64), GFP_KERNEL); > + if (!rsmmap) > + goto bail; > + I

RE: [PATCH 1/3] staging/rdma/hfi1: consolidate kmalloc_array+memset into kcalloc

> --- a/drivers/staging/rdma/hfi1/chip.c > +++ b/drivers/staging/rdma/hfi1/chip.c > @@ -10128,8 +10128,7 @@ static void init_qos(struct hfi1_devdata *dd, > u32 first_ctxt) > goto bail; > if (num_vls * qpns_per_vl > dd->chip_rcv_contexts) > goto bail; > -

RE: [PATCH v2 1/1] staging: rdma: hfi1 : Prefer using the BIT macro

> Cc: Sunny Kumar > Subject: [PATCH v2 1/1] staging: rdma: hfi1 : Prefer using the BIT macro > > This patch replaces bit shifting on 1 with the BIT(x) macro > > Signed-off-by: Sunny Kumar > --- Thanks for the patch! Acked-by: Mike Marciniszyn -- To unsubscribe from this list: send the line

RE: [PATCH v2 1/1] staging: rdma: hfi1 : Prefer using the BIT macro

> Cc: Sunny Kumar > Subject: [PATCH v2 1/1] staging: rdma: hfi1 : Prefer using the BIT macro > > This patch replaces bit shifting on 1 with the BIT(x) macro > > Signed-off-by: Sunny Kumar > --- Thanks for the patch! Acked-by: Mike Marciniszyn -- To

RE: [PATCH 1/1] staging: rdma: hfi1 : Prefer using the BIT macro

> Subject: [PATCH 1/1] staging: rdma: hfi1 : Prefer using the BIT macro > > This patch replaces bit shifting on 1 with the BIT(x) macro > > Signed-off-by: Sunny Kumar > --- Nak. The patch leaves the shift in. Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

RE: [PATCH 1/1] staging: rdma: hfi1 : Prefer using the BIT macro

> Subject: [PATCH 1/1] staging: rdma: hfi1 : Prefer using the BIT macro > > This patch replaces bit shifting on 1 with the BIT(x) macro > > Signed-off-by: Sunny Kumar > --- Nak. The patch leaves the shift in. Mike -- To unsubscribe from this list: send the line "unsubscribe

RE: [PATCH] fix return value error

> > Subject: [PATCH] fix return value error > > > > I checked returns in configfs (-ENOMEM), proc (-ENOENT), proc-sys (- > ENOMEM), ramfs (-ENOSPC), vfs (-ENOMEM). > > Not entirely consistent but this matches the majority. > > I agree -EPERM is pretty misleading. > > Acked-by: Mike Marciniszyn

RE: [PATCH] fix return value error

> Subject: [PATCH] fix return value error > I checked returns in configfs (-ENOMEM), proc (-ENOENT), proc-sys (-ENOMEM), ramfs (-ENOSPC), vfs (-ENOMEM). Not entirely consistent but this matches the majority. I agree -EPERM is pretty misleading. Acked-by: Mike Marciniszyn -- To unsubscribe

RE: [PATCH] fix return value error

> > Subject: [PATCH] fix return value error > > > > I checked returns in configfs (-ENOMEM), proc (-ENOENT), proc-sys (- > ENOMEM), ramfs (-ENOSPC), vfs (-ENOMEM). > > Not entirely consistent but this matches the majority. > > I agree -EPERM is pretty misleading. > > Acked-by: Mike Marciniszyn

RE: [PATCH] fix return value error

> Subject: [PATCH] fix return value error > I checked returns in configfs (-ENOMEM), proc (-ENOENT), proc-sys (-ENOMEM), ramfs (-ENOSPC), vfs (-ENOMEM). Not entirely consistent but this matches the majority. I agree -EPERM is pretty misleading. Acked-by: Mike Marciniszyn

RE: [PATCH] staging/rdma/hfi1: do not use u8 to store a 32-bit integer

> Subject: [PATCH] staging/rdma/hfi1: do not use u8 to store a 32-bit integer > Thanks for the patch! Acked-by: Mike Marciniszyn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at

RE: [PATCH] IB/hfi1: class_name_user() should be static

> Subject: [PATCH] IB/hfi1: class_name_user() should be static > > Fixes the following sparse warning: > drivers/staging/rdma/hfi1/device.c:127:12: > warning: symbol 'class_name_user' was not declared. Should it be static? > > Signed-off-by: Geliang Tang > --- Thanks for the patch!

RE: [PATCH] IB/hfi1: use kvfree() in sdma.c

> Subject: [PATCH] IB/hfi1: use kvfree() in sdma.c > > Use kvfree() instead of open-coding it. > > Signed-off-by: Geliang Tang > --- > drivers/staging/rdma/hfi1/sdma.c | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) Thanks for the patch. Acked-by: Mike Marciniszyn -- To

RE: [PATCH] IB/hfi1: use kvfree() in sdma.c

> Subject: [PATCH] IB/hfi1: use kvfree() in sdma.c > > Use kvfree() instead of open-coding it. > > Signed-off-by: Geliang Tang > --- > drivers/staging/rdma/hfi1/sdma.c | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) Thanks for the patch. Acked-by: Mike

RE: [PATCH] IB/hfi1: class_name_user() should be static

> Subject: [PATCH] IB/hfi1: class_name_user() should be static > > Fixes the following sparse warning: > drivers/staging/rdma/hfi1/device.c:127:12: > warning: symbol 'class_name_user' was not declared. Should it be static? > > Signed-off-by: Geliang Tang > --- Thanks

RE: [PATCH] staging/rdma/hfi1: do not use u8 to store a 32-bit integer

> Subject: [PATCH] staging/rdma/hfi1: do not use u8 to store a 32-bit integer > Thanks for the patch! Acked-by: Mike Marciniszyn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More

RE: [PATCH 11/39] hfi1: drop null test before destroy functions

> Subject: [PATCH 11/39] hfi1: drop null test before destroy functions > > Remove unneeded NULL test. > > The semantic patch that makes this change is as follows: > (http://coccinelle.lip6.fr/) > > // > @@ expression x; @@ > -if (x != NULL) >

RE: [PATCH 11/39] hfi1: drop null test before destroy functions

> Subject: [PATCH 11/39] hfi1: drop null test before destroy functions > > Remove unneeded NULL test. > > The semantic patch that makes this change is as follows: > (http://coccinelle.lip6.fr/) > > // > @@ expression x; @@ > -if (x != NULL) >

RE: [PATCH] staging: hfi1: Kconfig: remove 'CONFIG_' prefix

> Subject: [PATCH] staging: hfi1: Kconfig: remove 'CONFIG_' prefix > > Remove the 'CONFIG_' prefix of the Kconfig options PRESCAN_RXQ and > SDMA_VERBOSITY in Kconfig. Such prefix in Kconfig requires a double > 'CONFIG_CONFIG_' prefix in Make and CPP syntax. > Doug, can you pull this one in?

RE: linux-next: Tree for Aug 17 (staging/hfi1)

> A: these and other similar errors: > > In file included from ../drivers/staging/hfi1/chip.c:61:0: > ../drivers/staging/hfi1/chip.c: In function ‘__hfi1_trace_LINKVERB’: > ../drivers/staging/hfi1/trace.h:1357:20: error: function > ‘__hfi1_trace_LINKVERB’ can never be inlined because it

RE: [PATCH] staging: hfi1: Kconfig: remove 'CONFIG_' prefix

Subject: [PATCH] staging: hfi1: Kconfig: remove 'CONFIG_' prefix Remove the 'CONFIG_' prefix of the Kconfig options PRESCAN_RXQ and SDMA_VERBOSITY in Kconfig. Such prefix in Kconfig requires a double 'CONFIG_CONFIG_' prefix in Make and CPP syntax. Doug, can you pull this one in? There

RE: linux-next: Tree for Aug 17 (staging/hfi1)

A: these and other similar errors: In file included from ../drivers/staging/hfi1/chip.c:61:0: ../drivers/staging/hfi1/chip.c: In function ‘__hfi1_trace_LINKVERB’: ../drivers/staging/hfi1/trace.h:1357:20: error: function ‘__hfi1_trace_LINKVERB’ can never be inlined because it uses

RE: [PATCH] staging: hfi1: Kconfig: remove 'CONFIG_' prefix

> Subject: [PATCH] staging: hfi1: Kconfig: remove 'CONFIG_' prefix > Signed-off-by: Valentin Rothberg > --- Thanks for the patch! Acked-by: Mike Marciniszyn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More

RE: [PATCH] staging: hfi1: Kconfig: remove 'CONFIG_' prefix

Subject: [PATCH] staging: hfi1: Kconfig: remove 'CONFIG_' prefix Signed-off-by: Valentin Rothberg valentinrothb...@gmail.com --- Thanks for the patch! Acked-by: Mike Marciniszyn mike.marcinis...@intel.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of

RE: [PATCH v3 2/3] IB/qib: use arch_phys_wc_add()

> > This driver already makes use of ioremap_wc() on PIO buffers, so > > convert it to use arch_phys_wc_add(). > > This is probably OK, but I think you should also remove the qib_wc_pat module > parameter. > > Jason Revise based on Jason's request and I will do some testing. Mike -- To

RE: [PATCH v3 2/3] IB/qib: use arch_phys_wc_add()

This driver already makes use of ioremap_wc() on PIO buffers, so convert it to use arch_phys_wc_add(). This is probably OK, but I think you should also remove the qib_wc_pat module parameter. Jason Revise based on Jason's request and I will do some testing. Mike -- To unsubscribe from

RE: [PATCH] infiniband: hw: ipath: ipath_wc_ppc64.c: Remove unused function

> From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma- > ow...@vger.kernel.org] On Behalf Of Rickard Strandqvist > Sent: Saturday, December 20, 2014 11:19 AM > To: infinipath; Roland Dreier > Cc: Rickard Strandqvist; Hefty, Sean; Hal Rosenstock; linux- > r...@vger.kernel.org;

RE: [PATCH] IB: qib: qib_iba7322: Remove unused function

> From: Rickard Strandqvist [mailto:rickard_strandqv...@spectrumdigital.se] > Sent: Sunday, January 11, 2015 9:05 AM > Subject: [PATCH] IB: qib: qib_iba7322: Remove unused function > Roland, can you change the summary to: IB/qib: Remove unused function in qib_iba7322 Thanks for the

RE: [PATCH] IB: qib: qib_iba7322: Remove unused function

From: Rickard Strandqvist [mailto:rickard_strandqv...@spectrumdigital.se] Sent: Sunday, January 11, 2015 9:05 AM Subject: [PATCH] IB: qib: qib_iba7322: Remove unused function Roland, can you change the summary to: IB/qib: Remove unused function in qib_iba7322 Thanks for the patch!

RE: [PATCH] infiniband: hw: ipath: ipath_wc_ppc64.c: Remove unused function

From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma- ow...@vger.kernel.org] On Behalf Of Rickard Strandqvist Sent: Saturday, December 20, 2014 11:19 AM To: infinipath; Roland Dreier Cc: Rickard Strandqvist; Hefty, Sean; Hal Rosenstock; linux- r...@vger.kernel.org;

RE: [PATCH] qib: qib_qp: Replace rcu_assign_pointer() with RCU_INIT_POINTER()

> Subject: [PATCH] qib: qib_qp: Replace rcu_assign_pointer() with > RCU_INIT_POINTER() > Why not consolidate this with http://marc.info/?l=linux-rdma=140836578119485=2 so there is just one patch? Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a

RE: [PATCH] qib_keys: Replace rcu_assign_pointer() with RCU_INIT_POINTER()

> Subject: [PATCH] qib_keys: Replace rcu_assign_pointer() with > RCU_INIT_POINTER() > I would prefer the summary be: IB/qib: qib_remove_lkey() Replace rcu_assign_pointer() with > RCU_INIT_POINTER() Otherwise the patch looks ok and has been tested. -- To unsubscribe from this list: send the

RE: [PATCH] qib_qp: Replace rcu_assign_pointer() with RCU_INIT_POINTER()

> Subject: [PATCH] qib_qp: Replace rcu_assign_pointer() with > RCU_INIT_POINTER() > I would prefer the summary line be: IB/qib: remove_qp() use RCU_INIT_POINTER() instead of rcu_assign_pointer() Otherwise I agree with the patch and I have tested it with large numbers of QPs. Mike -- To

RE: [PATCH] qib_qp: Replace rcu_assign_pointer() with RCU_INIT_POINTER()

Subject: [PATCH] qib_qp: Replace rcu_assign_pointer() with RCU_INIT_POINTER() I would prefer the summary line be: IB/qib: remove_qp() use RCU_INIT_POINTER() instead of rcu_assign_pointer() Otherwise I agree with the patch and I have tested it with large numbers of QPs. Mike -- To

RE: [PATCH] qib_keys: Replace rcu_assign_pointer() with RCU_INIT_POINTER()

Subject: [PATCH] qib_keys: Replace rcu_assign_pointer() with RCU_INIT_POINTER() I would prefer the summary be: IB/qib: qib_remove_lkey() Replace rcu_assign_pointer() with RCU_INIT_POINTER() Otherwise the patch looks ok and has been tested. -- To unsubscribe from this list: send the line

RE: [PATCH] qib: qib_qp: Replace rcu_assign_pointer() with RCU_INIT_POINTER()

Subject: [PATCH] qib: qib_qp: Replace rcu_assign_pointer() with RCU_INIT_POINTER() Why not consolidate this with http://marc.info/?l=linux-rdmam=140836578119485w=2 so there is just one patch? Mike -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a

RE: [PATCH 9/10] IB/qib: use safer test on the result of find_first_zero_bit

> > No, it's not necessary. It turns out that the result cannot be greater than > the > requested maximum value. > > Julia Ok. No stable then. Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More

RE: [PATCH 9/10] IB/qib: use safer test on the result of find_first_zero_bit

> Subject: [PATCH 9/10] IB/qib: use safer test on the result of > find_first_zero_bit > > From: Julia Lawall Thanks for the patch! Roland, I'm marking this as stable since a memory corruption can occur in the _set_bit(). Cc: Acked-by: Mike Marciniszyn -- To unsubscribe from this list:

RE: [PATCH 9/10] IB/qib: use safer test on the result of find_first_zero_bit

Subject: [PATCH 9/10] IB/qib: use safer test on the result of find_first_zero_bit From: Julia Lawall julia.law...@lip6.fr Thanks for the patch! Roland, I'm marking this as stable since a memory corruption can occur in the _set_bit(). Cc: sta...@vger.kernel.org Acked-by: Mike Marciniszyn

RE: [PATCH 9/10] IB/qib: use safer test on the result of find_first_zero_bit

No, it's not necessary. It turns out that the result cannot be greater than the requested maximum value. Julia Ok. No stable then. Mike -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info

RE: [PATCH] drivers/infiniband: Use RCU_INIT_POINTER(x, NULL) in hw/qib/qib_keys.c

> Subject: [PATCH] drivers/infiniband: Use RCU_INIT_POINTER(x, NULL) in > hw/qib/qib_keys.c > > Signed-off-by: Monam Agarwal Thanks for the patch! Acked-by: Mike Marciniszyn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to

RE: [PATCH] drivers/infiniband: Use RCU_INIT_POINTER(x, NULL) in hw/qib/qib_qp.c

> Subject: [PATCH] drivers/infiniband: Use RCU_INIT_POINTER(x, NULL) in > hw/qib/qib_qp.c > > Signed-off-by: Monam Agarwal Thanks for the patch! Acked-by: Mike Marciniszyn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to

RE: [PATCH] drivers/infiniband: Use RCU_INIT_POINTER(x, NULL) in hw/qib/qib_qp.c

Subject: [PATCH] drivers/infiniband: Use RCU_INIT_POINTER(x, NULL) in hw/qib/qib_qp.c Signed-off-by: Monam Agarwal monamagarwal...@gmail.com Thanks for the patch! Acked-by: Mike Marciniszyn mike.marcinis...@intel.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel

RE: [PATCH] drivers/infiniband: Use RCU_INIT_POINTER(x, NULL) in hw/qib/qib_keys.c

Subject: [PATCH] drivers/infiniband: Use RCU_INIT_POINTER(x, NULL) in hw/qib/qib_keys.c Signed-off-by: Monam Agarwal monamagarwal...@gmail.com Thanks for the patch! Acked-by: Mike Marciniszyn mike.marcinis...@intel.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel

RE: [PATCH infiniband] IB/qib: qib_user_sdma_rb_root can be static

> Subject: [PATCH infiniband] IB/qib: qib_user_sdma_rb_root can be static > > CC: CQ Tang > CC: Roland Dreier > Signed-off-by: Fengguang Wu Thanks for the patch. Acked-by: Mike Marciniszyn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to

RE: [PATCH infiniband] IB/qib: qib_user_sdma_rb_root can be static

Subject: [PATCH infiniband] IB/qib: qib_user_sdma_rb_root can be static CC: CQ Tang cq.t...@intel.com CC: Roland Dreier rol...@purestorage.com Signed-off-by: Fengguang Wu fengguang...@intel.com Thanks for the patch. Acked-by: Mike Marciniszyn mike.marcinis...@intel.com -- To unsubscribe

RE: [PATCH 2/2] qib: Use pci_enable_msix_range() instead of pci_enable_msix()

> Subject: [PATCH 2/2] qib: Use pci_enable_msix_range() instead of > pci_enable_msix() > > As result of deprecation of MSI-X/MSI enablement functions > pci_enable_msix() and pci_enable_msi_block() all drivers using these two > interfaces need to be updated to use the new pci_enable_msi_range()

RE: [PATCH 2/2] qib: Use pci_enable_msix_range() instead of pci_enable_msix()

Subject: [PATCH 2/2] qib: Use pci_enable_msix_range() instead of pci_enable_msix() As result of deprecation of MSI-X/MSI enablement functions pci_enable_msix() and pci_enable_msi_block() all drivers using these two interfaces need to be updated to use the new pci_enable_msi_range() and

RE: [PATCH 2/2] qib: Use pci_enable_msix_range() instead of pci_enable_msix()

> Subject: [PATCH 2/2] qib: Use pci_enable_msix_range() instead of > pci_enable_msix() > We are testing this now. I suggest a subject/summary adding the IB/: IB/qib: Use pci_enable_msix_range() instead of pci_enable_msix() -- To unsubscribe from this list: send the line "unsubscribe

RE: [PATCH 2/2] qib: Use pci_enable_msix_range() instead of pci_enable_msix()

Subject: [PATCH 2/2] qib: Use pci_enable_msix_range() instead of pci_enable_msix() We are testing this now. I suggest a subject/summary adding the IB/: IB/qib: Use pci_enable_msix_range() instead of pci_enable_msix() -- To unsubscribe from this list: send the line unsubscribe linux-kernel in

RE: qib_lookup_qpn() appears to leak pointer out of rcu_read_unlock()

BTW, I am considering eliminating the atomic_inc() in favor of widening the scope of the rcu lock expanse. Mike > -Original Message- > From: Paul E. McKenney [mailto:paul...@linux.vnet.ibm.com] > Sent: Wednesday, February 12, 2014 9:56 AM > To: Marciniszyn, Mike > Cc: ro

RE: qib_lookup_qpn() appears to leak pointer out of rcu_read_unlock()

> So what am I missing here? > The atomic increment of a reference count: struct qib_qp *qib_lookup_qpn(struct qib_ibport *ibp, u32 qpn) { struct qib_qp *qp = NULL; rcu_read_lock(); if (unlikely(qpn <= 1)) { if (qpn == 0) qp =

RE: qib_lookup_qpn() appears to leak pointer out of rcu_read_unlock()

So what am I missing here? The atomic increment of a reference count: struct qib_qp *qib_lookup_qpn(struct qib_ibport *ibp, u32 qpn) { struct qib_qp *qp = NULL; rcu_read_lock(); if (unlikely(qpn = 1)) { if (qpn == 0) qp =

RE: qib_lookup_qpn() appears to leak pointer out of rcu_read_unlock()

BTW, I am considering eliminating the atomic_inc() in favor of widening the scope of the rcu lock expanse. Mike -Original Message- From: Paul E. McKenney [mailto:paul...@linux.vnet.ibm.com] Sent: Wednesday, February 12, 2014 9:56 AM To: Marciniszyn, Mike Cc: rol...@kernel.org

RE: linux-next: build warning after merge of the infiniband tree

t: Sunday, November 03, 2013 11:55 PM > To: Roland Dreier; linux-r...@vger.kernel.org > Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; Jan Kara; > Marciniszyn, Mike > Subject: linux-next: build warning after merge of the infiniband tree > > Hi all, > > After mer

RE: linux-next: build warning after merge of the infiniband tree

, November 03, 2013 11:55 PM To: Roland Dreier; linux-r...@vger.kernel.org Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; Jan Kara; Marciniszyn, Mike Subject: linux-next: build warning after merge of the infiniband tree Hi all, After merging the infiniband tree, today's linux-next

RE: [PATCH linux-next-20131029] IB/ipath: Fix random stack overflow.

From: Tetsuo Handa > Date: Wed, 30 Oct 2013 16:12:58 +0900 > Subject: [PATCH linux-next-20131029] IB/ipath: Fix random stack overflow. > Signed-off-by: Tetsuo Handa > Cc: > --- Thanks for catching this! Acked-by: Mike Marciniszyn -- To unsubscribe from this list: send the line "unsubscribe

RE: [PATCH linux-next-20131029] IB/ipath: Fix random stack overflow.

From: Tetsuo Handa penguin-ker...@i-love.sakura.ne.jp Date: Wed, 30 Oct 2013 16:12:58 +0900 Subject: [PATCH linux-next-20131029] IB/ipath: Fix random stack overflow. Signed-off-by: Tetsuo Handa penguin-ker...@i-love.sakura.ne.jp Cc: sta...@vger.kernel.org --- Thanks for catching this!

RE: [PATCH 23/26] ib: Convert qib_get_user_pages() to get_user_pages_unlocked()

> > This patch and the sibling ipath patch will nominally take the mmap_sem > > twice where the old routine only took it once. This is a performance > > issue. > It will take mmap_sem only once during normal operation. Only if > get_user_pages_unlocked() fail, we have to take mmap_sem again to

RE: [PATCH 23/26] ib: Convert qib_get_user_pages() to get_user_pages_unlocked()

> -Original Message- > From: Jan Kara [mailto:j...@suse.cz] > Sent: Friday, October 04, 2013 2:33 PM > To: Marciniszyn, Mike > Cc: Jan Kara; LKML; linux...@kvack.org; infinipath; Roland Dreier; linux- > r...@vger.kernel.org > Subject: Re: [PATCH 23/26] ib: Conve

RE: [PATCH 23/26] ib: Convert qib_get_user_pages() to get_user_pages_unlocked()

-Original Message- From: Jan Kara [mailto:j...@suse.cz] Sent: Friday, October 04, 2013 2:33 PM To: Marciniszyn, Mike Cc: Jan Kara; LKML; linux...@kvack.org; infinipath; Roland Dreier; linux- r...@vger.kernel.org Subject: Re: [PATCH 23/26] ib: Convert qib_get_user_pages

RE: [PATCH 23/26] ib: Convert qib_get_user_pages() to get_user_pages_unlocked()

This patch and the sibling ipath patch will nominally take the mmap_sem twice where the old routine only took it once. This is a performance issue. It will take mmap_sem only once during normal operation. Only if get_user_pages_unlocked() fail, we have to take mmap_sem again to undo

RE: [PATCH 23/26] ib: Convert qib_get_user_pages() to get_user_pages_unlocked()

> Convert qib_get_user_pages() to use get_user_pages_unlocked(). This > shortens the section where we hold mmap_sem for writing and also removes > the knowledge about get_user_pages() locking from ipath driver. We also fix > a bug in testing pinned number of pages when changing the code. > This

RE: [PATCH 23/26] ib: Convert qib_get_user_pages() to get_user_pages_unlocked()

Inadvertent send! Mike > -Original Message- > From: Marciniszyn, Mike > Sent: Friday, October 04, 2013 9:39 AM > To: Jan Kara > Cc: LKML; linux...@kvack.org; infinipath; Roland Dreier; linux- > r...@vger.kernel.org > Subject: RE: [PATCH 23/26] ib: Conve

RE: [PATCH 23/26] ib: Convert qib_get_user_pages() to get_user_pages_unlocked()

> The PSM side of the code is a more traditional use of GUP (like direct I/O), > so > I think it is a different use case than the locking for IB memory regions. I have resubmitted the two deadlock fixes using get_user_pages_fast() and marked them stable. See

RE: [PATCH 23/26] ib: Convert qib_get_user_pages() to get_user_pages_unlocked()

> -Original Message- > From: Jan Kara [mailto:j...@suse.cz] > Sent: Wednesday, October 02, 2013 11:39 AM > To: Marciniszyn, Mike > Cc: Jan Kara; LKML; linux...@kvack.org; infinipath; Roland Dreier; linux- > r...@vger.kernel.org > Subject: Re: [PATCH 23/26] ib: Conve

RE: [PATCH 23/26] ib: Convert qib_get_user_pages() to get_user_pages_unlocked()

-Original Message- From: Jan Kara [mailto:j...@suse.cz] Sent: Wednesday, October 02, 2013 11:39 AM To: Marciniszyn, Mike Cc: Jan Kara; LKML; linux...@kvack.org; infinipath; Roland Dreier; linux- r...@vger.kernel.org Subject: Re: [PATCH 23/26] ib: Convert qib_get_user_pages

RE: [PATCH 23/26] ib: Convert qib_get_user_pages() to get_user_pages_unlocked()

The PSM side of the code is a more traditional use of GUP (like direct I/O), so I think it is a different use case than the locking for IB memory regions. I have resubmitted the two deadlock fixes using get_user_pages_fast() and marked them stable. See

  1   2   >