From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 25DB5A0093; Fri, 24 Jun 2022 22:46:09 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CBE8F4069D; Fri, 24 Jun 2022 22:46:08 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 1FA06400EF for ; Fri, 24 Jun 2022 22:46:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1656103567; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=T/tH5v34LHNda4nupiHqdOgalTS1X+PUwGJhfpQmKAw=; b=Y+8nFbq1puDcrTlBLwjL6WRa5MrHzlHF8wYyFKEvG/0GPd35x4xqYRg5y1RI7RsB/tga80 JChpeFC8OHomUXczWj9GlHPZCWIXVlXsUDG2OHN7yB7G9qO3FDFMfFTG63ii0QsrGWeLzF jgIa/btGjGukPwiV6e5GmQuzf3/f104= Received: from mail-lf1-f72.google.com (mail-lf1-f72.google.com [209.85.167.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-494-WdahWDfyNrWSIXjjkdpqIg-1; Fri, 24 Jun 2022 16:46:06 -0400 X-MC-Unique: WdahWDfyNrWSIXjjkdpqIg-1 Received: by mail-lf1-f72.google.com with SMTP id bq4-20020a056512150400b0047f7f36efc6so1924396lfb.9 for ; Fri, 24 Jun 2022 13:46:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=T/tH5v34LHNda4nupiHqdOgalTS1X+PUwGJhfpQmKAw=; b=xBpxXOT+vbj/stFXcjSju4t7rUiNayPiqGce3w0uTejWyL/1QuKlMjyWIEE/WheIJA 4chI6m7nKE6wA0tT0fm/0zPmqlXkkVMUba28AxXe8ksFinI0mwReq6AkECR1e754p3RB SVfpBAbqG+60JmCrKo1YGV+R5rVvJJWOIyNZfmlEYu3Rx0s0wCu9WNAL1SM/J5ltXN9N 0RzYNGxF1Sd0CgARt0EU7SD+mFY+w82KuA5cfJovpIU5u9/QIzJld7hA8TIBY3fUU+JJ Q2UeA94fkSCZ/BAjdeiz5hw6grk8KfPIPM40mZs9NRnwdAyqC4+iNL8OhJ1O7+UBoWgr uP+w== X-Gm-Message-State: AJIora88bb3disHEWin+QFpj+UeqdobiE+/AAYUM43iW+GcbZldf9AD7 3d/OrMbhSDFijmYEPGuYtByEgA7xB/W+FLnc5nJQiLQxXGQ7EcumnFbrTJvuIL89BwJKvS/4wmw +EbqImKSGOU37S6uHOJI= X-Received: by 2002:a2e:6e0c:0:b0:255:98fb:cb45 with SMTP id j12-20020a2e6e0c000000b0025598fbcb45mr387244ljc.55.1656103565068; Fri, 24 Jun 2022 13:46:05 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vHNBeKDHM4ZaYGzfZQTHm7FXXHKwNS9SyNMIdTaAmlcLcyO4WvfJuchcWxN18eJ39tkCZTlMWzMKz36/0t+h8= X-Received: by 2002:a2e:6e0c:0:b0:255:98fb:cb45 with SMTP id j12-20020a2e6e0c000000b0025598fbcb45mr387235ljc.55.1656103564853; Fri, 24 Jun 2022 13:46:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Marchand Date: Fri, 24 Jun 2022 22:45:53 +0200 Message-ID: Subject: Re: [PATCH 01/20] baseband/acc100: fix a memory leak in acc100 queue setup To: Weiguo Li , Nicolas Chautru Cc: dev , Akhil Goyal , Maxime Coquelin , Tom Rix Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Tue, Feb 22, 2022 at 7:18 PM Weiguo Li wrote: > > We allocated memory for 'q', we don't free it when null check for 'd' fails > and it will lead to memory leak. > We can move null check for 'd' ahead of the memory allocation to fix it. > > Fixes: 060e76729302 ("baseband/acc100: add queue configuration") > > Signed-off-by: Weiguo Li > --- > drivers/baseband/acc100/rte_acc100_pmd.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c b/drivers/baseband/acc100/rte_acc100_pmd.c > index f86474f7e0..25e9e6435f 100644 > --- a/drivers/baseband/acc100/rte_acc100_pmd.c > +++ b/drivers/baseband/acc100/rte_acc100_pmd.c > @@ -824,6 +824,10 @@ acc100_queue_setup(struct rte_bbdev *dev, uint16_t queue_id, > struct acc100_queue *q; > int16_t q_idx; > > + if (d == NULL) { > + rte_bbdev_log(ERR, "Undefined device"); > + return -ENODEV; > + } Nicolas, .queue_setup is a dev_ops, which means it is invoked after the .probe function was called. Failing to allocate dev_private shoud have been detected earlier, is that correct? If so, this check should simply be dropped, and there is no leak to fix. Please confirm when you have the time. Thanks. -- David Marchand