lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 26 Mar 2020 12:58:09 -0700
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     Rafael Aquini <aquini@...hat.com>,
        Shakeel Butt <shakeelb@...gle.com>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-kselftest@...r.kernel.org, shuah@...nel.org,
        Eric B Munson <emunson@...mai.com>
Subject: Re: [PATCH] tools/testing/selftests/vm/mlock2-tests: fix mlock2
 false-negative errors

On Thu, 26 Mar 2020 07:49:09 +0100 Michal Hocko <mhocko@...nel.org> wrote:

> On Wed 25-03-20 17:49:49, Andrew Morton wrote:
> > On Tue, 24 Mar 2020 11:49:10 -0400 Rafael Aquini <aquini@...hat.com> wrote:
> > 
> > > Thanks Michal!
> > > 
> > >  
> > > Acked-by: Rafael Aquini <aquini@...hat.com>
> > 
> > I'll add
> > Fixes: 9c4e6b1a7027f ("mm, mlock, vmscan: no more skipping pagevecs")
> 
> Wouldn't be this misleading? It would suggest that this commit is
> somehow incorrect. I would consider b3b0d09c7a23 ("selftests: vm: add
> tests for lock on fault") to be a better fit.

Yes, it's a bit misleading.

Or maybe not.  b3b0d09c7a23 was merged in 2015 and worked OK (afaik)
until 9c4e6b1a7027f came along in 2020.  So arguably, 2020's
9c4e6b1a7027f was correct but incomplete, since it failed to repair the
impact upon the test code.

I don't think that kernels prior to 2020's 9c4e6b1a7027f require this
change(?), so we only need to backport this into 5.6.x, which is what
my proposed Fixes: and cc:stable expresses.

> > and cc:stable to this.  Any kernel which has 9c4e6b1a7027f will benefit
> > from this change.
> 
> OK, makes sense with
> Cc: stable # with 9c4e6b1a7027f applied
>  
> > We're getting quite late in the cycle now so I think I'll hold off
> > merging this up until post-5.7-rc1.  It will still get into the stable
> > trees, but a bit later.
> 
> No problem. Nothing really urget. Coincidentaly we've just had a report
> from our partner about this very specific test failure for our
> enterprise kernel as well.

I assume that your kernel has 2020's 9c4e6b1a7027f?

> I will just backport the patch as it seems
> nobody really objects to it.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ