[dpdk-stable] patch 'mem: mark pages as not accessed when reserving VA' has been queued to stable release 19.11.3

[Luca Boccassi]

On Tue, 2020-06-16 at 10:13 +0200, David Marchand wrote:
> Hello Luca,
> 
> On Fri, Jun 12, 2020 at 10:00 AM Luca Boccassi <bluca at debian.org> 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 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?
> 
> - 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.
> 
> - This first patch fixed the way we mark anonymous pages used by the
> dpdk memory allocator.
> 
> 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 reserving.
> 
> 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.
> 
> 
> 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.
> 
> 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.

-- 
Kind regards,
Luca Boccassi