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 E7628A04FE for ; Tue, 9 Jun 2020 16:14:40 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id AFC781F28; Tue, 9 Jun 2020 16:14:40 +0200 (CEST) Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by dpdk.org (Postfix) with ESMTP id 56CA91F28 for ; Tue, 9 Jun 2020 16:14:39 +0200 (CEST) Received: by mail-wr1-f68.google.com with SMTP id p5so21485064wrw.9 for ; Tue, 09 Jun 2020 07:14:39 -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=t/MqFxbUCf2HusDSzJt1uGbfq7UEeg3xNBkuCYAH8nI=; b=RoP3PatkFbIm31mFq4PCQXV+0a42cneTYPKK6aQkK/MXq0O8BUoHHC+LAwnepM7SiA DjLXEAI1L4AadIymH4me1f1CDlaybKDzBVlE4RGr10EV3FNijsdEvPSMzNgc+i5qNl1H eYAQ+Z6BJ0C7RVq7FtyPycy1tVITNsO1KnW7xZMtQS8Tp3OzfkXa6eT9/hpahy4sJn2m 7dH3jAKWvUt7qbnDyojCGLcwHDAcAmGW/u/mu6uSvAPcDaXkaEoRJUwv0H5C2ofjBM5g 4MwKcCyZpAxZ7LuIOyoTvNP+EXUN3QzMNXmB4COzpzwN3MTZXUtIkPydGvDc0SPwfmKc nIBw== X-Gm-Message-State: AOAM531YTZ/Gzb76RE51EAoItjwSjYxcvJblRWSOdD37GknSI4f1C8BS sSYYCbcjagDeg0r29IrdF8g= X-Google-Smtp-Source: ABdhPJzU0gSryRIWvmy7JelR4bXBgV8+5glIwgdXRj2Ukj5eFVzlcWRT2k9GTCB8Jd/l99x7OXD+SA== X-Received: by 2002:a5d:5389:: with SMTP id d9mr5049437wrv.77.1591712078971; Tue, 09 Jun 2020 07:14:38 -0700 (PDT) Received: from localhost ([88.98.246.218]) by smtp.gmail.com with ESMTPSA id h188sm3227801wmh.2.2020.06.09.07.14.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Jun 2020 07:14:37 -0700 (PDT) Message-ID: <39a62e6f200444d3386504ab27f14d916fdb4ece.camel@debian.org> From: Luca Boccassi To: Kevin Traynor , David Marchand Cc: Andrea Arcangeli , Maxime Coquelin , Aaron Conole , Anatoly Burakov , dpdk stable , fengli@smartx.com Date: Tue, 09 Jun 2020 15:14:36 +0100 In-Reply-To: <06e1bc7c-d41d-e575-2460-b2cb4ff0cda9@redhat.com> References: <20200519125804.104349-1-luca.boccassi@gmail.com> <20200519125804.104349-11-luca.boccassi@gmail.com> <06e1bc7c-d41d-e575-2460-b2cb4ff0cda9@redhat.com> 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 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 rebasi= ng > > needed to apply to the stable branch. If there were code changes for re= basing > > (ie: not only metadata diffs), please double check that the rebase was > > correctly done. > >=20 > > Thanks. > >=20 > > Luca Boccassi > >=20 > > --- > > From d0e456e9b1af8594ed22382e33bc6e1d5acec994 Mon Sep 17 00:00:00 2001 > > 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 not > > 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 use > > of it. > >=20 > > It also has the nice effect of getting those pages skipped by the kerne= l > > 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: 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? --=20 Kind regards, Luca Boccassi