Mike Christie
unread,Jul 17, 2025, 4:01:33 PMJul 17Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to Li Lingfeng, ldu...@suse.com, cle...@redhat.com, nja...@marvell.com, mrang...@marvell.com, GR-QLogic-Sto...@marvell.com, martin....@oracle.com, je...@linux.ibm.com, James.B...@hansenpartnership.com, open-...@googlegroups.com, linux...@vger.kernel.org, linux-...@vger.kernel.org, yuk...@huaweicloud.com, hou...@huawei.com, yi.z...@huawei.com, yang...@huawei.com, chengz...@huawei.com, lilin...@huaweicloud.com
On 7/15/25 2:39 AM, Li Lingfeng wrote:
> This reverts commit c577ab7ba5f3bf9062db8a58b6e89d4fe370447e.
>
> The invocation of iscsi_put_conn() in iscsi_iter_destory_conn_fn() is used
> to free the initial reference counter of iscsi_cls_conn.
> For non-qla4xxx cases, the ->destroy_conn() callback (e.g.,
> iscsi_conn_teardown) will call iscsi_remove_conn() and iscsi_put_conn() to
> remove the connection from the children list of session and free the
> connection at last.
> However for qla4xxx, it is not the case. The ->destroy_conn() callback
> of qla4xxx will keep the connection in the session conn_list and doesn't
> use iscsi_put_conn() to free the initial reference counter. Therefore,
> it seems necessary to keep the iscsi_put_conn() in the
> iscsi_iter_destroy_conn_fn(), otherwise, there will be memory leak
> problem.
>
I must have thought we did a unregister instead of remove for
some reason. Thanks for catching this.
Reviewed-by: Mike Christie <
michael....@oracle.com>