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 DA8F4A0C41 for ; Thu, 30 Sep 2021 09:51:29 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C4F78410EC; Thu, 30 Sep 2021 09:51:29 +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 BCB96410EC for ; Thu, 30 Sep 2021 09:51:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1632988288; 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=MLt3OmWz/TD41h58XhEIQL9V7uWTlpxPTOPyRvS2566l8HSBJ3mPcLGZtv+WLw9oDnMJet DaHA+y3t9tHDzP/epTNpkqdyOFj/nUxTqP6Z91BdgIYgdt6BltJ2qvDY+4ZPzSgFh1vkLl 9ZMa0sYaaUVb/ww6AcgCXHO3Zt3xZXM= Received: from mail-lf1-f71.google.com (mail-lf1-f71.google.com [209.85.167.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-394-ljn8tgNWMcm0poCwM0C58g-1; Thu, 30 Sep 2021 03:51:11 -0400 X-MC-Unique: ljn8tgNWMcm0poCwM0C58g-1 Received: by mail-lf1-f71.google.com with SMTP id c6-20020a05651200c600b003fc6d39efa4so4797391lfp.12 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=klPAGO8zGq+N9NkJKiegFVg9QqSny8ArnX+eBdWDO5rq7KgbskiQ/LSNXqG3zjS81f bH2xn3aWcOGCk6Pzbsc7wbvA7HOjuITnz0Vy5y97y+XJzb7Udgp1T5udMO1l2YbAXa7D wZ8eGr5p6Wkl6tvqZF5J6LL/SToYIizwAO42TZwfeHvkoA3gD7/xihK6e0VkWQq8KRgD 256GlSAqeECUZdRAf5xr06mJ7tmIN6MA5nEU5EaAmAuXH1beiO9WwE/FktwQeI0tJHgm aSpRXuV5eUoXEbVp8o3seDIuStAxDmJBsQrU4ZPwdtDQNehmSu47H5267SHq797cHg3f CU2w== X-Gm-Message-State: AOAM5303/8GcojUGxX+Ja06uawUlTsIxw9QqJbuEPFCyzHXQWuUd6Xzs Yy/glWMwQDC5pUHUMfLLfj8BfUX9FLKXVuS3dwbjQk2G5jCAwMrOYaQkQx055z6IViJjB7AdGA6 ck3JQ9yJMAafH9mPBUX6WWVw= X-Received: by 2002:ac2:4e0d:: with SMTP id e13mr4305017lfr.560.1632988270329; 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-stable] [PATCH 1/3] bus/vmbus: fix leak on device scan X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" 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