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:   Tue, 5 Dec 2017 20:14:37 +0100
From:   Michal Hocko <mhocko@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Will Deacon <will.deacon@....com>,
        Minchan Kim <minchan@...nel.org>,
        Andrea Argangeli <andrea@...nel.org>,
        Ingo Molnar <mingo@...hat.com>, linux-mm <linux-mm@...ck.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] arch, mm: introduce arch_tlb_gather_mmu_exit

On Tue 05-12-17 10:31:12, Linus Torvalds wrote:
> On Tue, Dec 5, 2017 at 6:58 AM, Michal Hocko <mhocko@...nel.org> wrote:
> >
> > This all is nice but tlb_gather users are not aware of that and this can
> > actually cause some real problems. E.g. the oom_reaper tries to reap the
> > whole address space but it might race with threads accessing the memory [1].
> > It is possible that soft-dirty handling might suffer from the same
> > problem [2] as soon as it starts supporting the feature.
> 
> So we fixed the oom reaper to just do proper TLB invalidates in commit
> 687cb0884a71 ("mm, oom_reaper: gather each vma to prevent leaking TLB
> entry").
> 
> So now "fullmm" should be the expected "exit" case, and it all should
> be unambiguous.
> 
> Do we really have any reason to apply this patch any more?

Well, the point was the clarity. The bad behavior came as a surprise for
the oom reaper and as Minchan mentioned we would see a similar problem
with soft-dirty bits as soon as they are supported on arm64 or
potentially other architectures which might do special handling for exit
case.

So strictly speaking, this doesn't fix any known bug to me. But I would
find it more robust if the very special handling was explicit.
-- 
Michal Hocko
SUSE Labs

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ