From: Miklos Szeredi <miklos@szeredi.hu>
To: David Hildenbrand <david@redhat.com>
Cc: xingwei lee <xrivendell7@gmail.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
samsun1006219@gmail.com, syzkaller-bugs@googlegroups.com,
linux-mm <linux-mm@kvack.org>, Mike Rapoport <rppt@kernel.org>
Subject: Re: BUG: unable to handle kernel paging request in fuse_copy_do
Date: Fri, 22 Mar 2024 22:13:55 +0100 [thread overview]
Message-ID: <CAJfpegub5Ny9kyX+dDbRwx7kd6ZdxtOeQ9RTK8n=LGGSzA9iOQ@mail.gmail.com> (raw)
In-Reply-To: <620f68b0-4fe0-4e3e-856a-dedb4bcdf3a7@redhat.com>
On Fri, 22 Mar 2024 at 22:08, David Hildenbrand <david@redhat.com> wrote:
>
> On 22.03.24 20:46, Miklos Szeredi wrote:
> > On Fri, 22 Mar 2024 at 16:41, David Hildenbrand <david@redhat.com> wrote:
> >
> >> But at least the vmsplice() just seems to work. Which is weird, because
> >> GUP-fast should not apply (page not faulted in?)
> >
> > But it is faulted in, and that indeed seems to be the root cause.
>
> secretmem mmap() won't populate the page tables. So it's not faulted in yet.
>
> When we GUP via vmsplice, GUP-fast should not find it in the page tables
> and fallback to slow GUP.
>
> There, we seem to pass check_vma_flags(), trigger faultin_page() to
> fault it in, and then find it via follow_page_mask().
>
> ... and I wonder how we manage to skip check_vma_flags(), or otherwise
> managed to GUP it.
>
> vmsplice() should, in theory, never succeed here.
>
> Weird :/
>
> > Improved repro:
> >
> > #define _GNU_SOURCE
> >
> > #include <fcntl.h>
> > #include <unistd.h>
> > #include <stdio.h>
> > #include <errno.h>
> > #include <sys/mman.h>
> > #include <sys/syscall.h>
> >
> > int main(void)
> > {
> > int fd1, fd2;
> > int pip[2];
> > struct iovec iov;
> > char *addr;
> > int ret;
> >
> > fd1 = syscall(__NR_memfd_secret, 0);
> > addr = mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_SHARED, fd1, 0);
> > ftruncate(fd1, 7);
> > addr[0] = 1; /* fault in page */
Here the page is faulted in and GUP-fast will find it. It's not in
the kernel page table, but it is in the user page table, which is what
matter for GUP.
Thanks,
Miklos
next prev parent reply other threads:[~2024-03-22 21:14 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-21 7:52 BUG: unable to handle kernel paging request in fuse_copy_do xingwei lee
2024-03-22 13:50 ` Miklos Szeredi
2024-03-22 15:41 ` David Hildenbrand
2024-03-22 19:46 ` Miklos Szeredi
2024-03-22 21:08 ` David Hildenbrand
2024-03-22 21:13 ` Miklos Szeredi [this message]
2024-03-22 21:18 ` David Hildenbrand
2024-03-22 21:33 ` David Hildenbrand
2024-03-22 21:37 ` David Hildenbrand
2024-03-22 21:56 ` David Hildenbrand
2024-03-24 10:29 ` Mike Rapoport
2024-03-25 11:21 ` Miklos Szeredi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJfpegub5Ny9kyX+dDbRwx7kd6ZdxtOeQ9RTK8n=LGGSzA9iOQ@mail.gmail.com' \
--to=miklos@szeredi.hu \
--cc=david@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rppt@kernel.org \
--cc=samsun1006219@gmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=xrivendell7@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.