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 03F0AA0C41; Thu, 30 Sep 2021 09:51:31 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E7F94410F0; Thu, 30 Sep 2021 09:51:30 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mails.dpdk.org (Postfix) with ESMTP id F210B410F0 for ; Thu, 30 Sep 2021 09:51:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1632988289; 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=6hevqSh0ncL50rEyiZBH5qK4myvm+x+9bJtNQ5AYLew=; b=Phnq6qGfnIxvU09DrXHmID3XBEgqr3+HvR7+oGA110+aZHLzsCLvfPqd+SddPSB6tSdKW2 sPTlc/2OKNJr9Jps3cOxi1FN9fjMnDwZj5gZ6XpPPghq3osF9iL1RzBFYdEStYq4Hn2yrw 9FeNw/KFFgNU1C0P8yV8KVN29kwq9KI= Received: from mail-lf1-f70.google.com (mail-lf1-f70.google.com [209.85.167.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-553-cVmWk5w5NB23iuLm1T3Zaw-1; Thu, 30 Sep 2021 03:51:12 -0400 X-MC-Unique: cVmWk5w5NB23iuLm1T3Zaw-1 Received: by mail-lf1-f70.google.com with SMTP id x4-20020a056512078400b003fc8e963f1dso4794146lfr.5 for ; Thu, 30 Sep 2021 00:51:11 -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=6hevqSh0ncL50rEyiZBH5qK4myvm+x+9bJtNQ5AYLew=; b=gIRK6rd9lF7+6pypAQKQfhPRp59bxZsqXp78+Buy9pCXefI+f6Q/XCouUzB/F/SAEM c5ni16efQcf7zM/OUVI1HhpBFaKyKAOP9EH9o3TCuxeBR9KY11u4kFI4SyHywzFzq/m/ IoqWJevrU5OBN4r7/y5D10Qq6OdHvUxn7BkxJbs5x6mzNaPoSC4Egf7kD4IBQpW3oigd JLzRBKl3wIKDJXii+j09+VgcpzAbBKCX6HP1Rnj76Uzr/O073BxSxD7No6k6ctiQQAut PuGSa2T0nxgrL1lbYN0+1/FZ/wrzpl/QeglDYsVDaq2vVPDLTrUX27XMIdwBmuuDybmt 2gvQ== X-Gm-Message-State: AOAM5311dPt+9rK3nVpAvGfNYUlz2ukYcZE6zCGFzRL+TvQbcM/bR6Fm xxm9lo58NCUhFVaYCv0bGkgZ4fMKzm6myWT2lZIXQ5sK05mNGwx1KLb/j76CdK5CXc5cdm8DjVH jY8/Ah3mmsXDsl5d5atM= X-Received: by 2002:ac2:4e0d:: with SMTP id e13mr4305015lfr.560.1632988270327; Thu, 30 Sep 2021 00:51:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwEaBoaIE9R54YhXOiYXYxxEC0KYmBhL0ywEuV9lId541Zh5Q/v+MuCyuxNxeCVoLY0I22vjKoHeSY+QfdGnas= X-Received: by 2002:ac2:4e0d:: with SMTP id e13mr4304993lfr.560.1632988270150; Thu, 30 Sep 2021 00:51:10 -0700 (PDT) MIME-Version: 1.0 References: <20210917082313.21934-1-david.marchand@redhat.com> <20210917082313.21934-2-david.marchand@redhat.com> In-Reply-To: From: David Marchand Date: Thu, 30 Sep 2021 09:50:58 +0200 Message-ID: To: Long Li Cc: "dev@dpdk.org" , "aconole@redhat.com" , "zhihongx.peng@intel.com" , "stable@dpdk.org" , Stephen Hemminger 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" Subject: Re: [dpdk-dev] [PATCH 1/3] bus/vmbus: fix leak on device scan 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 Sender: "dev" On Wed, Sep 29, 2021 at 10:57 PM Long Li wrote: > > > Subject: [PATCH 1/3] bus/vmbus: fix leak on device scan > > > > Caught running ASAN. > > > > The device name is leaked on scan. > > rte_device name field being a const, use the private vmbus struct to store the > > device name and point at it. > > > > Fixes: 831dba47bd36 ("bus/vmbus: add Hyper-V virtual bus support") > > Cc: stable@dpdk.org > > > > Signed-off-by: David Marchand > > --- > > drivers/bus/vmbus/linux/vmbus_bus.c | 5 ++++- > > drivers/bus/vmbus/rte_bus_vmbus.h | 1 + > > 2 files changed, 5 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/bus/vmbus/linux/vmbus_bus.c > > b/drivers/bus/vmbus/linux/vmbus_bus.c > > index 3c924eee14..d8eb07d398 100644 > > --- a/drivers/bus/vmbus/linux/vmbus_bus.c > > +++ b/drivers/bus/vmbus/linux/vmbus_bus.c > > @@ -242,7 +242,7 @@ vmbus_scan_one(const char *name) > > return -1; > > > > dev->device.bus = &rte_vmbus_bus.bus; > > - dev->device.name = strdup(name); > > + dev->device.name = dev->name = strdup(name); > > > I suggest not to add a "name" in struct rte_vmbus_device. How about defining a local variable in this function, like: > dev->device.name = dev_name = strdup(name); What is your concern for storing the name? rte_device name only points at some location where the name is stored. In general this storage is in the bus object or (in some buses) the devarg that resulted in the rte_device object creation. If we won't store the name in the bus object, then we lose the ability to release the name later. This is probably fine as long as we never release rte_vmbus_device objects which is the case atm. But I don't understand why vmbus should be an exception when comparing to other buses. -- David Marchand