From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id B0626A04F6; Tue, 7 Jan 2020 09:43:35 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4FDF71D974; Tue, 7 Jan 2020 09:43:35 +0100 (CET) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by dpdk.org (Postfix) with ESMTP id BFB091D972 for ; Tue, 7 Jan 2020 09:43:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1578386613; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6Q3nYgtg6+LpOSlm4G69z0LRcbbZdBgrbhfeJLCt7ag=; b=LetdbeSprgMgOdWagEGSmEnBJ1hZkcy021FmCafjmQfav+ZGi3zUkMLoSmcMJwX2fV3C7N /kJB/nLsCvtpITHLSM9/7mckVXzoygpWmeAJrPYGOnIY479Ti/A/I8dORNJInYC3ya7Csu EaZUVjO05fZeL2CivhB5gs+guMh7Tsg= Received: from mail-ua1-f72.google.com (mail-ua1-f72.google.com [209.85.222.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-348-tFfmqmgcMou-8z4WFdNLyA-1; Tue, 07 Jan 2020 03:43:29 -0500 Received: by mail-ua1-f72.google.com with SMTP id t26so5316586ual.17 for ; Tue, 07 Jan 2020 00:43:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cU1AyJrLwdCYE8WQWyRQwT4GkLHVHPMJilnxqO0Yi/E=; b=P3kCLY+XpdkAEeNa+od8+CtbuYjw/WSNubcN+YBgWTCE0sNBKMYo0QnqesEimDiJZd 67jOGvXy4Se9I8/DYYHam7OQtkDkPkbSThiBYiPgvDk/nSKMXUsjZAJeb0OOG3Isg3rw 70NmHA/MrZRhFRy7dlDpFZrsmX2IATjBK58qZs/rghsiqytM+rQ5vQNdxc2bgvujtVrw jC+ziLp+43URE99YQb9dzPkIJ+E8mlXI95P9/mm3Y8mhEZsDcIKPIHnIgnB2p3kXM9a2 EU9IjrXhPgsE6sO78ntpSkMo/NSAeWQ7bmwjpd3LRLB5JHmOR2IFCuwA9WwqZQjF1Km5 LgdQ== X-Gm-Message-State: APjAAAWEh7D/YDg4L1OxcQefcrCM8TVKs0Ta9vTEmnStHxGPhzKu7UDk 4YCbzmmxyKvKrFmX0MAz1VOWXnJAl6+d5FUj8pJjWkrPuoqnHnmkPNAE+lVhHBi7DDTIqgFBcFW e8FF4zCKjeBvmqcVpHjI= X-Received: by 2002:ab0:2408:: with SMTP id f8mr56623293uan.126.1578386609436; Tue, 07 Jan 2020 00:43:29 -0800 (PST) X-Google-Smtp-Source: APXvYqzWu3payt0Q02mluyUW02XOKTg1erruniqVDYFErWVflGvIplHCfBCf0KaDBBjMtMvS/Zj4NTiJtyY2iTMS88c= X-Received: by 2002:ab0:2408:: with SMTP id f8mr56623285uan.126.1578386609126; Tue, 07 Jan 2020 00:43:29 -0800 (PST) MIME-Version: 1.0 References: <20200106205553.3696-1-stephen@networkplumber.org> In-Reply-To: <20200106205553.3696-1-stephen@networkplumber.org> From: David Marchand Date: Tue, 7 Jan 2020 09:43:17 +0100 Message-ID: To: Stephen Hemminger Cc: dev , "Burakov, Anatoly" , dpdk stable X-MC-Unique: tFfmqmgcMou-8z4WFdNLyA-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH] mem: fix incorrect munmap in error unwind X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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 Mon, Jan 6, 2020 at 9:56 PM Stephen Hemminger wrote: > > The loop to unwind existing mmaps was only unmapping the > first segment. > > Also, remove obvious redundant assignment. > > Fixes: 66cc45e293ed ("mem: replace memseg with memseg lists") > Cc: anatoly.burakov@intel.com > Cc: stable@dpdk.org > Signed-off-by: Stephen Hemminger > --- > lib/librte_eal/linux/eal/eal_memory.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/lib/librte_eal/linux/eal/eal_memory.c b/lib/librte_eal/linux= /eal/eal_memory.c > index 43e4ffc757bd..cf5b2433614b 100644 > --- a/lib/librte_eal/linux/eal/eal_memory.c > +++ b/lib/librte_eal/linux/eal/eal_memory.c > @@ -1967,9 +1967,8 @@ eal_legacy_hugepage_attach(void) > close(fd); > error: > /* map all segments into memory to make sure we get the addrs */ This looks like a copy of the same loop from a few lines before in the same function. The comment can be removed. > - cur_seg =3D 0; > for (cur_seg =3D 0; cur_seg < i; cur_seg++) { > - struct hugepage_file *hf =3D &hp[i]; > + struct hugepage_file *hf =3D &hp[cur_seg]; > size_t map_sz =3D hf->size; > void *map_addr =3D hf->final_va; > map_addr and map_sz are unnecessary. We should be safe with dereferencing hp if i !=3D 0, but still how about: error: if (hp !=3D NULL && hp !=3D MAP_FAILED) { unsigned int cur_seg; for (cur_seg =3D 0; cur_seg < i; cur_seg++) munmap(hp[cur_seg].final_va, hp[cur_seg].size); munmap(hp, size); } if (fd_hugepage >=3D 0) close(fd_hugepage); return -1; --=20 David Marchand