On Sat, 2 Nov 2024 06:18:54 +0900 Asahi Lina <lina@xxxxxxxxxxxxx> wrote:
>
>
> On 11/2/24 4:07 AM, Andrew Morton wrote:
> > On Fri, 01 Nov 2024 21:08:02 +0900 Asahi Lina <lina@xxxxxxxxxxxxx> wrote:
> >
> >> If the source page is a PFN mapping, we copy back from userspace.
> >> However, if this fault is a remote access, we cannot use
> >> __copy_from_user_inatomic. Instead, use access_remote_vm() in this case.
> >>
> >> Fixes WARN and incorrect zero-filling when writing to CoW mappings in
> >> a remote process, such as when using gdb on a binary present on a DAX
> >> filesystem.
> >>
> >> [ 143.683782] ------------[ cut here ]------------
> >> [ 143.683784] WARNING: CPU: 1 PID: 350 at mm/memory.c:2904 __wp_page_copy_user+0x120/0x2bc
> >>
> >> ...
> >>
> >
> > Thanks. I assume we should backport this into earlier kernels?
> >
> > If so, a Fixes: target is desired, to tell people how far back in time
> > it should be ported.
>
> I think so? I'm not sure how back the bug goes though, possibly a long
> time...
>
> > I think it's
> >
> > 83d116c53058 ("mm: fix double page fault on arm64 if PTE_AF is cleared").
>
> That doesn't sound right. The old code prior to the patch still had the
> __copy_from_user_inatomic() fallback path so it should still have the
> same problem. That fallback goes back to:
>
> 6aab341e0a28 ("mm: re-architect the VM_UNPAGED logic")
>
> But the ptrace code back then doesn't seem to be using that codepath at
> all, so that's meaningless. I think this is the proper tag:
>
> 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
>
> That's when GUP started working for DAX mappings at all, and if my
> reading of the code is correct, at that point do_wp_page() was only
> grabbing the struct page for normal pages to pass to wp_page_copy()
> (triggering the fallback path for DAX mappings). The code has moved
> around a lot today but has the same logic, so I think it's been broken
> since then.
Cool, thanks.
> Should I resend it with the Fixes tag?
That's OK, I edited the mm.git changelog.
