Re: [PATCH v8 00/17] gfs2: Fix mmap + page fault deadlocks
Linus Torvalds <[email protected]>
| Newsgroups | org.kernel.vger.kvm-ppc,com.redhat.cluster-devel,dev.linux.lists.ocfs2-devel,org.kernel.vger.linux-btrfs,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <CAHk-=wjQqi9cw1Guz6a8oBB0xiQNF_jtFzs3gW0k7+fKN-mB1g@mail.gmail.com> |
On Wed, Oct 27, 2021 at 12:13 PM Catalin Marinas <[email protected]> wrote: > > As an alternative, you mentioned earlier that a per-thread fault status > was not feasible on x86 due to races. Was this only for the hw poison > case? I think the uaccess is slightly different. It's not x86-specific, it's very generic. If we set some flag in the per-thread status, we'll need to be careful about not overwriting it if we then have a subsequent NMI that _also_ takes a (completely unrelated) page fault - before we then read the per-thread flag. Think 'perf' and fetching backtraces etc. Note that the NMI page fault can easily also be a pointer coloring fault on arm64, for exactly the same reason that whatever original copy_from_user() code was. So this is not a "oh, pointer coloring faults are different". They have the same re-entrancy issue. And both the "pagefault_disable" and "fault happens in interrupt context" cases are also the exact same 'faulthandler_disabled()' thing. So even at fault time they look very similar. So we'd have to have some way to separate out only the one we care about. Linus