Re: [PATCH 1/3] infiniband: i40iw: Replace GFP_ATOMIC with GFP_KERNEL in i40iw_add_mqh_4

[Jason Gunthorpe]

On Wed, Apr 11, 2018 at 03:32:25PM +0800, Jia-Ju Bai wrote:
> i40iw_add_mqh_4() is never called in atomic context, because it 
> calls rtnl_lock() that can sleep.
> 
> Despite never getting called from atomic context,
> i40iw_add_mqh_4() calls kzalloc() with GFP_ATOMIC,
> which does not sleep for allocation.
> GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
> which can sleep and improve the possibility of sucessful allocation.
> 
> This is found by a static analysis tool named DCNS written by myself.
> And I also manually check it.
> 
> Signed-off-by: Jia-Ju Bai 
> Acked-by: Shiraz Saleem 
> ---
>  drivers/infiniband/hw/i40iw/i40iw_cm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied all three patches in this series to for-next, thanks

Jason

Re: [PATCH 1/3] infiniband: i40iw: Replace GFP_ATOMIC with GFP_KERNEL in i40iw_add_mqh_4

[Jason Gunthorpe]

On Wed, Apr 11, 2018 at 03:32:25PM +0800, Jia-Ju Bai wrote:
> i40iw_add_mqh_4() is never called in atomic context, because it 
> calls rtnl_lock() that can sleep.
> 
> Despite never getting called from atomic context,
> i40iw_add_mqh_4() calls kzalloc() with GFP_ATOMIC,
> which does not sleep for allocation.
> GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
> which can sleep and improve the possibility of sucessful allocation.
> 
> This is found by a static analysis tool named DCNS written by myself.
> And I also manually check it.
> 
> Signed-off-by: Jia-Ju Bai 
> Acked-by: Shiraz Saleem 
> ---
>  drivers/infiniband/hw/i40iw/i40iw_cm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied all three patches in this series to for-next, thanks

Jason

Re: [PATCH 1/3] infiniband: i40iw: Replace GFP_ATOMIC with GFP_KERNEL in i40iw_add_mqh_4

[Shiraz Saleem]

On Wed, Apr 11, 2018 at 10:53:13AM -0400, Dennis Dalessandro wrote:
> On 4/11/2018 3:32 AM, Jia-Ju Bai wrote:
> > i40iw_add_mqh_4() is never called in atomic context, because it
> > calls rtnl_lock() that can sleep.
> > 
> > Despite never getting called from atomic context,
> > i40iw_add_mqh_4() calls kzalloc() with GFP_ATOMIC,
> > which does not sleep for allocation.
> > GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
> > which can sleep and improve the possibility of sucessful allocation.
> 
> Just a general comment. I don't know that this is the greatest idea. I can
> imagine instances where sleeping is OK as far as how the code is written,
> but for performance reasons you would rather fail than sleep.
> 
> As to whether that is the case here I'll let the i40iw folks comment.
>

In this case, the changes Jia made look safe and not in the perf. path. Thanks!

 
> > This is found by a static analysis tool named DCNS written by myself.
> > And I also manually check it.
> You should probably post a pointer to your tool.
> 
> -Denny

Re: [PATCH 1/3] infiniband: i40iw: Replace GFP_ATOMIC with GFP_KERNEL in i40iw_add_mqh_4

[Shiraz Saleem]

On Wed, Apr 11, 2018 at 10:53:13AM -0400, Dennis Dalessandro wrote:
> On 4/11/2018 3:32 AM, Jia-Ju Bai wrote:
> > i40iw_add_mqh_4() is never called in atomic context, because it
> > calls rtnl_lock() that can sleep.
> > 
> > Despite never getting called from atomic context,
> > i40iw_add_mqh_4() calls kzalloc() with GFP_ATOMIC,
> > which does not sleep for allocation.
> > GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
> > which can sleep and improve the possibility of sucessful allocation.
> 
> Just a general comment. I don't know that this is the greatest idea. I can
> imagine instances where sleeping is OK as far as how the code is written,
> but for performance reasons you would rather fail than sleep.
> 
> As to whether that is the case here I'll let the i40iw folks comment.
>

In this case, the changes Jia made look safe and not in the perf. path. Thanks!

 
> > This is found by a static analysis tool named DCNS written by myself.
> > And I also manually check it.
> You should probably post a pointer to your tool.
> 
> -Denny

Re: [PATCH 1/3] infiniband: i40iw: Replace GFP_ATOMIC with GFP_KERNEL in i40iw_add_mqh_4

[Shiraz Saleem]

On Wed, Apr 11, 2018 at 03:32:25PM +0800, Jia-Ju Bai wrote:
> i40iw_add_mqh_4() is never called in atomic context, because it 
> calls rtnl_lock() that can sleep.
> 
> Despite never getting called from atomic context,
> i40iw_add_mqh_4() calls kzalloc() with GFP_ATOMIC,
> which does not sleep for allocation.
> GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
> which can sleep and improve the possibility of sucessful allocation.
> 
> This is found by a static analysis tool named DCNS written by myself.
> And I also manually check it.
> 
> Signed-off-by: Jia-Ju Bai 
> ---

Acked-by: Shiraz Saleem 

Re: [PATCH 1/3] infiniband: i40iw: Replace GFP_ATOMIC with GFP_KERNEL in i40iw_add_mqh_4

[Shiraz Saleem]

On Wed, Apr 11, 2018 at 03:32:25PM +0800, Jia-Ju Bai wrote:
> i40iw_add_mqh_4() is never called in atomic context, because it 
> calls rtnl_lock() that can sleep.
> 
> Despite never getting called from atomic context,
> i40iw_add_mqh_4() calls kzalloc() with GFP_ATOMIC,
> which does not sleep for allocation.
> GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
> which can sleep and improve the possibility of sucessful allocation.
> 
> This is found by a static analysis tool named DCNS written by myself.
> And I also manually check it.
> 
> Signed-off-by: Jia-Ju Bai 
> ---

Acked-by: Shiraz Saleem 

Re: [PATCH 1/3] infiniband: i40iw: Replace GFP_ATOMIC with GFP_KERNEL in i40iw_add_mqh_4

[Dennis Dalessandro]

On 4/11/2018 3:32 AM, Jia-Ju Bai wrote:

i40iw_add_mqh_4() is never called in atomic context, because it
calls rtnl_lock() that can sleep.

Despite never getting called from atomic context,
i40iw_add_mqh_4() calls kzalloc() with GFP_ATOMIC,
which does not sleep for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
which can sleep and improve the possibility of sucessful allocation.


Just a general comment. I don't know that this is the greatest idea. I 
can imagine instances where sleeping is OK as far as how the code is 
written, but for performance reasons you would rather fail than sleep.


As to whether that is the case here I'll let the i40iw folks comment.


This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.

You should probably post a pointer to your tool.

-Denny

Re: [PATCH 1/3] infiniband: i40iw: Replace GFP_ATOMIC with GFP_KERNEL in i40iw_add_mqh_4

[Dennis Dalessandro]

On 4/11/2018 3:32 AM, Jia-Ju Bai wrote:

i40iw_add_mqh_4() is never called in atomic context, because it
calls rtnl_lock() that can sleep.

Despite never getting called from atomic context,
i40iw_add_mqh_4() calls kzalloc() with GFP_ATOMIC,
which does not sleep for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
which can sleep and improve the possibility of sucessful allocation.


Just a general comment. I don't know that this is the greatest idea. I 
can imagine instances where sleeping is OK as far as how the code is 
written, but for performance reasons you would rather fail than sleep.


As to whether that is the case here I'll let the i40iw folks comment.


This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.

You should probably post a pointer to your tool.

-Denny

[PATCH 1/3] infiniband: i40iw: Replace GFP_ATOMIC with GFP_KERNEL in i40iw_add_mqh_4

[Jia-Ju Bai]

i40iw_add_mqh_4() is never called in atomic context, because it 
calls rtnl_lock() that can sleep.

Despite never getting called from atomic context,
i40iw_add_mqh_4() calls kzalloc() with GFP_ATOMIC,
which does not sleep for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
which can sleep and improve the possibility of sucessful allocation.

This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.

Signed-off-by: Jia-Ju Bai 
---
 drivers/infiniband/hw/i40iw/i40iw_cm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/infiniband/hw/i40iw/i40iw_cm.c 
b/drivers/infiniband/hw/i40iw/i40iw_cm.c
index 5230dd3..4e79af5 100644
--- a/drivers/infiniband/hw/i40iw/i40iw_cm.c
+++ b/drivers/infiniband/hw/i40iw/i40iw_cm.c
@@ -1758,7 +1758,7 @@ static enum i40iw_status_code i40iw_add_mqh_4(
>ifa_address,
rdma_vlan_dev_vlan_id(dev),
dev->dev_addr);
-   child_listen_node = 
kzalloc(sizeof(*child_listen_node), GFP_ATOMIC);
+   child_listen_node = 
kzalloc(sizeof(*child_listen_node), GFP_KERNEL);

cm_parent_listen_node->cm_core->stats_listen_nodes_created++;
i40iw_debug(>sc_dev,
I40IW_DEBUG_CM,
-- 
1.9.1

[PATCH 1/3] infiniband: i40iw: Replace GFP_ATOMIC with GFP_KERNEL in i40iw_add_mqh_4

[Jia-Ju Bai]

i40iw_add_mqh_4() is never called in atomic context, because it 
calls rtnl_lock() that can sleep.

Despite never getting called from atomic context,
i40iw_add_mqh_4() calls kzalloc() with GFP_ATOMIC,
which does not sleep for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
which can sleep and improve the possibility of sucessful allocation.

This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.

Signed-off-by: Jia-Ju Bai 
---
 drivers/infiniband/hw/i40iw/i40iw_cm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/infiniband/hw/i40iw/i40iw_cm.c 
b/drivers/infiniband/hw/i40iw/i40iw_cm.c
index 5230dd3..4e79af5 100644
--- a/drivers/infiniband/hw/i40iw/i40iw_cm.c
+++ b/drivers/infiniband/hw/i40iw/i40iw_cm.c
@@ -1758,7 +1758,7 @@ static enum i40iw_status_code i40iw_add_mqh_4(
>ifa_address,
rdma_vlan_dev_vlan_id(dev),
dev->dev_addr);
-   child_listen_node = 
kzalloc(sizeof(*child_listen_node), GFP_ATOMIC);
+   child_listen_node = 
kzalloc(sizeof(*child_listen_node), GFP_KERNEL);

cm_parent_listen_node->cm_core->stats_listen_nodes_created++;
i40iw_debug(>sc_dev,
I40IW_DEBUG_CM,
-- 
1.9.1