Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 16 Sep 2021 10:57:12 -0300
From:   Jason Gunthorpe <jgg@nvidia.com>
To:     Leon Romanovsky <leon@kernel.org>
Cc:     Tao Liu <thomas.liu@ucloud.cn>, dledford@redhat.com,
        haakon.bugge@oracle.com, shayd@nvidia.com, avihaih@nvidia.com,
        linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org,
        thomas.liu@ucloud.com
Subject: Re: [PATCH] RDMA/cma: Fix listener leak in rdma_cma_listen_on_all()
 failure
Message-ID: <20210916135712.GA327412@nvidia.com>
References: <20210913093344.17230-1-thomas.liu@ucloud.cn>
 <20210914195444.GA156389@nvidia.com>
 <YUEtpNgI+Z8ksQjC@unreal>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YUEtpNgI+Z8ksQjC@unreal>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?tZKyj1cqc585SZ1Bc2Hp5trtV5YDglJDM+MVXUR2Mevykr/rr1Uz+srT19CE?=
 =?us-ascii?Q?7wnXUgMmSVAbgFaPLN857tFjfD1Q9b67I+eJGp2oU2FMlv/6De0621fqaqjm?=
 =?us-ascii?Q?Y7cRmw7WIRxUJWZ7hIpwo21RLuuuVOEo+PXupGYbwjtLDTVyqUhKzO5qBlqr?=
 =?us-ascii?Q?nWf1fuhdSDKE9ZSSyC6ey0bnMVbJwdgIaw2wbOLFC7vJZtvLCgRGwysHIjsI?=
 =?us-ascii?Q?SJW9bjoZeDdxkf5R6sq3Yv1z7ZeCY9X4PlyNHE0dZSwxkCi/LDyXapMYPEi7?=
 =?us-ascii?Q?mKJ/L+bV44zihW0VcQRG9vzyN5dW0jW1s/zXYDSorPhfSYZWp72MPE+w5v70?=
 =?us-ascii?Q?NrbNeuVTb1TrGP5xHx4pcgxhXQY3gnbQIfSf44WC+hxKcxK1JDH+ZSgFK4Xz?=
 =?us-ascii?Q?xT5o6XwAt17/3uUEClBRK730+Kixrp7qB102/wo9CLQCXgnrYfvYGWEBtPcN?=
 =?us-ascii?Q?o7CrBdai8YuK3NQSs3F9BCuxm8F6jY/jXYtnL2WZ4J7K6+wAQfKQNeTIOtnY?=
 =?us-ascii?Q?BKF9kjI6vdXgQdC6kphyF3IaQ+MEmSoilev7D9HBuYAO1j8feLrFnfqYgD0k?=
 =?us-ascii?Q?eld+uJevElD8Tw/PNVHCUgl09fwJgBVXijT3+1jVJj6lYhXPQPqYgPizxDJn?=
 =?us-ascii?Q?lPa3iHgDtnAxKKwaIzxZE8PeS0JY9nCUAlHnltJPqeK5t9emepgGiD+FjUbB?=
 =?us-ascii?Q?E6DyAOx48mYTHtuXoYPHJbqacnD0RWgqXvU3k2G0rNDFoBfS9p9giqv64Bje?=
 =?us-ascii?Q?k9jAcEqBdduCsXk+7658Dlkke23rvV0aO26CyOesZ2s6KrkOXT0cvkuaIYOm?=
 =?us-ascii?Q?7xiaotgEuVu2xI3d4x+LPsBCjmYTzVgK2tOuxjUsavrKMa+lsXstFyuUEu6g?=
 =?us-ascii?Q?aw5flbkO9hqZ2RSOsoi07Bd3vYR2d8Yn3G2JRsKNQggK5TRlZXaTdXtZkcgm?=
 =?us-ascii?Q?oP3i5pIBoVjT0Kvtq+z28ZtXQVZWUV/+PiwvvSfallYUj4Uq06aEWRGiNunR?=
 =?us-ascii?Q?1dXgVVUuaZ+cRuC2X8Up3MH3mXfeTaHp+A7WfFMOba5Y07fpd5ppmaufOYDy?=
 =?us-ascii?Q?r1qX7ocyJLWnNjCd8GjsUr9MtYibZ2kB5ia2ALMOiG3u8ff26WtWtAoTUNQ6?=
 =?us-ascii?Q?L5cQlg3LezARIivFaA6ej+iNlcVSpOzhXKQtn/5AgpqXTN363nDQMngaJYFn?=
 =?us-ascii?Q?ZmaAn69B3Eiyr3sR46igq75AAt4iPcM0+p//uQtnjO3NrIeS3i1B4+uGdZJX?=
 =?us-ascii?Q?fiKEzex9wc2MjWY65+TKKTHsQb+Q5e49uDtTyXnx05H9hn7RI3PME2CmzGO2?=
 =?us-ascii?Q?fAQbhDJhP27562s3OtUrUNWb?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 92a25bb2-6b37-4a6d-1832-08d97919e2a5
X-MS-Exchange-CrossTenant-AuthSource: BL0PR12MB5506.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2021 13:57:13.4693
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: QSPzuw+NyYJqZLc/d6G/9wRTEJCpwcWMzGPvw3zQzq16WwIP78qRpXfm8OBjI6vo
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR12MB5176
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Sep 15, 2021 at 02:17:56AM +0300, Leon Romanovsky wrote:

> > +static void cma_cancel_listens(struct rdma_id_private *id_priv)
> > +{
> > +	/*
> > +	 * During _destroy_id() it is not possible for this value to transition
> > +	 * from empty to !empty, test it outside to lock to avoid taking a
> > +	 * global lock on every destroy. Only listen all cases will have
> > +	 * something to do
> > +	 */
> > +	if (list_empty(&id_priv->list))
> > +		return;
> 
> IMHO, it is better do not do such check outside of the lock without real
> gain. It is too subtle to rely on _destroy_id() behaviour.

This arrangement would have solved the syzkaller bugs that are
triggering due to the other logic in _destroy_id() being too subtle
already :\

But it can't be done because priv->list is a total mess

Jason