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 B4332A04A3 for ; Tue, 16 Jun 2020 12:41:52 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 982101BF4E; Tue, 16 Jun 2020 12:41:52 +0200 (CEST) Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by dpdk.org (Postfix) with ESMTP id ABDA91BF4E for ; Tue, 16 Jun 2020 12:41:50 +0200 (CEST) Received: by mail-wr1-f66.google.com with SMTP id x13so20211547wrv.4 for ; Tue, 16 Jun 2020 03:41:50 -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=ASuFCeMom+VHdf6xan6wQCOg90QwRIS5bn2fdZAtcDk=; b=Ldacj1JUC2wvrh8lklRRcDJxbzSs8nZcI/yVOycQ7LkbYpgeaY3cOSTWi5uvxIxGKs 0CJ2h7jamPlCQfUxvV/Em3PfUQxbn/bXiOSgk9bVGKXtwUlX6zxRQ7KJV2uYqIVobQSu IPQ7m7UyaAQPvoLE/TwAt/WVBwdQuo7ahVA4EdHheuaELvtW983yiCI6KLRSuOI9C8jS LM2fDcFHijr2wykwmYEBCM+QSRBQUlVSsk3zt+C1ftzWnxSoF1/i05QFsJ0wbX6k9K3A bH/c669kXSyCWYVbnnPVO/r+aWvUqi4zbCBPUqPrMD8eEVHefDcVPq/XN0/mQIMr9rqx YJoA== X-Gm-Message-State: AOAM530dRGQovyGJGIGrVt5SUOr88MObRvWKP+kmqyRgggtw2su9gNzm /KUa2WKZIA0qcdhoKaLSJZr2jT6CrxgJrA== X-Google-Smtp-Source: ABdhPJyE0GvZ+MPpDa1dqls860ZGkkw021V2FdJxp8ReEjp5ZsDk2aB/lyI1iSnvx8os83HhfrXjMA== X-Received: by 2002:adf:fd4b:: with SMTP id h11mr2306878wrs.209.1592304110384; Tue, 16 Jun 2020 03:41:50 -0700 (PDT) Received: from localhost ([88.98.246.218]) by smtp.gmail.com with ESMTPSA id 23sm3378213wmg.10.2020.06.16.03.41.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Jun 2020 03:41:49 -0700 (PDT) Message-ID: <071476a005abba74200efd9e3df0e3cd6dc4da41.camel@debian.org> From: Luca Boccassi To: David Marchand Cc: Kevin Traynor , Andrea Arcangeli , Maxime Coquelin , Aaron Conole , Anatoly Burakov , dpdk stable , Li Feng Date: Tue, 16 Jun 2020 11:41:49 +0100 In-Reply-To: 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-16 at 10:13 +0200, David Marchand wrote: > Hello Luca, >=20 > On Fri, Jun 12, 2020 at 10:00 AM Luca Boccassi wrote: > > On Tue, 2020-06-09 at 15:14 +0100, Luca Boccassi wrote: > > > On Tue, 2020-06-09 at 14:45 +0100, Kevin Traynor wrote: > > > > Hi, discussed this patch for 18.11 with David and he pointed out th= at > > > > there is a fix for it on master: > > >=20 > > > Uh, I wonder how it got left behind, strange - how critical is it? An= d > > > how safe is it to pick up now, when validation has already started? >=20 > - On the reason of why it was left behind, iiuc, Kevin thought it was > because of how the git-log-fixes.sh script works and this patch was > not marked as a fix in master. >=20 > - This first patch fixed the way we mark anonymous pages used by the > dpdk memory allocator. >=20 > At initialisation, the dpdk memory allocator reserves anonymous > mappings for later uses. > Before this patch, it was instructing the kernel the mapping was used > for reading with PROT_READ (which has some side effects, for > applications calling mlockall()). > The dpdk memory allocator has no actual need at the time of the > reservation, it switches to the right memory protection when using the > mapping. > So the first patch switched the memory protection to PROT_NONE when reser= ving. >=20 > Later when the dpdk memory allocator frees some memory and does not > use a mapping, the memory protection on this mapping is left untouched > as I forgot to set it back to PROT_NONE: this is what the 2nd patch > from Li Feng addresses. >=20 >=20 > The first patch landed in master at the start of 20.05 and we lived in > this state for a month. > The second patch got merged just before tagging 20.05-rc1. > "Real" validation happened with both patches applied. >=20 > I can understand your reluctance at touching the memory allocator now > that validation for 19.11.3 started, but with only the first patch, we > end up with an intermediate behavior in the dpdk memory allocator. > I would go with backporting the second patch. Ok, thank you. I will backport the patch. --=20 Kind regards, Luca Boccassi