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 70A61A00BE for ; Fri, 12 Jun 2020 10:00:38 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 32E94FFA; Fri, 12 Jun 2020 10:00:38 +0200 (CEST) Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by dpdk.org (Postfix) with ESMTP id 08A95FFA for ; Fri, 12 Jun 2020 10:00:37 +0200 (CEST) Received: by mail-wr1-f67.google.com with SMTP id q11so8747668wrp.3 for ; Fri, 12 Jun 2020 01:00:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-transfer-encoding:user-agent:mime-version; bh=d9OlTqCuFHD8wKE+SmfqquAZt3wmmc9inGutYPoXyQs=; b=blPnfMOJRoR1PzlW7AnM6sSsC75ZSX6QMoEIAPyLYvKfho6V8G1A73uub8m55HsMwL UX9i5mfGT3h4FNzY+eOypDlMpbBcBpUU6CgBFJP+6/1f+z+yLn0D5NGEGVYE7SYUpgUi ZH8tccCXGHXGOcI+5keEXqZmxILbv6mLToOFw9NF5qboLpeR0jAs/MZfCCI9EpEa/XIH Xo7iyLOuPLttvs9eLVnOk3u77ZhLJN2/ztdf6Sh5A+8iBg9NiilXqP6PaqDMm9kpp7S+ RIm4OZ5WuNkIrcAweRODHUDRCAjXm5cap7rROX70TzS+KkVT0OFcENrM5nER9C1LIq+Z mjeg== X-Gm-Message-State: AOAM530irDhZTOIrnhF7B77nzAVxJyWkYhvorftcv90p20rhwtgDDjqp ViWHi/HxjIcX00ffbiNpHpE= X-Google-Smtp-Source: ABdhPJxN6ttE7dzKQx4rSktMjj9DqmGNZKXRgIU8BrqZ4tYqKpLfSjjL4y/NXz0JrWdJ5c+aniqVhA== X-Received: by 2002:a05:6000:104f:: with SMTP id c15mr13501553wrx.391.1591948836603; Fri, 12 Jun 2020 01:00:36 -0700 (PDT) Received: from localhost ([88.98.246.218]) by smtp.gmail.com with ESMTPSA id o15sm8847876wrv.48.2020.06.12.01.00.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Jun 2020 01:00:35 -0700 (PDT) Message-ID: From: Luca Boccassi To: Kevin Traynor , David Marchand Cc: Andrea Arcangeli , Maxime Coquelin , Aaron Conole , Anatoly Burakov , dpdk stable , fengli@smartx.com Date: Fri, 12 Jun 2020 09:00:34 +0100 In-Reply-To: <39a62e6f200444d3386504ab27f14d916fdb4ece.camel@debian.org> References: <20200519125804.104349-1-luca.boccassi@gmail.com> <20200519125804.104349-11-luca.boccassi@gmail.com> <06e1bc7c-d41d-e575-2460-b2cb4ff0cda9@redhat.com> <39a62e6f200444d3386504ab27f14d916fdb4ece.camel@debian.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 Subject: Re: [dpdk-stable] patch 'mem: mark pages as not accessed when reserving VA' has been queued to stable release 19.11.3 X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 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 Tue, 2020-06-09 at 15:14 +0100, Luca Boccassi wrote: > On Tue, 2020-06-09 at 14:45 +0100, Kevin Traynor wrote: > > On 19/05/2020 13:53, luca.boccassi@gmail.com wrote: > > > Hi, > > >=20 > > > FYI, your patch has been queued to stable release 19.11.3 > > >=20 > > > Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet. > > > It will be pushed if I get no objections before 05/21/20. So please > > > shout if anyone has objections. > > >=20 > > > Also note that after the patch there's a diff of the upstream commit = vs the > > > patch applied to the branch. This will indicate if there was any reba= sing > > > needed to apply to the stable branch. If there were code changes for = rebasing > > > (ie: not only metadata diffs), please double check that the rebase wa= s > > > correctly done. > > >=20 > > > Thanks. > > >=20 > > > Luca Boccassi > > >=20 > > > --- > > > From d0e456e9b1af8594ed22382e33bc6e1d5acec994 Mon Sep 17 00:00:00 200= 1 > > > From: David Marchand > > > Date: Mon, 9 Mar 2020 15:54:42 +0100 > > > Subject: [PATCH] mem: mark pages as not accessed when reserving VA > > >=20 > > > [ upstream commit 8a4baf06c17a806696fb10aba36fce7471983028 ] > > >=20 > > > When the memory allocator reserves virtual addresses, it still does n= ot > > > know what they will be used for. > > > Besides, huge areas are reserved for memory hotplug in multiprocess > > > setups. But most of the pages are unused in the whole life of the > > > processes. > > >=20 > > > Change protection mode to PROT_NONE when only reserving VA. > > > The memory allocator already switches to the right mode when making u= se > > > of it. > > >=20 > > > It also has the nice effect of getting those pages skipped by the ker= nel > > > when calling mlockall() or when a coredump gets generated. > > >=20 > >=20 > > Hi, discussed this patch for 18.11 with David and he pointed out that > > there is a fix for it on master: >=20 > Uh, I wonder how it got left behind, strange - how critical is it? And > how safe is it to pick up now, when validation has already started? Ping - David, what do you think about the above questions? --=20 Kind regards, Luca Boccassi