> -----Original Message----- > From: Jason Gunthorpe [mailto:jgg@xxxxxxxx] > Sent: Monday, July 09, 2018 4:05 PM > To: Parav Pandit <parav@xxxxxxxxxxxx> > Cc: Leon Romanovsky <leon@xxxxxxxxxx>; Doug Ledford > <dledford@xxxxxxxxxx>; RDMA mailing list <linux-rdma@xxxxxxxxxxxxxxx>; > Daniel Jurgens <danielj@xxxxxxxxxxxx>; Leon Romanovsky > <leonro@xxxxxxxxxxxx> > Subject: Re: [PATCH rdma-next] IB/mlx5: Honor cnt_set_id_valid flag instead of > set_id > > On Mon, Jul 09, 2018 at 08:48:35PM +0000, Parav Pandit wrote: > > > > > > > From: Jason Gunthorpe [mailto:jgg@xxxxxxxx] > > > Sent: Monday, July 09, 2018 2:32 PM > > > To: Leon Romanovsky <leon@xxxxxxxxxx> > > > Cc: Doug Ledford <dledford@xxxxxxxxxx>; Parav Pandit > > > <parav@xxxxxxxxxxxx>; RDMA mailing list > > > <linux-rdma@xxxxxxxxxxxxxxx>; Daniel Jurgens <danielj@xxxxxxxxxxxx>; > > > Leon Romanovsky <leonro@xxxxxxxxxxxx> > > > Subject: Re: [PATCH rdma-next] IB/mlx5: Honor cnt_set_id_valid flag > > > instead of set_id > > > > > > On Sun, Jul 08, 2018 at 01:40:30PM +0300, Leon Romanovsky wrote: > > > > From: Parav Pandit <parav@xxxxxxxxxxxx> > > > > > > > > It is incorrect to depend on set_id value to know if counters were > > > > allocated or not. set_id_valid field is set to true when counters > > > > were allocated. Therefore, use set_id_valid while deciding to free > > > > counters. > > > > > > > > Cc: <stable@xxxxxxxxxxxxxxx> # 4.15 > > > > Fixes: aac4492ef23a ("IB/mlx5: Update counter implementation for > > > > dual port RoCE") > > > > Signed-off-by: Parav Pandit <parav@xxxxxxxxxxxx> > > > > Reviewed-by: Daniel Jurgens <danielj@xxxxxxxxxxxx> > > > > Signed-off-by: Leon Romanovsky <leonro@xxxxxxxxxxxx> > > > > drivers/infiniband/hw/mlx5/main.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > Applied to for-next, but confused why this is cc'd stable but not for-rc. > > > > I guess because the bug was not introduced in this rc cycle. But it may be > wrong guess. > > Can you elaborate on what the consequence of this bug is? No user visible consequence. When driver is unloaded or device is removed, counter set id can remain allocated in HCA. But this is also unlikely because when RDMA driver gets to allocate the counter set id after code driver is loaded, it always or most of the time gets non zero value. So it's unlikely an issue. For VFs, VM driver can always decide to free the counter set id and its fine, HCA is expected to necessary cleanup. It is just done correctly to refer to right flag to make sure that if in case HCA assigned counter set id = 0, we still free it and don't assume that counter_set id was always non_zero. > > Is it user triggerable? Can we use after free? etc. No. This is internal to driver during load/unload sequence. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
