| Message ID | 1523431945-3508-1-git-send-email-baijiaju1990@gmail.com (mailing list archive) |
|---|---|
| State | Accepted |
| Delegated to: | Jason Gunthorpe |
| Headers | show |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <baijiaju1990@gmail.com> > --- Acked-by: Shiraz Saleem <shiraz.saleem@intel.com> -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <baijiaju1990@gmail.com> > Acked-by: Shiraz Saleem <shiraz.saleem@intel.com> > --- > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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->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(&iwdev->sc_dev, I40IW_DEBUG_CM,
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 <baijiaju1990@gmail.com> --- drivers/infiniband/hw/i40iw/i40iw_cm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)