linux-kernel - Re: Possible duplicate page fault accounting on some archs after commit 4064b9827063

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]

Message-ID: <CAHk-=wgm0_0PjXaSVbrpDfgtn6UbDyWjSRnXvfdebweUYSZ+eA@mail.gmail.com>
Date:   Wed, 10 Jun 2020 09:53:49 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Gerald Schaefer <gerald.schaefer@...ibm.com>
Cc:     Peter Xu <peterx@...hat.com>,
        linux-arch <linux-arch@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        alpha <linux-alpha@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        linux-hexagon@...r.kernel.org, linux-ia64@...r.kernel.org,
        linux-m68k <linux-m68k@...ts.linux-m68k.org>,
        Michal Simek <monstr@...str.eu>, linux-mips@...r.kernel.org,
        Nick Hu <nickhu@...estech.com>,
        Ley Foon Tan <ley.foon.tan@...el.com>,
        openrisc@...ts.librecores.org, linux-parisc@...r.kernel.org,
        linux-riscv@...ts.infradead.org,
        Linux-sh list <linux-sh@...r.kernel.org>,
        sparclinux@...r.kernel.org,
        linux-um <linux-um@...ts.infradead.org>,
        Guan Xuetao <gxt@....edu.cn>, linux-xtensa@...ux-xtensa.org,
        Heiko Carstens <heiko.carstens@...ibm.com>,
        Andrea Arcangeli <aarcange@...hat.com>
Subject: Re: Possible duplicate page fault accounting on some archs after
 commit 4064b9827063

On Wed, Jun 10, 2020 at 8:48 AM Gerald Schaefer
<gerald.schaefer@...ibm.com> wrote:
>
> This was found by coincidence in s390 code, and a quick check showed that
> there are quite a lot of other architectures that seem to be affected in a
> similar way. I'm preparing a fix for s390, by moving the accounting behind
> the retry loop, similar to x86. It is not completely straight-forward, so
> I leave the fix for other archs to the respective maintainers.

Hmm. I wonder if we could move the handling into  handle_mm_fault() itself.

It's _fairly_ trivial to do on the arch side, just as long as you
remember to make the VM_FAULT_MAJOR bit sticky like x86 does with that

        major |= fault & VM_FAULT_MAJOR;

right after handle_mm_fault(). But it certainly doesn't seem like it
would be hard to move into common code in handle_mm_fault() either, by
just not doing the accounting if it's about to return VM_FAULT_RETRY
or VM_FAULT_ERROR.

That said, we want that perf_sw_event() accounting too, so we'd have
to pass in a 'struct regs *' as well. And it's not clear which way
accounting should go for other callers of handle_mm_fault() (ie gup
etc).

So I guess just having architectures fix it up individually and make
sure they don't do it for retry conditions is the right thing to do..

             Linus