From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752113AbdHPPcl (ORCPT ); Wed, 16 Aug 2017 11:32:41 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33886 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751556AbdHPPck (ORCPT ); Wed, 16 Aug 2017 11:32:40 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com D692C745C8 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=dledford@redhat.com Message-ID: <1502897557.33760.12.camel@redhat.com> Subject: Re: [PATCH] IB/core: fix memory leak on ah on error return path From: Doug Ledford To: Parav Pandit , Johannes Thumshirn , Colin Ian King Cc: Lijun Ou , Wei Hu , Sean Hefty , Hal Rosenstock , "linux-rdma@vger.kernel.org" , "kernel-janitors@vger.kernel.org" , "linux-kernel@vger.kernel.org" Date: Wed, 16 Aug 2017 11:32:37 -0400 In-Reply-To: References: <20170808101054.13800-1-colin.king@canonical.com> <20170808102026.GG3926@linux-x5ow.site> <866a49ab-6f7b-4b46-062b-6230e48da725@canonical.com> <20170808125927.GK3926@linux-x5ow.site> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 16 Aug 2017 15:32:40 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2017-08-08 at 19:48 +0000, Parav Pandit wrote: > Hi, > > I need to top post because comments are unrelated to past discussion. > > rdma_ah_retrieve_dmac() can never fail for RoCE as its returning > pointer from structure ah_attr. > Provider driver doesn't need to check for null pointer as ib/core > would never call provider if it's not RoCE provider. > So this memory leak only exist in theory. > > When its null, driver should WARN_ON/BUG_ON in extreme case, but > that's not necessary either. > > I have patch is progress under internal review that does nice small > cleanup in many provider drivers that eliminates the check > completely. > Waiting for Moni to finish the review. This sounds like a nice patch to push into for-next, but in the meantime I took the V2 of this patch as it silences a checker warning. -- Doug Ledford GPG KeyID: B826A3330E572FDD Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD