Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 22 Nov 2022 10:03:31 -0400
From:   Jason Gunthorpe <jgg@ziepe.ca>
To:     Wang Yufen <wangyufen@huawei.com>
Cc:     leon@kernel.org, markzhang@nvidia.com, haakon.bugge@oracle.com,
        mbloch@nvidia.com, sean.hefty@intel.com, rolandd@cisco.com,
        linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] infiniband: cma: fix the dev refcnt leak
Message-ID: <Y3zWs1m7m5D3+BJW@ziepe.ca>
References: <1669099673-12213-1-git-send-email-wangyufen@huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1669099673-12213-1-git-send-email-wangyufen@huawei.com>
Precedence: bulk

On Tue, Nov 22, 2022 at 02:47:53PM +0800, Wang Yufen wrote:
> Syzbot report the following issue:
>   infiniband syj1: RDMA CMA: cma_listen_on_dev, error -98
>   unregister_netdevice: waiting for vlan0 to become free. Usage count = 2
> 
> The causes are as follows:
> 
> rdma_listen()
>   rdma_bind_addr()
>     cma_acquire_dev_by_src_ip()
>       cma_attach_to_dev()
>         _cma_attach_to_dev()
>           cma_dev_get()
> 
>   cma_check_port()
>   <--The return value is -98， goto err
> 
> err:
> <-- The error handling here is missing the operation of cma_release_dev.
> 
> To fix, add cma_release_dev to error handing.
> 
> Fixes: e51060f08a61 ("IB: IP address based RDMA connection manager")
> Reported-by: syzbot+5e70d01ee8985ae62a3b@syzkaller.appspotmail.com
> Signed-off-by: Wang Yufen <wangyufen@huawei.com>
> ---
>  drivers/infiniband/core/cma.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
> index 26d1772..3a50a8e 100644
> --- a/drivers/infiniband/core/cma.c
> +++ b/drivers/infiniband/core/cma.c
> @@ -4049,6 +4049,9 @@ int rdma_listen(struct rdma_cm_id *id, int backlog)
>  	return 0;
>  err:
>  	id_priv->backlog = 0;
> +	if (id_priv->cma_dev)
> +		cma_release_dev(id_priv);
> +

I'm not sure about this, the dev is released during _destroy_id()

Is something leaking an entire CM id or is there something wrong with
_destroy_id() ?

Jason