* Re: Add linux-um archives to lore.kernel.org?
From: Konstantin Ryabitsev @ 2022-11-18 21:41 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Richard Weinberger, anton ivanov, Johannes Berg, Bjorn Helgaas,
linux-um, linux-kernel, helpdesk, David Woodhouse
In-Reply-To: <CAMuHMdV5pbH-=8z0Qg2_t8ekzTQjZUopPrZeJHWs+z0DzJAZYg@mail.gmail.com>
On Thu, Nov 17, 2022 at 09:58:31AM +0100, Geert Uytterhoeven wrote:
> Is there anything from us you are still waiting for?
> Thanks again!
Nope, it's just waiting for some cycles. I should be able to get it done soon.
Thank you for your patience.
Cheers,
-K
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
^ permalink raw reply
* Re: [PATCH mm-unstable v1 05/20] mm: add early FAULT_FLAG_WRITE consistency checks
From: Vlastimil Babka @ 2022-11-18 17:03 UTC (permalink / raw)
To: David Hildenbrand, linux-kernel
Cc: x86, linux-alpha, linux-arm-kernel, linux-ia64, linux-mips,
linuxppc-dev, sparclinux, linux-um, etnaviv, dri-devel,
linux-samsung-soc, linux-rdma, linux-media, linux-fsdevel,
linux-mm, linux-perf-users, linux-security-module,
linux-kselftest, Linus Torvalds, Andrew Morton, Jason Gunthorpe,
John Hubbard, Peter Xu, Greg Kroah-Hartman, Andrea Arcangeli,
Hugh Dickins, Nadav Amit, Matthew Wilcox, Mike Kravetz,
Muchun Song, Shuah Khan, Lucas Stach, David Airlie, Oded Gabbay,
Arnd Bergmann, Christoph Hellwig, Alex Williamson
In-Reply-To: <20221116102659.70287-6-david@redhat.com>
On 11/16/22 11:26, David Hildenbrand wrote:
> Let's catch abuse of FAULT_FLAG_WRITE early, such that we don't have to
> care in all other handlers and might get "surprises" if we forget to do
> so.
>
> Write faults without VM_MAYWRITE don't make any sense, and our
> maybe_mkwrite() logic could have hidden such abuse for now.
>
> Write faults without VM_WRITE on something that is not a COW mapping is
> similarly broken, and e.g., do_wp_page() could end up placing an
> anonymous page into a shared mapping, which would be bad.
>
> This is a preparation for reliable R/O long-term pinning of pages in
> private mappings, whereby we want to make sure that we will never break
> COW in a read-only private mapping.
>
> Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
> ---
> mm/memory.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/mm/memory.c b/mm/memory.c
> index e014435a87db..c4fa378ec2a0 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -5170,6 +5170,14 @@ static vm_fault_t sanitize_fault_flags(struct vm_area_struct *vma,
> */
> if (!is_cow_mapping(vma->vm_flags))
> *flags &= ~FAULT_FLAG_UNSHARE;
> + } else if (*flags & FAULT_FLAG_WRITE) {
> + /* Write faults on read-only mappings are impossible ... */
> + if (WARN_ON_ONCE(!(vma->vm_flags & VM_MAYWRITE)))
> + return VM_FAULT_SIGSEGV;
> + /* ... and FOLL_FORCE only applies to COW mappings. */
> + if (WARN_ON_ONCE(!(vma->vm_flags & VM_WRITE) &&
> + !is_cow_mapping(vma->vm_flags)))
> + return VM_FAULT_SIGSEGV;
> }
> return 0;
> }
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
^ permalink raw reply
* Re: [PATCH mm-unstable v1 04/20] mm: add early FAULT_FLAG_UNSHARE consistency checks
From: Vlastimil Babka @ 2022-11-18 16:45 UTC (permalink / raw)
To: David Hildenbrand, linux-kernel
Cc: x86, linux-alpha, linux-arm-kernel, linux-ia64, linux-mips,
linuxppc-dev, sparclinux, linux-um, etnaviv, dri-devel,
linux-samsung-soc, linux-rdma, linux-media, linux-fsdevel,
linux-mm, linux-perf-users, linux-security-module,
linux-kselftest, Linus Torvalds, Andrew Morton, Jason Gunthorpe,
John Hubbard, Peter Xu, Greg Kroah-Hartman, Andrea Arcangeli,
Hugh Dickins, Nadav Amit, Matthew Wilcox, Mike Kravetz,
Muchun Song, Shuah Khan, Lucas Stach, David Airlie, Oded Gabbay,
Arnd Bergmann, Christoph Hellwig, Alex Williamson
In-Reply-To: <20221116102659.70287-5-david@redhat.com>
On 11/16/22 11:26, David Hildenbrand wrote:
> For now, FAULT_FLAG_UNSHARE only applies to anonymous pages, which
> implies a COW mapping. Let's hide FAULT_FLAG_UNSHARE early if we're not
> dealing with a COW mapping, such that we treat it like a read fault as
> documented and don't have to worry about the flag throughout all fault
> handlers.
>
> While at it, centralize the check for mutual exclusion of
> FAULT_FLAG_UNSHARE and FAULT_FLAG_WRITE and just drop the check that
> either flag is set in the WP handler.
>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
> mm/huge_memory.c | 3 ---
> mm/hugetlb.c | 5 -----
> mm/memory.c | 23 ++++++++++++++++++++---
> 3 files changed, 20 insertions(+), 11 deletions(-)
Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
^ permalink raw reply
* Re: [PATCH mm-unstable v1 01/20] selftests/vm: anon_cow: prepare for non-anonymous COW tests
From: Vlastimil Babka @ 2022-11-18 16:20 UTC (permalink / raw)
To: David Hildenbrand, linux-kernel
Cc: x86, linux-alpha, linux-arm-kernel, linux-ia64, linux-mips,
linuxppc-dev, sparclinux, linux-um, etnaviv, dri-devel,
linux-samsung-soc, linux-rdma, linux-media, linux-fsdevel,
linux-mm, linux-perf-users, linux-security-module,
linux-kselftest, Linus Torvalds, Andrew Morton, Jason Gunthorpe,
John Hubbard, Peter Xu, Greg Kroah-Hartman, Andrea Arcangeli,
Hugh Dickins, Nadav Amit, Matthew Wilcox, Mike Kravetz,
Muchun Song, Shuah Khan, Lucas Stach, David Airlie, Oded Gabbay,
Arnd Bergmann, Christoph Hellwig, Alex Williamson
In-Reply-To: <20221116102659.70287-2-david@redhat.com>
On 11/16/22 11:26, David Hildenbrand wrote:
> Originally, the plan was to have a separate tests for testing COW of
> non-anonymous (e.g., shared zeropage) pages.
>
> Turns out, that we'd need a lot of similar functionality and that there
> isn't a really good reason to separate it. So let's prepare for non-anon
> tests by renaming to "cow".
>
> Signed-off-by: David Hildenbrand <david@redhat.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
^ permalink raw reply
* Re: [PATCH printk v5 00/40] reduce console_lock scope
From: Petr Mladek @ 2022-11-18 14:55 UTC (permalink / raw)
To: John Ogness
Cc: Sergey Senozhatsky, Steven Rostedt, Thomas Gleixner, linux-kernel,
Jason Wessel, Daniel Thompson, Douglas Anderson,
Greg Kroah-Hartman, Jiri Slaby, kgdb-bugreport, linux-serial,
linux-fsdevel, Miguel Ojeda, Richard Weinberger, Anton Ivanov,
Johannes Berg, linux-um, Aaron Tomlin, Luis Chamberlain,
Andy Shevchenko, Ilpo Järvinen, Lukas Wunner,
Geert Uytterhoeven, Geert Uytterhoeven, linux-m68k,
Ard Biesheuvel, linux-efi, linuxppc-dev, Krzysztof Kozlowski,
Alim Akhtar, linux-arm-kernel, linux-samsung-soc, Michal Simek,
Peter Zijlstra, Mathias Nyman, linux-usb, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, netdev, Helge Deller,
Thomas Zimmermann, Javier Martinez Canillas, Juergen Gross,
Boris Ostrovsky, Tom Rix, linux-fbdev, dri-devel
In-Reply-To: <Y3drEOkD1fuZcvV2@alley>
On Fri 2022-11-18 12:22:58, Petr Mladek wrote:
> On Wed 2022-11-16 17:27:12, John Ogness wrote:
> > This is v5 of a series to prepare for threaded/atomic
> > printing. v4 is here [0]. This series focuses on reducing the
> > scope of the BKL console_lock. It achieves this by switching to
> > SRCU and a dedicated mutex for console list iteration and
> > modification, respectively. The console_lock will no longer
> > offer this protection.
>
> The patchset looks ready for linux-next from my POV.
>
> I am going to push it there right now to get as much testing
> as possible before the merge window.
JFYI, the patchset is committed in printk/linux.git,
branch rework/console-list-lock.
I'll eventually merge it into rework/kthreads. But I wanted to have
it separated until it gets some more testing in linux-next and
eventually some more review.
Best Regards,
Petr
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
^ permalink raw reply
* Re: [PATCH printk v5 00/40] reduce console_lock scope
From: Petr Mladek @ 2022-11-18 11:22 UTC (permalink / raw)
To: John Ogness
Cc: Sergey Senozhatsky, Steven Rostedt, Thomas Gleixner, linux-kernel,
Jason Wessel, Daniel Thompson, Douglas Anderson,
Greg Kroah-Hartman, Jiri Slaby, kgdb-bugreport, linux-serial,
linux-fsdevel, Miguel Ojeda, Richard Weinberger, Anton Ivanov,
Johannes Berg, linux-um, Aaron Tomlin, Luis Chamberlain,
Andy Shevchenko, Ilpo Järvinen, Lukas Wunner,
Geert Uytterhoeven, Geert Uytterhoeven, linux-m68k,
Ard Biesheuvel, linux-efi, linuxppc-dev, Krzysztof Kozlowski,
Alim Akhtar, linux-arm-kernel, linux-samsung-soc, Michal Simek,
Peter Zijlstra, Mathias Nyman, linux-usb, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, netdev, Helge Deller,
Thomas Zimmermann, Javier Martinez Canillas, Juergen Gross,
Boris Ostrovsky, Tom Rix, linux-fbdev, dri-devel
In-Reply-To: <20221116162152.193147-1-john.ogness@linutronix.de>
On Wed 2022-11-16 17:27:12, John Ogness wrote:
> This is v5 of a series to prepare for threaded/atomic
> printing. v4 is here [0]. This series focuses on reducing the
> scope of the BKL console_lock. It achieves this by switching to
> SRCU and a dedicated mutex for console list iteration and
> modification, respectively. The console_lock will no longer
> offer this protection.
The patchset looks ready for linux-next from my POV.
I am going to push it there right now to get as much testing
as possible before the merge window.
Any review and comments are still appreciate. We could always
take it back if some critical problems are discovered and
can't be solved easily.
Best Regards,
Petr
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
^ permalink raw reply
* Re: [PATCH mm-unstable v1 20/20] mm: rename FOLL_FORCE to FOLL_PTRACE
From: Peter Zijlstra @ 2022-11-18 11:09 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Hildenbrand, linux-kernel, x86, linux-alpha,
linux-arm-kernel, linux-ia64, linux-mips, linuxppc-dev,
sparclinux, linux-um, etnaviv, dri-devel, linux-samsung-soc,
linux-rdma, linux-media, linux-fsdevel, linux-mm,
linux-perf-users, linux-security-module, linux-kselftest,
Andrew Morton, Jason Gunthorpe, John Hubbard, Peter Xu,
Greg Kroah-Hartman, Andrea Arcangeli, Hugh Dickins, Nadav Amit,
Vlastimil Babka, Matthew Wilcox, Mike Kravetz, Muchun Song,
Shuah Khan, Lucas Stach, David Airlie, Oded Gabbay, Arnd Bergmann,
Christoph Hellwig, Alex Williamson, Oleg Nesterov,
Richard Henderson, Ivan Kokshaysky, Matt Turner, Catalin Marinas,
Will Deacon, Thomas Bogendoerfer, Michael Ellerman,
Nicholas Piggin, Christophe Leroy, David S. Miller,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Richard Weinberger, Anton Ivanov, Johannes Berg,
Eric Biederman, Kees Cook, Alexander Viro,
Arnaldo Carvalho de Melo, Mark Rutland, Alexander Shishkin,
Jiri Olsa, Namhyung Kim, Kentaro Takeda, Tetsuo Handa, Paul Moore,
James Morris, Serge E. Hallyn
In-Reply-To: <CAHk-=wgtEwpR-rE_=cXzecHMZ+zgrx5zf9UfvH0w-mKgckn4=Q@mail.gmail.com>
On Wed, Nov 16, 2022 at 10:16:34AM -0800, Linus Torvalds wrote:
> Following the history of it is a big of a mess, because there's a
> number of renamings and re-organizations, but it seems to go back to
> 2007 and commit b6a2fea39318 ("mm: variable length argument support").
I went back and read parts of the discussions with Ollie, and the
.force=1 thing just magically appeared one day when we were sending
work-in-progress patches back and forth without mention of where it came
from :-/
And I certainly can't remember now..
Looking at it now, I have the same reaction as both you and Kees had, it
seems entirely superflous. So I'm all for trying to remove it.
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
^ permalink raw reply
* Re: [PATCH mm-unstable v1 20/20] mm: rename FOLL_FORCE to FOLL_PTRACE
From: Linus Torvalds @ 2022-11-17 23:20 UTC (permalink / raw)
To: Kees Cook
Cc: David Hildenbrand, linux-kernel, x86, linux-alpha,
linux-arm-kernel, linux-ia64, linux-mips, linuxppc-dev,
sparclinux, linux-um, etnaviv, dri-devel, linux-samsung-soc,
linux-rdma, linux-media, linux-fsdevel, linux-mm,
linux-perf-users, linux-security-module, linux-kselftest,
Andrew Morton, Jason Gunthorpe, John Hubbard, Peter Xu,
Greg Kroah-Hartman, Andrea Arcangeli, Hugh Dickins, Nadav Amit,
Vlastimil Babka, Matthew Wilcox, Mike Kravetz, Muchun Song,
Shuah Khan, Lucas Stach, David Airlie, Oded Gabbay, Arnd Bergmann,
Christoph Hellwig, Alex Williamson, Oleg Nesterov,
Richard Henderson, Ivan Kokshaysky, Matt Turner, Catalin Marinas,
Will Deacon, Thomas Bogendoerfer, Michael Ellerman,
Nicholas Piggin, Christophe Leroy, David S. Miller,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Richard Weinberger, Anton Ivanov, Johannes Berg,
Eric Biederman, Alexander Viro, Peter Zijlstra,
Arnaldo Carvalho de Melo, Mark Rutland, Alexander Shishkin,
Jiri Olsa, Namhyung Kim, Kentaro Takeda, Tetsuo Handa, Paul Moore,
James Morris, Serge E. Hallyn
In-Reply-To: <202211171439.CDE720EAD@keescook>
On Thu, Nov 17, 2022 at 2:58 PM Kees Cook <keescook@chromium.org> wrote:
>
> Oh, er, why does get_arg_page() even need FOLL_FORCE? This is writing the
> new stack contents to the nascent brpm->vma, which was newly allocated
> with VM_STACK_FLAGS, which an arch can override, but they all appear to include
> VM_WRITE | VM_MAYWRITE.
Yeah, it does seem entirely superfluous.
It's been there since the very beginning (although in that original
commit b6a2fea39318 it was there as a '1' to the 'force' argument to
get_user_pages()).
I *think* it can be just removed. But as long as it exists, it should
most definitely not be renamed to FOLL_PTRACE.
There's a slight worry that it currently hides some other setup issue
that makes it matter, since it's been that way so long, but I can't
see what it is.
Linus
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
^ permalink raw reply
* Re: Add linux-um archives to lore.kernel.org?
From: Geert Uytterhoeven @ 2022-11-17 8:58 UTC (permalink / raw)
To: Konstantin Ryabitsev
Cc: Richard Weinberger, anton ivanov, Johannes Berg, Bjorn Helgaas,
linux-um, linux-kernel, helpdesk, David Woodhouse
In-Reply-To: <CAMuHMdV5i3JGtg8e=STuP7SENVOKHAEtZ+WdUw8GPt7j9gH65A@mail.gmail.com>
Hi Konstantin,
On Fri, Oct 14, 2022 at 8:06 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Thu, Oct 13, 2022 at 8:48 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Thu, Oct 13, 2022 at 8:29 PM Konstantin Ryabitsev
> > <konstantin@linuxfoundation.org> wrote:
> > > On Thu, Oct 13, 2022 at 02:57:18PM +0200, Geert Uytterhoeven wrote:
> > > > The first step is
> > > > https://korg.docs.kernel.org/lore.html#requesting-archival-of-an-existing-list
> > > >
> > > > It doesn't make much sense to start collecting archives if the lore
> > > > collector hasn't been activated yet.
> > >
> > > The archiver is now subscribed to the list. Once we have the archives, we can
> > > complete the setup.
> >
> > Thank you, I have triggered the export from Gmail. After I have received
> > the export archive, I will merge it with my local pre-Gmail archives.
>
> I have just sent my merged archive for linux-um.lists.infradead.org
> and the old user-mode-linux-devel.lists.sourceforge.net (starting
> from 2003-09-02) to Konstantin.
Is there anything from us you are still waiting for?
Thanks again!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
^ permalink raw reply
* Re: [PATCH mm-unstable v1 12/20] RDMA/siw: remove FOLL_FORCE usage
From: Jason Gunthorpe @ 2022-11-17 0:46 UTC (permalink / raw)
To: David Hildenbrand
Cc: linux-kernel, x86, linux-alpha, linux-arm-kernel, linux-ia64,
linux-mips, linuxppc-dev, sparclinux, linux-um, etnaviv,
dri-devel, linux-samsung-soc, linux-rdma, linux-media,
linux-fsdevel, linux-mm, linux-perf-users, linux-security-module,
linux-kselftest, Linus Torvalds, Andrew Morton, John Hubbard,
Peter Xu, Greg Kroah-Hartman, Andrea Arcangeli, Hugh Dickins,
Nadav Amit, Vlastimil Babka, Matthew Wilcox, Mike Kravetz,
Muchun Song, Shuah Khan, Lucas Stach, David Airlie, Oded Gabbay,
Arnd Bergmann, Christoph Hellwig, Alex Williamson,
Bernard Metzler, Leon Romanovsky
In-Reply-To: <20221116102659.70287-13-david@redhat.com>
On Wed, Nov 16, 2022 at 11:26:51AM +0100, David Hildenbrand wrote:
> GUP now supports reliable R/O long-term pinning in COW mappings, such
> that we break COW early. MAP_SHARED VMAs only use the shared zeropage so
> far in one corner case (DAXFS file with holes), which can be ignored
> because GUP does not support long-term pinning in fsdax (see
> check_vma_flags()).
>
> Consequently, FOLL_FORCE | FOLL_WRITE | FOLL_LONGTERM is no longer required
> for reliable R/O long-term pinning: FOLL_LONGTERM is sufficient. So stop
> using FOLL_FORCE, which is really only for ptrace access.
>
> Cc: Bernard Metzler <bmt@zurich.ibm.com>
> Cc: Jason Gunthorpe <jgg@ziepe.ca>
> Cc: Leon Romanovsky <leon@kernel.org>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
> drivers/infiniband/sw/siw/siw_mem.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
^ permalink raw reply
* Re: [PATCH mm-unstable v1 11/20] RDMA/usnic: remove FOLL_FORCE usage
From: Jason Gunthorpe @ 2022-11-17 0:45 UTC (permalink / raw)
To: David Hildenbrand
Cc: linux-kernel, x86, linux-alpha, linux-arm-kernel, linux-ia64,
linux-mips, linuxppc-dev, sparclinux, linux-um, etnaviv,
dri-devel, linux-samsung-soc, linux-rdma, linux-media,
linux-fsdevel, linux-mm, linux-perf-users, linux-security-module,
linux-kselftest, Linus Torvalds, Andrew Morton, John Hubbard,
Peter Xu, Greg Kroah-Hartman, Andrea Arcangeli, Hugh Dickins,
Nadav Amit, Vlastimil Babka, Matthew Wilcox, Mike Kravetz,
Muchun Song, Shuah Khan, Lucas Stach, David Airlie, Oded Gabbay,
Arnd Bergmann, Christoph Hellwig, Alex Williamson,
Christian Benvenuti, Nelson Escobar, Leon Romanovsky
In-Reply-To: <20221116102659.70287-12-david@redhat.com>
On Wed, Nov 16, 2022 at 11:26:50AM +0100, David Hildenbrand wrote:
> GUP now supports reliable R/O long-term pinning in COW mappings, such
> that we break COW early. MAP_SHARED VMAs only use the shared zeropage so
> far in one corner case (DAXFS file with holes), which can be ignored
> because GUP does not support long-term pinning in fsdax (see
> check_vma_flags()).
>
> Consequently, FOLL_FORCE | FOLL_WRITE | FOLL_LONGTERM is no longer required
> for reliable R/O long-term pinning: FOLL_LONGTERM is sufficient. So stop
> using FOLL_FORCE, which is really only for ptrace access.
>
> Cc: Christian Benvenuti <benve@cisco.com>
> Cc: Nelson Escobar <neescoba@cisco.com>
> Cc: Jason Gunthorpe <jgg@ziepe.ca>
> Cc: Leon Romanovsky <leon@kernel.org>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
> drivers/infiniband/hw/usnic/usnic_uiom.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
^ permalink raw reply
* Re: [PATCH mm-unstable v1 10/20] RDMA/umem: remove FOLL_FORCE usage
From: Jason Gunthorpe @ 2022-11-17 0:45 UTC (permalink / raw)
To: David Hildenbrand
Cc: linux-kernel, x86, linux-alpha, linux-arm-kernel, linux-ia64,
linux-mips, linuxppc-dev, sparclinux, linux-um, etnaviv,
dri-devel, linux-samsung-soc, linux-rdma, linux-media,
linux-fsdevel, linux-mm, linux-perf-users, linux-security-module,
linux-kselftest, Linus Torvalds, Andrew Morton, John Hubbard,
Peter Xu, Greg Kroah-Hartman, Andrea Arcangeli, Hugh Dickins,
Nadav Amit, Vlastimil Babka, Matthew Wilcox, Mike Kravetz,
Muchun Song, Shuah Khan, Lucas Stach, David Airlie, Oded Gabbay,
Arnd Bergmann, Christoph Hellwig, Alex Williamson,
Leon Romanovsky, Leon Romanovsky
In-Reply-To: <20221116102659.70287-11-david@redhat.com>
On Wed, Nov 16, 2022 at 11:26:49AM +0100, David Hildenbrand wrote:
> GUP now supports reliable R/O long-term pinning in COW mappings, such
> that we break COW early. MAP_SHARED VMAs only use the shared zeropage so
> far in one corner case (DAXFS file with holes), which can be ignored
> because GUP does not support long-term pinning in fsdax (see
> check_vma_flags()).
>
> Consequently, FOLL_FORCE | FOLL_WRITE | FOLL_LONGTERM is no longer required
> for reliable R/O long-term pinning: FOLL_LONGTERM is sufficient. So stop
> using FOLL_FORCE, which is really only for ptrace access.
>
> Tested-by: Leon Romanovsky <leonro@nvidia.com> # Over mlx4 and mlx5.
> Cc: Jason Gunthorpe <jgg@ziepe.ca>
> Cc: Leon Romanovsky <leon@kernel.org>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
> drivers/infiniband/core/umem.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
^ permalink raw reply
* Re: [PATCH mm-unstable v1 20/20] mm: rename FOLL_FORCE to FOLL_PTRACE
From: David Hildenbrand @ 2022-11-16 18:53 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, x86, linux-alpha, linux-arm-kernel, linux-ia64,
linux-mips, linuxppc-dev, sparclinux, linux-um, etnaviv,
dri-devel, linux-samsung-soc, linux-rdma, linux-media,
linux-fsdevel, linux-mm, linux-perf-users, linux-security-module,
linux-kselftest, Andrew Morton, Jason Gunthorpe, John Hubbard,
Peter Xu, Greg Kroah-Hartman, Andrea Arcangeli, Hugh Dickins,
Nadav Amit, Vlastimil Babka, Matthew Wilcox, Mike Kravetz,
Muchun Song, Shuah Khan, Lucas Stach, David Airlie, Oded Gabbay,
Arnd Bergmann, Christoph Hellwig, Alex Williamson, Oleg Nesterov,
Richard Henderson, Ivan Kokshaysky, Matt Turner, Catalin Marinas,
Will Deacon, Thomas Bogendoerfer, Michael Ellerman,
Nicholas Piggin, Christophe Leroy, David S. Miller,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Richard Weinberger, Anton Ivanov, Johannes Berg,
Eric Biederman, Kees Cook, Alexander Viro, Peter Zijlstra,
Arnaldo Carvalho de Melo, Mark Rutland, Alexander Shishkin,
Jiri Olsa, Namhyung Kim, Kentaro Takeda, Tetsuo Handa, Paul Moore,
James Morris, Serge E. Hallyn
In-Reply-To: <CAHk-=wgtEwpR-rE_=cXzecHMZ+zgrx5zf9UfvH0w-mKgckn4=Q@mail.gmail.com>
On 16.11.22 19:16, Linus Torvalds wrote:
> On Wed, Nov 16, 2022 at 2:30 AM David Hildenbrand <david@redhat.com> wrote:
>>
>> Let's make it clearer that functionality provided by FOLL_FORCE is
>> really only for ptrace access.
>
> I'm not super-happy about this one.
>
> I do understand the "let's rename the bit so that no new user shows up".
>
> And it's true that the main traditional use is ptrace.
>
> But from the patch itself it becomes obvious that no, it's not *just*
> ptrace. At least not yet.
>
> It's used for get_arg_page(), which uses it to basically look up (and
> install) pages in the newly created VM.
>
> Now, I'm not entirely sure why it even uses FOLL_FORCE, - I think it
> might be historical, because the target should always be the new stack
> vma.
>
> Following the history of it is a big of a mess, because there's a
> number of renamings and re-organizations, but it seems to go back to
> 2007 and commit b6a2fea39318 ("mm: variable length argument support").
>
Right.
> Before that commit, we kept our own array of "this is the set of pages
> that I will install in the new VM". That commit basically just inserts
> the pages directly into the VM instead, getting rid of the array size
> limitation.
>
> So at a minimum, I think that FOLL_FORCE would need to be removed
> before any renaming to FOLL_PTRACE, because that's not some kind of
> small random case.
>
> It *might* be as simple as just removing it, but maybe there's some
> reason for having it that I don't immediately see.
Right, I have the same feeling. It might just be a copy-and-paste legacy
leftover.
>
> There _are_ also small random cases too, like get_cmdline(). Maybe
> that counts as ptrace, but the execve() case most definitely does not.
I agree. I'd suggest moving forward without this (last) patch for now
and figuring out how to further cleanup FOLL_FORCE usage on top.
@Andrew, if you intend to put this into mm-unstable, please drop the
last patch for now.
--
Thanks,
David / dhildenb
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
^ permalink raw reply
* Re: [PATCH mm-unstable v1 20/20] mm: rename FOLL_FORCE to FOLL_PTRACE
From: Linus Torvalds @ 2022-11-16 18:16 UTC (permalink / raw)
To: David Hildenbrand
Cc: linux-kernel, x86, linux-alpha, linux-arm-kernel, linux-ia64,
linux-mips, linuxppc-dev, sparclinux, linux-um, etnaviv,
dri-devel, linux-samsung-soc, linux-rdma, linux-media,
linux-fsdevel, linux-mm, linux-perf-users, linux-security-module,
linux-kselftest, Andrew Morton, Jason Gunthorpe, John Hubbard,
Peter Xu, Greg Kroah-Hartman, Andrea Arcangeli, Hugh Dickins,
Nadav Amit, Vlastimil Babka, Matthew Wilcox, Mike Kravetz,
Muchun Song, Shuah Khan, Lucas Stach, David Airlie, Oded Gabbay,
Arnd Bergmann, Christoph Hellwig, Alex Williamson, Oleg Nesterov,
Richard Henderson, Ivan Kokshaysky, Matt Turner, Catalin Marinas,
Will Deacon, Thomas Bogendoerfer, Michael Ellerman,
Nicholas Piggin, Christophe Leroy, David S. Miller,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Richard Weinberger, Anton Ivanov, Johannes Berg,
Eric Biederman, Kees Cook, Alexander Viro, Peter Zijlstra,
Arnaldo Carvalho de Melo, Mark Rutland, Alexander Shishkin,
Jiri Olsa, Namhyung Kim, Kentaro Takeda, Tetsuo Handa, Paul Moore,
James Morris, Serge E. Hallyn
In-Reply-To: <20221116102659.70287-21-david@redhat.com>
On Wed, Nov 16, 2022 at 2:30 AM David Hildenbrand <david@redhat.com> wrote:
>
> Let's make it clearer that functionality provided by FOLL_FORCE is
> really only for ptrace access.
I'm not super-happy about this one.
I do understand the "let's rename the bit so that no new user shows up".
And it's true that the main traditional use is ptrace.
But from the patch itself it becomes obvious that no, it's not *just*
ptrace. At least not yet.
It's used for get_arg_page(), which uses it to basically look up (and
install) pages in the newly created VM.
Now, I'm not entirely sure why it even uses FOLL_FORCE, - I think it
might be historical, because the target should always be the new stack
vma.
Following the history of it is a big of a mess, because there's a
number of renamings and re-organizations, but it seems to go back to
2007 and commit b6a2fea39318 ("mm: variable length argument support").
Before that commit, we kept our own array of "this is the set of pages
that I will install in the new VM". That commit basically just inserts
the pages directly into the VM instead, getting rid of the array size
limitation.
So at a minimum, I think that FOLL_FORCE would need to be removed
before any renaming to FOLL_PTRACE, because that's not some kind of
small random case.
It *might* be as simple as just removing it, but maybe there's some
reason for having it that I don't immediately see.
There _are_ also small random cases too, like get_cmdline(). Maybe
that counts as ptrace, but the execve() case most definitely does not.
Linus
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
^ permalink raw reply
* [PATCH printk v5 07/40] um: kmsg_dump: only dump when no output console available
From: John Ogness @ 2022-11-16 16:21 UTC (permalink / raw)
To: Petr Mladek
Cc: Sergey Senozhatsky, Steven Rostedt, Thomas Gleixner, linux-kernel,
Richard Weinberger, Anton Ivanov, Johannes Berg, linux-um
In-Reply-To: <20221116162152.193147-1-john.ogness@linutronix.de>
The initial intention of the UML kmsg_dumper is to dump the kernel
buffers to stdout if there is no console available to perform the
regular crash output.
However, if ttynull was registered as a console, no crash output was
seen. Commit e23fe90dec28 ("um: kmsg_dumper: always dump when not tty
console") tried to fix this by performing the kmsg_dump unless the
stdio console was behind /dev/console or enabled. But this allowed
kmsg dumping to occur even if other non-stdio consoles will output
the crash output. Also, a console being the driver behind
/dev/console has nothing to do with a crash scenario.
Restore the initial intention by dumping the kernel buffers to stdout
only if a non-ttynull console is registered and enabled. Also add
detailed comments so that it is clear why these rules are applied.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Reviewed-by: Petr Mladek <pmladek@suse.com>
---
arch/um/kernel/kmsg_dump.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/um/kernel/kmsg_dump.c b/arch/um/kernel/kmsg_dump.c
index 0224fcb36e22..40abf1e9ccb1 100644
--- a/arch/um/kernel/kmsg_dump.c
+++ b/arch/um/kernel/kmsg_dump.c
@@ -17,13 +17,22 @@ static void kmsg_dumper_stdout(struct kmsg_dumper *dumper,
unsigned long flags;
size_t len = 0;
- /* only dump kmsg when no console is available */
+ /*
+ * If no consoles are available to output crash information, dump
+ * the kmsg buffer to stdout.
+ */
+
if (!console_trylock())
return;
for_each_console(con) {
- if(strcmp(con->name, "tty") == 0 &&
- (con->flags & (CON_ENABLED | CON_CONSDEV)) != 0) {
+ /*
+ * The ttynull console and disabled consoles are ignored
+ * since they cannot output. All other consoles are
+ * expected to output the crash information.
+ */
+ if (strcmp(con->name, "ttynull") != 0 &&
+ (con->flags & CON_ENABLED)) {
break;
}
}
--
2.30.2
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
^ permalink raw reply related
* [PATCH printk v5 00/40] reduce console_lock scope
From: John Ogness @ 2022-11-16 16:21 UTC (permalink / raw)
To: Petr Mladek
Cc: Sergey Senozhatsky, Steven Rostedt, Thomas Gleixner, linux-kernel,
Jason Wessel, Daniel Thompson, Douglas Anderson,
Greg Kroah-Hartman, Jiri Slaby, kgdb-bugreport, linux-serial,
linux-fsdevel, Miguel Ojeda, Richard Weinberger, Anton Ivanov,
Johannes Berg, linux-um, Aaron Tomlin, Luis Chamberlain,
Andy Shevchenko, Ilpo Järvinen, Lukas Wunner,
Geert Uytterhoeven, Geert Uytterhoeven, linux-m68k,
Ard Biesheuvel, linux-efi, linuxppc-dev, Krzysztof Kozlowski,
Alim Akhtar, linux-arm-kernel, linux-samsung-soc, Michal Simek,
Peter Zijlstra, Mathias Nyman, linux-usb, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, netdev, Helge Deller,
Thomas Zimmermann, Javier Martinez Canillas, Juergen Gross,
Boris Ostrovsky, Tom Rix, linux-fbdev, dri-devel
This is v5 of a series to prepare for threaded/atomic
printing. v4 is here [0]. This series focuses on reducing the
scope of the BKL console_lock. It achieves this by switching to
SRCU and a dedicated mutex for console list iteration and
modification, respectively. The console_lock will no longer
offer this protection.
Also, during the review of v2 it came to our attention that
many console drivers are checking CON_ENABLED to see if they
are registered. Because this flag can change without
unregistering and because this flag does not represent an
atomic point when an (un)registration process is complete,
a new console_is_registered() function is introduced. This
function uses the console_list_lock to synchronize with the
(un)registration process to provide a reliable status.
All users of the console_lock for list iteration have been
modified. For the call sites where the console_lock is still
needed (for other reasons), comments are added to explain
exactly why the console_lock is needed.
All users of CON_ENABLED for registration status have been
modified to use console_is_registered(). Note that there are
still users of CON_ENABLED, but this is for legitimate purposes
about a registered console being able to print.
The base commit for this series is from Paul McKenney's RCU tree
and provides an NMI-safe SRCU implementation [1]. Without the
NMI-safe SRCU implementation, this series is not less safe than
mainline. But we will need the NMI-safe SRCU implementation for
atomic consoles anyway, so we might as well get it in
now. Especially since it _does_ increase the reliability for
mainline in the panic path.
Changes since v4:
printk:
- Introduce console_init_seq() to handle the now rather complex
procedure to find an appropriate start sequence number for a
new console upon registration.
- When registering a non-boot console and boot consoles are
registered, try to flush all the consoles to get the next @seq
value before falling back to use the @seq of the enabled boot
console that is furthest behind.
- For console_force_preferred_locked(), make the console the
head of the console list.
John Ogness
[0] https://lore.kernel.org/lkml/20221114162932.141883-1-john.ogness@linutronix.de
[1] https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git/log/?h=srcunmisafe.2022.11.09a
John Ogness (38):
printk: Prepare for SRCU console list protection
printk: register_console: use "registered" for variable names
printk: move @seq initialization to helper
printk: fix setting first seq for consoles
um: kmsg_dump: only dump when no output console available
tty: serial: kgdboc: document console_lock usage
tty: tty_io: document console_lock usage
proc: consoles: document console_lock usage
printk: introduce console_list_lock
console: introduce wrappers to read/write console flags
um: kmsg_dumper: use srcu console list iterator
kdb: use srcu console list iterator
printk: console_flush_all: use srcu console list iterator
printk: __pr_flush: use srcu console list iterator
printk: console_is_usable: use console_srcu_read_flags
printk: console_unblank: use srcu console list iterator
printk: console_flush_on_panic: use srcu console list iterator
printk: console_device: use srcu console list iterator
console: introduce console_is_registered()
serial_core: replace uart_console_enabled() with
uart_console_registered()
tty: nfcon: use console_is_registered()
efi: earlycon: use console_is_registered()
tty: hvc: use console_is_registered()
tty: serial: earlycon: use console_is_registered()
tty: serial: pic32_uart: use console_is_registered()
tty: serial: samsung_tty: use console_is_registered()
tty: serial: xilinx_uartps: use console_is_registered()
usb: early: xhci-dbc: use console_is_registered()
netconsole: avoid CON_ENABLED misuse to track registration
printk, xen: fbfront: create/use safe function for forcing preferred
tty: tty_io: use console_list_lock for list synchronization
proc: consoles: use console_list_lock for list iteration
tty: serial: kgdboc: use srcu console list iterator
tty: serial: kgdboc: use console_list_lock for list traversal
tty: serial: kgdboc: synchronize tty_find_polling_driver() and
register_console()
tty: serial: kgdboc: use console_list_lock to trap exit
printk: relieve console_lock of list synchronization duties
tty: serial: sh-sci: use setup() callback for early console
Thomas Gleixner (2):
serial: kgdboc: Lock console list in probe function
printk: Convert console_drivers list to hlist
.clang-format | 1 +
arch/m68k/emu/nfcon.c | 9 +-
arch/um/kernel/kmsg_dump.c | 24 +-
drivers/firmware/efi/earlycon.c | 8 +-
drivers/net/netconsole.c | 21 +-
drivers/tty/hvc/hvc_console.c | 4 +-
drivers/tty/serial/8250/8250_core.c | 2 +-
drivers/tty/serial/earlycon.c | 4 +-
drivers/tty/serial/kgdboc.c | 46 ++-
drivers/tty/serial/pic32_uart.c | 4 +-
drivers/tty/serial/samsung_tty.c | 2 +-
drivers/tty/serial/serial_core.c | 14 +-
drivers/tty/serial/sh-sci.c | 20 +-
drivers/tty/serial/xilinx_uartps.c | 2 +-
drivers/tty/tty_io.c | 18 +-
drivers/usb/early/xhci-dbc.c | 2 +-
drivers/video/fbdev/xen-fbfront.c | 12 +-
fs/proc/consoles.c | 21 +-
include/linux/console.h | 129 +++++++-
include/linux/serial_core.h | 10 +-
kernel/debug/kdb/kdb_io.c | 18 +-
kernel/printk/printk.c | 493 +++++++++++++++++++++-------
22 files changed, 680 insertions(+), 184 deletions(-)
base-commit: f733615e39aa2d6ddeef33b7b2c9aa6a5a2c2785
--
2.30.2
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
^ permalink raw reply
* Re: [PATCH -next] um: vector: Fix memory leak in vector_config
From: Anton Ivanov @ 2022-11-16 16:09 UTC (permalink / raw)
To: Xiang Yang, patchwork, kuba, richard, johannes; +Cc: linux-um, linux-kernel
In-Reply-To: <20221115073225.161592-1-xiangyang3@huawei.com>
On 15/11/2022 07:32, Xiang Yang wrote:
> If the return value of the uml_parse_vector_ifspec function is NULL,
> we should call kfree(params) to prevent memory leak.
>
> Fixes: 49da7e64f33e ("High Performance UML Vector Network Driver")
> Signed-off-by: Xiang Yang <xiangyang3@huawei.com>
> ---
> arch/um/drivers/vector_kern.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/um/drivers/vector_kern.c b/arch/um/drivers/vector_kern.c
> index ded7c47d2fbe..131b7cb29576 100644
> --- a/arch/um/drivers/vector_kern.c
> +++ b/arch/um/drivers/vector_kern.c
> @@ -767,6 +767,7 @@ static int vector_config(char *str, char **error_out)
>
> if (parsed == NULL) {
> *error_out = "vector_config failed to parse parameters";
> + kfree(params);
> return -EINVAL;
> }
>
Acked-By: Anton Ivanov <anton.ivanov@kot-begemot.co.uk>
--
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
^ permalink raw reply
* [PATCH printk v5 13/40] um: kmsg_dumper: use srcu console list iterator
From: John Ogness @ 2022-11-16 16:21 UTC (permalink / raw)
To: Petr Mladek
Cc: Sergey Senozhatsky, Steven Rostedt, Thomas Gleixner, linux-kernel,
Richard Weinberger, Anton Ivanov, Johannes Berg, linux-um
In-Reply-To: <20221116162152.193147-1-john.ogness@linutronix.de>
Rather than using the console_lock to guarantee safe console list
traversal, use srcu console list iteration.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Reviewed-by: Petr Mladek <pmladek@suse.com>
---
arch/um/kernel/kmsg_dump.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/arch/um/kernel/kmsg_dump.c b/arch/um/kernel/kmsg_dump.c
index 40abf1e9ccb1..427dd5a61a38 100644
--- a/arch/um/kernel/kmsg_dump.c
+++ b/arch/um/kernel/kmsg_dump.c
@@ -16,29 +16,26 @@ static void kmsg_dumper_stdout(struct kmsg_dumper *dumper,
struct console *con;
unsigned long flags;
size_t len = 0;
+ int cookie;
/*
* If no consoles are available to output crash information, dump
* the kmsg buffer to stdout.
*/
- if (!console_trylock())
- return;
-
- for_each_console(con) {
+ cookie = console_srcu_read_lock();
+ for_each_console_srcu(con) {
/*
* The ttynull console and disabled consoles are ignored
* since they cannot output. All other consoles are
* expected to output the crash information.
*/
if (strcmp(con->name, "ttynull") != 0 &&
- (con->flags & CON_ENABLED)) {
+ (console_srcu_read_flags(con) & CON_ENABLED)) {
break;
}
}
-
- console_unlock();
-
+ console_srcu_read_unlock(cookie);
if (con)
return;
--
2.30.2
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
^ permalink raw reply related
* Re: [PATCH mm-unstable v1 17/20] drm/exynos: remove FOLL_FORCE usage
From: Daniel Vetter @ 2022-11-16 10:50 UTC (permalink / raw)
To: David Hildenbrand
Cc: linux-kernel, x86, linux-alpha, linux-arm-kernel, linux-ia64,
linux-mips, linuxppc-dev, sparclinux, linux-um, etnaviv,
dri-devel, linux-samsung-soc, linux-rdma, linux-media,
linux-fsdevel, linux-mm, linux-perf-users, linux-security-module,
linux-kselftest, Linus Torvalds, Andrew Morton, Jason Gunthorpe,
John Hubbard, Peter Xu, Greg Kroah-Hartman, Andrea Arcangeli,
Hugh Dickins, Nadav Amit, Vlastimil Babka, Matthew Wilcox,
Mike Kravetz, Muchun Song, Shuah Khan, Lucas Stach, David Airlie,
Oded Gabbay, Arnd Bergmann, Christoph Hellwig, Alex Williamson,
Inki Dae, Seung-Woo Kim, Kyungmin Park, Daniel Vetter,
Krzysztof Kozlowski
In-Reply-To: <20221116102659.70287-18-david@redhat.com>
On Wed, Nov 16, 2022 at 11:26:56AM +0100, David Hildenbrand wrote:
> FOLL_FORCE is really only for ptrace access. As we unpin the pinned pages
> using unpin_user_pages_dirty_lock(true), the assumption is that all these
> pages are writable.
>
> FOLL_FORCE in this case seems to be a legacy leftover. Let's just remove
> it.
>
> Cc: Inki Dae <inki.dae@samsung.com>
> Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: David Airlie <airlied@gmail.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Plus ack for merging through the appropriate non-drm tree.
-Daniel
> ---
> drivers/gpu/drm/exynos/exynos_drm_g2d.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> index 471fd6c8135f..e19c2ceb3759 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> @@ -477,7 +477,7 @@ static dma_addr_t *g2d_userptr_get_dma_addr(struct g2d_data *g2d,
> }
>
> ret = pin_user_pages_fast(start, npages,
> - FOLL_FORCE | FOLL_WRITE | FOLL_LONGTERM,
> + FOLL_WRITE | FOLL_LONGTERM,
> g2d_userptr->pages);
> if (ret != npages) {
> DRM_DEV_ERROR(g2d->dev,
> --
> 2.38.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
^ permalink raw reply
* Re: [PATCH mm-unstable v1 16/20] mm/frame-vector: remove FOLL_FORCE usage
From: Daniel Vetter @ 2022-11-16 10:50 UTC (permalink / raw)
To: David Hildenbrand
Cc: linux-kernel, linux-ia64, Greg Kroah-Hartman, dri-devel,
Hans Verkuil, linux-mm, Nadav Amit, linux-kselftest, sparclinux,
Shuah Khan, Marek Szyprowski, Andrea Arcangeli, linux-samsung-soc,
linux-rdma, x86, Hugh Dickins, Matthew Wilcox, Christoph Hellwig,
Jason Gunthorpe, Vlastimil Babka, linux-media, Arnd Bergmann,
John Hubbard, linux-um, etnaviv, Alex Williamson, Peter Xu,
Muchun Song, Mauro Carvalho Chehab, linux-arm-kernel,
linuxppc-dev, Oded Gabbay, linux-mips, Tomasz Figa,
linux-perf-users, linux-security-module, linux-alpha,
linux-fsdevel, Andrew Morton, Linus Torvalds, Mike Kravetz
In-Reply-To: <20221116102659.70287-17-david@redhat.com>
On Wed, Nov 16, 2022 at 11:26:55AM +0100, David Hildenbrand wrote:
> FOLL_FORCE is really only for ptrace access. According to commit
> 707947247e95 ("media: videobuf2-vmalloc: get_userptr: buffers are always
> writable"), get_vaddr_frames() currently pins all pages writable as a
> workaround for issues with read-only buffers.
>
> FOLL_FORCE, however, seems to be a legacy leftover as it predates
> commit 707947247e95 ("media: videobuf2-vmalloc: get_userptr: buffers are
> always writable"). Let's just remove it.
>
> Once the read-only buffer issue has been resolved, FOLL_WRITE could
> again be set depending on the DMA direction.
>
> Cc: Hans Verkuil <hverkuil@xs4all.nl>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> Cc: Tomasz Figa <tfiga@chromium.org>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
> Signed-off-by: David Hildenbrand <david@redhat.com>
Also code I looked at while looking at follow_pfn stuff
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
> drivers/media/common/videobuf2/frame_vector.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/common/videobuf2/frame_vector.c b/drivers/media/common/videobuf2/frame_vector.c
> index 542dde9d2609..062e98148c53 100644
> --- a/drivers/media/common/videobuf2/frame_vector.c
> +++ b/drivers/media/common/videobuf2/frame_vector.c
> @@ -50,7 +50,7 @@ int get_vaddr_frames(unsigned long start, unsigned int nr_frames,
> start = untagged_addr(start);
>
> ret = pin_user_pages_fast(start, nr_frames,
> - FOLL_FORCE | FOLL_WRITE | FOLL_LONGTERM,
> + FOLL_WRITE | FOLL_LONGTERM,
> (struct page **)(vec->ptrs));
> if (ret > 0) {
> vec->got_ref = true;
> --
> 2.38.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
^ permalink raw reply
* Re: [PATCH mm-unstable v1 14/20] drm/etnaviv: remove FOLL_FORCE usage
From: Daniel Vetter @ 2022-11-16 10:49 UTC (permalink / raw)
To: David Hildenbrand
Cc: linux-kernel, x86, linux-alpha, linux-arm-kernel, linux-ia64,
linux-mips, linuxppc-dev, sparclinux, linux-um, etnaviv,
dri-devel, linux-samsung-soc, linux-rdma, linux-media,
linux-fsdevel, linux-mm, linux-perf-users, linux-security-module,
linux-kselftest, Linus Torvalds, Andrew Morton, Jason Gunthorpe,
John Hubbard, Peter Xu, Greg Kroah-Hartman, Andrea Arcangeli,
Hugh Dickins, Nadav Amit, Vlastimil Babka, Matthew Wilcox,
Mike Kravetz, Muchun Song, Shuah Khan, Lucas Stach, David Airlie,
Oded Gabbay, Arnd Bergmann, Christoph Hellwig, Alex Williamson,
Daniel Vetter, Russell King, Christian Gmeiner
In-Reply-To: <20221116102659.70287-15-david@redhat.com>
On Wed, Nov 16, 2022 at 11:26:53AM +0100, David Hildenbrand wrote:
> GUP now supports reliable R/O long-term pinning in COW mappings, such
> that we break COW early. MAP_SHARED VMAs only use the shared zeropage so
> far in one corner case (DAXFS file with holes), which can be ignored
> because GUP does not support long-term pinning in fsdax (see
> check_vma_flags()).
>
> commit cd5297b0855f ("drm/etnaviv: Use FOLL_FORCE for userptr")
> documents that FOLL_FORCE | FOLL_WRITE was really only used for reliable
> R/O pinning.
>
> Consequently, FOLL_FORCE | FOLL_WRITE | FOLL_LONGTERM is no longer required
> for reliable R/O long-term pinning: FOLL_LONGTERM is sufficient. So stop
> using FOLL_FORCE, which is really only for ptrace access.
>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Cc: Russell King <linux+etnaviv@armlinux.org.uk>
> Cc: Christian Gmeiner <christian.gmeiner@gmail.com>
> Cc: David Airlie <airlied@gmail.com>
> Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Also ack for merging through whatever tree suits best, since I guess this
should all land together.
-Daniel
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gem.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> index cc386f8a7116..efe2240945d0 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> @@ -638,6 +638,7 @@ static int etnaviv_gem_userptr_get_pages(struct etnaviv_gem_object *etnaviv_obj)
> struct page **pvec = NULL;
> struct etnaviv_gem_userptr *userptr = &etnaviv_obj->userptr;
> int ret, pinned = 0, npages = etnaviv_obj->base.size >> PAGE_SHIFT;
> + unsigned int gup_flags = FOLL_LONGTERM;
>
> might_lock_read(¤t->mm->mmap_lock);
>
> @@ -648,14 +649,15 @@ static int etnaviv_gem_userptr_get_pages(struct etnaviv_gem_object *etnaviv_obj)
> if (!pvec)
> return -ENOMEM;
>
> + if (!userptr->ro)
> + gup_flags |= FOLL_WRITE;
> +
> do {
> unsigned num_pages = npages - pinned;
> uint64_t ptr = userptr->ptr + pinned * PAGE_SIZE;
> struct page **pages = pvec + pinned;
>
> - ret = pin_user_pages_fast(ptr, num_pages,
> - FOLL_WRITE | FOLL_FORCE | FOLL_LONGTERM,
> - pages);
> + ret = pin_user_pages_fast(ptr, num_pages, gup_flags, pages);
> if (ret < 0) {
> unpin_user_pages(pvec, pinned);
> kvfree(pvec);
> --
> 2.38.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
^ permalink raw reply
* Re: [PATCH mm-unstable v1 13/20] media: videobuf-dma-sg: remove FOLL_FORCE usage
From: Daniel Vetter @ 2022-11-16 10:48 UTC (permalink / raw)
To: David Hildenbrand
Cc: linux-kernel, linux-ia64, Greg Kroah-Hartman, dri-devel, linux-mm,
Nadav Amit, linux-kselftest, sparclinux, Shuah Khan,
Andrea Arcangeli, linux-samsung-soc, linux-rdma, x86,
Hugh Dickins, Matthew Wilcox, Christoph Hellwig, Jason Gunthorpe,
Vlastimil Babka, linux-media, Arnd Bergmann, John Hubbard,
linux-um, etnaviv, Alex Williamson, Peter Xu, Muchun Song,
Mauro Carvalho Chehab, linux-arm-kernel, linuxppc-dev,
Oded Gabbay, linux-mips, linux-perf-users, linux-security-module,
linux-alpha, linux-fsdevel, Andrew Morton, Linus Torvalds,
Mike Kravetz
In-Reply-To: <20221116102659.70287-14-david@redhat.com>
On Wed, Nov 16, 2022 at 11:26:52AM +0100, David Hildenbrand wrote:
> GUP now supports reliable R/O long-term pinning in COW mappings, such
> that we break COW early. MAP_SHARED VMAs only use the shared zeropage so
> far in one corner case (DAXFS file with holes), which can be ignored
> because GUP does not support long-term pinning in fsdax (see
> check_vma_flags()).
>
> Consequently, FOLL_FORCE | FOLL_WRITE | FOLL_LONGTERM is no longer required
> for reliable R/O long-term pinning: FOLL_LONGTERM is sufficient. So stop
> using FOLL_FORCE, which is really only for ptrace access.
>
> Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
> Signed-off-by: David Hildenbrand <david@redhat.com>
I looked at this a while ago when going through some of the follow_pfn
stuff, so
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
> drivers/media/v4l2-core/videobuf-dma-sg.c | 14 +++++---------
> 1 file changed, 5 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/videobuf-dma-sg.c b/drivers/media/v4l2-core/videobuf-dma-sg.c
> index f75e5eedeee0..234e9f647c96 100644
> --- a/drivers/media/v4l2-core/videobuf-dma-sg.c
> +++ b/drivers/media/v4l2-core/videobuf-dma-sg.c
> @@ -151,17 +151,16 @@ static void videobuf_dma_init(struct videobuf_dmabuf *dma)
> static int videobuf_dma_init_user_locked(struct videobuf_dmabuf *dma,
> int direction, unsigned long data, unsigned long size)
> {
> + unsigned int gup_flags = FOLL_LONGTERM;
> unsigned long first, last;
> - int err, rw = 0;
> - unsigned int flags = FOLL_FORCE;
> + int err;
>
> dma->direction = direction;
> switch (dma->direction) {
> case DMA_FROM_DEVICE:
> - rw = READ;
> + gup_flags |= FOLL_WRITE;
> break;
> case DMA_TO_DEVICE:
> - rw = WRITE;
> break;
> default:
> BUG();
> @@ -177,14 +176,11 @@ static int videobuf_dma_init_user_locked(struct videobuf_dmabuf *dma,
> if (NULL == dma->pages)
> return -ENOMEM;
>
> - if (rw == READ)
> - flags |= FOLL_WRITE;
> -
> dprintk(1, "init user [0x%lx+0x%lx => %lu pages]\n",
> data, size, dma->nr_pages);
>
> - err = pin_user_pages(data & PAGE_MASK, dma->nr_pages,
> - flags | FOLL_LONGTERM, dma->pages, NULL);
> + err = pin_user_pages(data & PAGE_MASK, dma->nr_pages, gup_flags,
> + dma->pages, NULL);
>
> if (err != dma->nr_pages) {
> dma->nr_pages = (err >= 0) ? err : 0;
> --
> 2.38.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
^ permalink raw reply
* Re: [PATCH mm-unstable v1 09/20] mm/gup: reliable R/O long-term pinning in COW mappings
From: Daniel Vetter @ 2022-11-16 10:42 UTC (permalink / raw)
To: David Hildenbrand
Cc: linux-kernel, linux-ia64, Greg Kroah-Hartman, dri-devel, linux-mm,
Nadav Amit, linux-kselftest, sparclinux, Shuah Khan,
Andrea Arcangeli, linux-samsung-soc, linux-rdma, x86,
Hugh Dickins, Matthew Wilcox, Christoph Hellwig, Jason Gunthorpe,
Vlastimil Babka, linux-media, Arnd Bergmann, John Hubbard,
linux-um, etnaviv, Alex Williamson, Peter Xu, Muchun Song,
linux-arm-kernel, linuxppc-dev, Oded Gabbay, linux-mips,
linux-perf-users, linux-security-module, linux-alpha,
linux-fsdevel, Andrew Morton, Linus Torvalds, Mike Kravetz
In-Reply-To: <20221116102659.70287-10-david@redhat.com>
On Wed, Nov 16, 2022 at 11:26:48AM +0100, David Hildenbrand wrote:
> We already support reliable R/O pinning of anonymous memory. However,
> assume we end up pinning (R/O long-term) a pagecache page or the shared
> zeropage inside a writable private ("COW") mapping. The next write access
> will trigger a write-fault and replace the pinned page by an exclusive
> anonymous page in the process page tables to break COW: the pinned page no
> longer corresponds to the page mapped into the process' page table.
>
> Now that FAULT_FLAG_UNSHARE can break COW on anything mapped into a
> COW mapping, let's properly break COW first before R/O long-term
> pinning something that's not an exclusive anon page inside a COW
> mapping. FAULT_FLAG_UNSHARE will break COW and map an exclusive anon page
> instead that can get pinned safely.
>
> With this change, we can stop using FOLL_FORCE|FOLL_WRITE for reliable
> R/O long-term pinning in COW mappings.
>
> With this change, the new R/O long-term pinning tests for non-anonymous
> memory succeed:
> # [RUN] R/O longterm GUP pin ... with shared zeropage
> ok 151 Longterm R/O pin is reliable
> # [RUN] R/O longterm GUP pin ... with memfd
> ok 152 Longterm R/O pin is reliable
> # [RUN] R/O longterm GUP pin ... with tmpfile
> ok 153 Longterm R/O pin is reliable
> # [RUN] R/O longterm GUP pin ... with huge zeropage
> ok 154 Longterm R/O pin is reliable
> # [RUN] R/O longterm GUP pin ... with memfd hugetlb (2048 kB)
> ok 155 Longterm R/O pin is reliable
> # [RUN] R/O longterm GUP pin ... with memfd hugetlb (1048576 kB)
> ok 156 Longterm R/O pin is reliable
> # [RUN] R/O longterm GUP-fast pin ... with shared zeropage
> ok 157 Longterm R/O pin is reliable
> # [RUN] R/O longterm GUP-fast pin ... with memfd
> ok 158 Longterm R/O pin is reliable
> # [RUN] R/O longterm GUP-fast pin ... with tmpfile
> ok 159 Longterm R/O pin is reliable
> # [RUN] R/O longterm GUP-fast pin ... with huge zeropage
> ok 160 Longterm R/O pin is reliable
> # [RUN] R/O longterm GUP-fast pin ... with memfd hugetlb (2048 kB)
> ok 161 Longterm R/O pin is reliable
> # [RUN] R/O longterm GUP-fast pin ... with memfd hugetlb (1048576 kB)
> ok 162 Longterm R/O pin is reliable
>
> Note 1: We don't care about short-term R/O-pinning, because they have
> snapshot semantics: they are not supposed to observe modifications that
> happen after pinning.
>
> As one example, assume we start direct I/O to read from a page and store
> page content into a file: modifications to page content after starting
> direct I/O are not guaranteed to end up in the file. So even if we'd pin
> the shared zeropage, the end result would be as expected -- getting zeroes
> stored to the file.
>
> Note 2: For shared mappings we'll now always fallback to the slow path to
> lookup the VMA when R/O long-term pining. While that's the necessary price
> we have to pay right now, it's actually not that bad in practice: most
> FOLL_LONGTERM users already specify FOLL_WRITE, for example, along with
> FOLL_FORCE because they tried dealing with COW mappings correctly ...
>
> Note 3: For users that use FOLL_LONGTERM right now without FOLL_WRITE,
> such as VFIO, we'd now no longer pin the shared zeropage. Instead, we'd
> populate exclusive anon pages that we can pin. There was a concern that
> this could affect the memlock limit of existing setups.
>
> For example, a VM running with VFIO could run into the memlock limit and
> fail to run. However, we essentially had the same behavior already in
> commit 17839856fd58 ("gup: document and work around "COW can break either
> way" issue") which got merged into some enterprise distros, and there were
> not any such complaints. So most probably, we're fine.
>
> Signed-off-by: David Hildenbrand <david@redhat.com>
I don't think my ack is any good for the implementation, but for the
driver side semantics this sounds like what we want :-)
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
> include/linux/mm.h | 27 ++++++++++++++++++++++++---
> mm/gup.c | 10 +++++-----
> mm/huge_memory.c | 2 +-
> mm/hugetlb.c | 7 ++++---
> 4 files changed, 34 insertions(+), 12 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 6bd2ee5872dd..e8cc838f42f9 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -3095,8 +3095,12 @@ static inline int vm_fault_to_errno(vm_fault_t vm_fault, int foll_flags)
> * Must be called with the (sub)page that's actually referenced via the
> * page table entry, which might not necessarily be the head page for a
> * PTE-mapped THP.
> + *
> + * If the vma is NULL, we're coming from the GUP-fast path and might have
> + * to fallback to the slow path just to lookup the vma.
> */
> -static inline bool gup_must_unshare(unsigned int flags, struct page *page)
> +static inline bool gup_must_unshare(struct vm_area_struct *vma,
> + unsigned int flags, struct page *page)
> {
> /*
> * FOLL_WRITE is implicitly handled correctly as the page table entry
> @@ -3109,8 +3113,25 @@ static inline bool gup_must_unshare(unsigned int flags, struct page *page)
> * Note: PageAnon(page) is stable until the page is actually getting
> * freed.
> */
> - if (!PageAnon(page))
> - return false;
> + if (!PageAnon(page)) {
> + /*
> + * We only care about R/O long-term pining: R/O short-term
> + * pinning does not have the semantics to observe successive
> + * changes through the process page tables.
> + */
> + if (!(flags & FOLL_LONGTERM))
> + return false;
> +
> + /* We really need the vma ... */
> + if (!vma)
> + return true;
> +
> + /*
> + * ... because we only care about writable private ("COW")
> + * mappings where we have to break COW early.
> + */
> + return is_cow_mapping(vma->vm_flags);
> + }
>
> /* Paired with a memory barrier in page_try_share_anon_rmap(). */
> if (IS_ENABLED(CONFIG_HAVE_FAST_GUP))
> diff --git a/mm/gup.c b/mm/gup.c
> index 5182abaaecde..01116699c863 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -578,7 +578,7 @@ static struct page *follow_page_pte(struct vm_area_struct *vma,
> }
> }
>
> - if (!pte_write(pte) && gup_must_unshare(flags, page)) {
> + if (!pte_write(pte) && gup_must_unshare(vma, flags, page)) {
> page = ERR_PTR(-EMLINK);
> goto out;
> }
> @@ -2338,7 +2338,7 @@ static int gup_pte_range(pmd_t pmd, pmd_t *pmdp, unsigned long addr,
> goto pte_unmap;
> }
>
> - if (!pte_write(pte) && gup_must_unshare(flags, page)) {
> + if (!pte_write(pte) && gup_must_unshare(NULL, flags, page)) {
> gup_put_folio(folio, 1, flags);
> goto pte_unmap;
> }
> @@ -2506,7 +2506,7 @@ static int gup_hugepte(pte_t *ptep, unsigned long sz, unsigned long addr,
> return 0;
> }
>
> - if (!pte_write(pte) && gup_must_unshare(flags, &folio->page)) {
> + if (!pte_write(pte) && gup_must_unshare(NULL, flags, &folio->page)) {
> gup_put_folio(folio, refs, flags);
> return 0;
> }
> @@ -2572,7 +2572,7 @@ static int gup_huge_pmd(pmd_t orig, pmd_t *pmdp, unsigned long addr,
> return 0;
> }
>
> - if (!pmd_write(orig) && gup_must_unshare(flags, &folio->page)) {
> + if (!pmd_write(orig) && gup_must_unshare(NULL, flags, &folio->page)) {
> gup_put_folio(folio, refs, flags);
> return 0;
> }
> @@ -2612,7 +2612,7 @@ static int gup_huge_pud(pud_t orig, pud_t *pudp, unsigned long addr,
> return 0;
> }
>
> - if (!pud_write(orig) && gup_must_unshare(flags, &folio->page)) {
> + if (!pud_write(orig) && gup_must_unshare(NULL, flags, &folio->page)) {
> gup_put_folio(folio, refs, flags);
> return 0;
> }
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 68d00196b519..dec7a7c0eca8 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -1434,7 +1434,7 @@ struct page *follow_trans_huge_pmd(struct vm_area_struct *vma,
> if (pmd_protnone(*pmd) && !gup_can_follow_protnone(flags))
> return NULL;
>
> - if (!pmd_write(*pmd) && gup_must_unshare(flags, page))
> + if (!pmd_write(*pmd) && gup_must_unshare(vma, flags, page))
> return ERR_PTR(-EMLINK);
>
> VM_BUG_ON_PAGE((flags & FOLL_PIN) && PageAnon(page) &&
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 383b26069b33..c3aab6d5b7aa 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -6195,7 +6195,8 @@ static void record_subpages_vmas(struct page *page, struct vm_area_struct *vma,
> }
> }
>
> -static inline bool __follow_hugetlb_must_fault(unsigned int flags, pte_t *pte,
> +static inline bool __follow_hugetlb_must_fault(struct vm_area_struct *vma,
> + unsigned int flags, pte_t *pte,
> bool *unshare)
> {
> pte_t pteval = huge_ptep_get(pte);
> @@ -6207,7 +6208,7 @@ static inline bool __follow_hugetlb_must_fault(unsigned int flags, pte_t *pte,
> return false;
> if (flags & FOLL_WRITE)
> return true;
> - if (gup_must_unshare(flags, pte_page(pteval))) {
> + if (gup_must_unshare(vma, flags, pte_page(pteval))) {
> *unshare = true;
> return true;
> }
> @@ -6336,7 +6337,7 @@ long follow_hugetlb_page(struct mm_struct *mm, struct vm_area_struct *vma,
> * directly from any kind of swap entries.
> */
> if (absent ||
> - __follow_hugetlb_must_fault(flags, pte, &unshare)) {
> + __follow_hugetlb_must_fault(vma, flags, pte, &unshare)) {
> vm_fault_t ret;
> unsigned int fault_flags = 0;
>
> --
> 2.38.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
^ permalink raw reply
* [PATCH mm-unstable v1 20/20] mm: rename FOLL_FORCE to FOLL_PTRACE
From: David Hildenbrand @ 2022-11-16 10:26 UTC (permalink / raw)
To: linux-kernel
Cc: x86, linux-alpha, linux-arm-kernel, linux-ia64, linux-mips,
linuxppc-dev, sparclinux, linux-um, etnaviv, dri-devel,
linux-samsung-soc, linux-rdma, linux-media, linux-fsdevel,
linux-mm, linux-perf-users, linux-security-module,
linux-kselftest, Linus Torvalds, Andrew Morton, Jason Gunthorpe,
John Hubbard, Peter Xu, Greg Kroah-Hartman, Andrea Arcangeli,
Hugh Dickins, Nadav Amit, Vlastimil Babka, Matthew Wilcox,
Mike Kravetz, Muchun Song, Shuah Khan, Lucas Stach, David Airlie,
Oded Gabbay, Arnd Bergmann, Christoph Hellwig, Alex Williamson,
David Hildenbrand, Oleg Nesterov, Richard Henderson,
Ivan Kokshaysky, Matt Turner, Catalin Marinas, Will Deacon,
Thomas Bogendoerfer, Michael Ellerman, Nicholas Piggin,
Christophe Leroy, David S. Miller, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Richard Weinberger,
Anton Ivanov, Johannes Berg, Eric Biederman, Kees Cook,
Alexander Viro, Peter Zijlstra, Arnaldo Carvalho de Melo,
Mark Rutland, Alexander Shishkin, Jiri Olsa, Namhyung Kim,
Kentaro Takeda, Tetsuo Handa, Paul Moore, James Morris,
Serge E. Hallyn
In-Reply-To: <20221116102659.70287-1-david@redhat.com>
Let's make it clearer that functionality provided by FOLL_FORCE is
really only for ptrace access. Prevent accidental re-use in drivers
by renaming FOLL_FORCE to FOLL_PTRACE:
git grep -l 'FOLL_FORCE' | xargs sed -i 's/FOLL_FORCE/FOLL_PTRACE/g'
In the future, we might want to use a separate set of flags for the
access_vm interface: most FOLL_* flags don't apply and we mostly only
want to pass FOLL_PTRACE and FOLL_WRITE.
Suggested-by: Christoph Hellwig <hch@infradead.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Richard Henderson <richard.henderson@linaro.org>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Matt Turner <mattst88@gmail.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Kentaro Takeda <takedakn@nttdata.co.jp>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Paul Moore <paul@paul-moore.com>
Cc: James Morris <jmorris@namei.org>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
---
arch/alpha/kernel/ptrace.c | 6 +++---
arch/arm64/kernel/mte.c | 2 +-
arch/ia64/kernel/ptrace.c | 10 +++++-----
arch/mips/kernel/ptrace32.c | 4 ++--
arch/mips/math-emu/dsemul.c | 2 +-
arch/powerpc/kernel/ptrace/ptrace32.c | 4 ++--
arch/sparc/kernel/ptrace_32.c | 4 ++--
arch/sparc/kernel/ptrace_64.c | 8 ++++----
arch/x86/kernel/step.c | 2 +-
arch/x86/um/ptrace_32.c | 2 +-
arch/x86/um/ptrace_64.c | 2 +-
fs/exec.c | 2 +-
fs/proc/base.c | 2 +-
include/linux/mm.h | 8 ++++----
kernel/events/uprobes.c | 4 ++--
kernel/ptrace.c | 12 ++++++------
mm/gup.c | 28 +++++++++++++--------------
mm/huge_memory.c | 8 ++++----
mm/hugetlb.c | 2 +-
mm/memory.c | 4 ++--
mm/util.c | 4 ++--
security/tomoyo/domain.c | 2 +-
22 files changed, 61 insertions(+), 61 deletions(-)
diff --git a/arch/alpha/kernel/ptrace.c b/arch/alpha/kernel/ptrace.c
index a1a239ea002d..55def6479ff2 100644
--- a/arch/alpha/kernel/ptrace.c
+++ b/arch/alpha/kernel/ptrace.c
@@ -158,7 +158,7 @@ static inline int
read_int(struct task_struct *task, unsigned long addr, int * data)
{
int copied = access_process_vm(task, addr, data, sizeof(int),
- FOLL_FORCE);
+ FOLL_PTRACE);
return (copied == sizeof(int)) ? 0 : -EIO;
}
@@ -166,7 +166,7 @@ static inline int
write_int(struct task_struct *task, unsigned long addr, int data)
{
int copied = access_process_vm(task, addr, &data, sizeof(int),
- FOLL_FORCE | FOLL_WRITE);
+ FOLL_PTRACE | FOLL_WRITE);
return (copied == sizeof(int)) ? 0 : -EIO;
}
@@ -284,7 +284,7 @@ long arch_ptrace(struct task_struct *child, long request,
case PTRACE_PEEKTEXT: /* read word at location addr. */
case PTRACE_PEEKDATA:
copied = ptrace_access_vm(child, addr, &tmp, sizeof(tmp),
- FOLL_FORCE);
+ FOLL_PTRACE);
ret = -EIO;
if (copied != sizeof(tmp))
break;
diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
index 7467217c1eaf..fa29fecaedbc 100644
--- a/arch/arm64/kernel/mte.c
+++ b/arch/arm64/kernel/mte.c
@@ -525,7 +525,7 @@ int mte_ptrace_copy_tags(struct task_struct *child, long request,
int ret;
struct iovec kiov;
struct iovec __user *uiov = (void __user *)data;
- unsigned int gup_flags = FOLL_FORCE;
+ unsigned int gup_flags = FOLL_PTRACE;
if (!system_supports_mte())
return -EIO;
diff --git a/arch/ia64/kernel/ptrace.c b/arch/ia64/kernel/ptrace.c
index ab8aeb34d1d9..3781db1f506c 100644
--- a/arch/ia64/kernel/ptrace.c
+++ b/arch/ia64/kernel/ptrace.c
@@ -452,7 +452,7 @@ ia64_peek (struct task_struct *child, struct switch_stack *child_stack,
return 0;
}
}
- copied = access_process_vm(child, addr, &ret, sizeof(ret), FOLL_FORCE);
+ copied = access_process_vm(child, addr, &ret, sizeof(ret), FOLL_PTRACE);
if (copied != sizeof(ret))
return -EIO;
*val = ret;
@@ -489,7 +489,7 @@ ia64_poke (struct task_struct *child, struct switch_stack *child_stack,
}
}
} else if (access_process_vm(child, addr, &val, sizeof(val),
- FOLL_FORCE | FOLL_WRITE)
+ FOLL_PTRACE | FOLL_WRITE)
!= sizeof(val))
return -EIO;
return 0;
@@ -544,7 +544,7 @@ ia64_sync_user_rbs (struct task_struct *child, struct switch_stack *sw,
if (ret < 0)
return ret;
if (access_process_vm(child, addr, &val, sizeof(val),
- FOLL_FORCE | FOLL_WRITE)
+ FOLL_PTRACE | FOLL_WRITE)
!= sizeof(val))
return -EIO;
}
@@ -561,7 +561,7 @@ ia64_sync_kernel_rbs (struct task_struct *child, struct switch_stack *sw,
/* now copy word for word from user rbs to kernel rbs: */
for (addr = user_rbs_start; addr < user_rbs_end; addr += 8) {
if (access_process_vm(child, addr, &val, sizeof(val),
- FOLL_FORCE)
+ FOLL_PTRACE)
!= sizeof(val))
return -EIO;
@@ -1105,7 +1105,7 @@ arch_ptrace (struct task_struct *child, long request,
case PTRACE_PEEKDATA:
/* read word at location addr */
if (ptrace_access_vm(child, addr, &data, sizeof(data),
- FOLL_FORCE)
+ FOLL_PTRACE)
!= sizeof(data))
return -EIO;
/* ensure return value is not mistaken for error code */
diff --git a/arch/mips/kernel/ptrace32.c b/arch/mips/kernel/ptrace32.c
index afcf27a877cb..31c1c805bb8e 100644
--- a/arch/mips/kernel/ptrace32.c
+++ b/arch/mips/kernel/ptrace32.c
@@ -71,7 +71,7 @@ long compat_arch_ptrace(struct task_struct *child, compat_long_t request,
break;
copied = ptrace_access_vm(child, (u64)addrOthers, &tmp,
- sizeof(tmp), FOLL_FORCE);
+ sizeof(tmp), FOLL_PTRACE);
if (copied != sizeof(tmp))
break;
ret = put_user(tmp, (u32 __user *) (unsigned long) data);
@@ -185,7 +185,7 @@ long compat_arch_ptrace(struct task_struct *child, compat_long_t request,
ret = 0;
if (ptrace_access_vm(child, (u64)addrOthers, &data,
sizeof(data),
- FOLL_FORCE | FOLL_WRITE) == sizeof(data))
+ FOLL_PTRACE | FOLL_WRITE) == sizeof(data))
break;
ret = -EIO;
break;
diff --git a/arch/mips/math-emu/dsemul.c b/arch/mips/math-emu/dsemul.c
index e02bd20b60a6..6111a46de2df 100644
--- a/arch/mips/math-emu/dsemul.c
+++ b/arch/mips/math-emu/dsemul.c
@@ -271,7 +271,7 @@ int mips_dsemul(struct pt_regs *regs, mips_instruction ir,
/* Write the frame to user memory */
fr_uaddr = (unsigned long)&dsemul_page()[fr_idx];
ret = access_process_vm(current, fr_uaddr, &fr, sizeof(fr),
- FOLL_FORCE | FOLL_WRITE);
+ FOLL_PTRACE | FOLL_WRITE);
if (unlikely(ret != sizeof(fr))) {
MIPS_FPU_EMU_INC_STATS(errors);
free_emuframe(fr_idx, current->mm);
diff --git a/arch/powerpc/kernel/ptrace/ptrace32.c b/arch/powerpc/kernel/ptrace/ptrace32.c
index 19c224808982..336cfebd70df 100644
--- a/arch/powerpc/kernel/ptrace/ptrace32.c
+++ b/arch/powerpc/kernel/ptrace/ptrace32.c
@@ -65,7 +65,7 @@ long compat_arch_ptrace(struct task_struct *child, compat_long_t request,
break;
copied = ptrace_access_vm(child, (u64)addrOthers, &tmp,
- sizeof(tmp), FOLL_FORCE);
+ sizeof(tmp), FOLL_PTRACE);
if (copied != sizeof(tmp))
break;
ret = put_user(tmp, (u32 __user *)data);
@@ -169,7 +169,7 @@ long compat_arch_ptrace(struct task_struct *child, compat_long_t request,
ret = 0;
if (ptrace_access_vm(child, (u64)addrOthers, &tmp,
sizeof(tmp),
- FOLL_FORCE | FOLL_WRITE) == sizeof(tmp))
+ FOLL_PTRACE | FOLL_WRITE) == sizeof(tmp))
break;
ret = -EIO;
break;
diff --git a/arch/sparc/kernel/ptrace_32.c b/arch/sparc/kernel/ptrace_32.c
index e7db48acb838..b5c91855faee 100644
--- a/arch/sparc/kernel/ptrace_32.c
+++ b/arch/sparc/kernel/ptrace_32.c
@@ -56,7 +56,7 @@ static int regwindow32_get(struct task_struct *target,
return -EFAULT;
} else {
if (access_process_vm(target, reg_window, uregs, size,
- FOLL_FORCE) != size)
+ FOLL_PTRACE) != size)
return -EFAULT;
}
return 0;
@@ -74,7 +74,7 @@ static int regwindow32_set(struct task_struct *target,
return -EFAULT;
} else {
if (access_process_vm(target, reg_window, uregs, size,
- FOLL_FORCE | FOLL_WRITE) != size)
+ FOLL_PTRACE | FOLL_WRITE) != size)
return -EFAULT;
}
return 0;
diff --git a/arch/sparc/kernel/ptrace_64.c b/arch/sparc/kernel/ptrace_64.c
index 86a7eb5c27ba..4de97cd1e55a 100644
--- a/arch/sparc/kernel/ptrace_64.c
+++ b/arch/sparc/kernel/ptrace_64.c
@@ -165,7 +165,7 @@ static int get_from_target(struct task_struct *target, unsigned long uaddr,
return -EFAULT;
} else {
int len2 = access_process_vm(target, uaddr, kbuf, len,
- FOLL_FORCE);
+ FOLL_PTRACE);
if (len2 != len)
return -EFAULT;
}
@@ -180,7 +180,7 @@ static int set_to_target(struct task_struct *target, unsigned long uaddr,
return -EFAULT;
} else {
int len2 = access_process_vm(target, uaddr, kbuf, len,
- FOLL_FORCE | FOLL_WRITE);
+ FOLL_PTRACE | FOLL_WRITE);
if (len2 != len)
return -EFAULT;
}
@@ -592,7 +592,7 @@ static int genregs32_set(struct task_struct *target,
®_window[pos],
(void *) k,
sizeof(*k),
- FOLL_FORCE | FOLL_WRITE)
+ FOLL_PTRACE | FOLL_WRITE)
!= sizeof(*k))
return -EFAULT;
k++;
@@ -622,7 +622,7 @@ static int genregs32_set(struct task_struct *target,
(unsigned long)
®_window[pos],
®, sizeof(reg),
- FOLL_FORCE | FOLL_WRITE)
+ FOLL_PTRACE | FOLL_WRITE)
!= sizeof(reg))
return -EFAULT;
pos++;
diff --git a/arch/x86/kernel/step.c b/arch/x86/kernel/step.c
index 8e2b2552b5ee..7c11da8bbe4c 100644
--- a/arch/x86/kernel/step.c
+++ b/arch/x86/kernel/step.c
@@ -60,7 +60,7 @@ static int is_setting_trap_flag(struct task_struct *child, struct pt_regs *regs)
unsigned long addr = convert_ip_to_linear(child, regs);
copied = access_process_vm(child, addr, opcode, sizeof(opcode),
- FOLL_FORCE);
+ FOLL_PTRACE);
for (i = 0; i < copied; i++) {
switch (opcode[i]) {
/* popf and iret */
diff --git a/arch/x86/um/ptrace_32.c b/arch/x86/um/ptrace_32.c
index 0bc4b73a9cde..a40430123448 100644
--- a/arch/x86/um/ptrace_32.c
+++ b/arch/x86/um/ptrace_32.c
@@ -38,7 +38,7 @@ int is_syscall(unsigned long addr)
* in case of singlestepping, if copy_from_user failed.
*/
n = access_process_vm(current, addr, &instr, sizeof(instr),
- FOLL_FORCE);
+ FOLL_PTRACE);
if (n != sizeof(instr)) {
printk(KERN_ERR "is_syscall : failed to read "
"instruction from 0x%lx\n", addr);
diff --git a/arch/x86/um/ptrace_64.c b/arch/x86/um/ptrace_64.c
index 289d0159b041..d9f8cba121d6 100644
--- a/arch/x86/um/ptrace_64.c
+++ b/arch/x86/um/ptrace_64.c
@@ -203,7 +203,7 @@ int is_syscall(unsigned long addr)
* in case of singlestepping, if copy_from_user failed.
*/
n = access_process_vm(current, addr, &instr, sizeof(instr),
- FOLL_FORCE);
+ FOLL_PTRACE);
if (n != sizeof(instr)) {
printk("is_syscall : failed to read instruction from "
"0x%lx\n", addr);
diff --git a/fs/exec.c b/fs/exec.c
index a0b1f0337a62..e616abec8b82 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -199,7 +199,7 @@ static struct page *get_arg_page(struct linux_binprm *bprm, unsigned long pos,
{
struct page *page;
int ret;
- unsigned int gup_flags = FOLL_FORCE;
+ unsigned int gup_flags = FOLL_PTRACE;
#ifdef CONFIG_STACK_GROWSUP
if (write) {
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 9e479d7d202b..f84a85a0f36d 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -854,7 +854,7 @@ static ssize_t mem_rw(struct file *file, char __user *buf,
if (!mmget_not_zero(mm))
goto free;
- flags = FOLL_FORCE | (write ? FOLL_WRITE : 0);
+ flags = FOLL_PTRACE | (write ? FOLL_WRITE : 0);
while (count > 0) {
size_t this_len = min_t(size_t, count, PAGE_SIZE);
diff --git a/include/linux/mm.h b/include/linux/mm.h
index e8cc838f42f9..037423431225 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2999,7 +2999,7 @@ struct page *follow_page(struct vm_area_struct *vma, unsigned long address,
#define FOLL_TOUCH 0x02 /* mark page accessed */
#define FOLL_GET 0x04 /* do get_page on page */
#define FOLL_DUMP 0x08 /* give error on hole if it would be zero */
-#define FOLL_FORCE 0x10 /* get_user_pages read/write w/o permission */
+#define FOLL_PTRACE 0x10 /* get_user_pages read/write w/o permission */
#define FOLL_NOWAIT 0x20 /* if a disk transfer is needed, start the IO
* and return without waiting upon it */
#define FOLL_NOFAULT 0x80 /* do not fault in pages */
@@ -3151,12 +3151,12 @@ static inline bool gup_must_unshare(struct vm_area_struct *vma,
static inline bool gup_can_follow_protnone(unsigned int flags)
{
/*
- * FOLL_FORCE has to be able to make progress even if the VMA is
- * inaccessible. Further, FOLL_FORCE access usually does not represent
+ * FOLL_PTRACE has to be able to make progress even if the VMA is
+ * inaccessible. Further, FOLL_PTRACE access usually does not represent
* application behaviour and we should avoid triggering NUMA hinting
* faults.
*/
- return flags & FOLL_FORCE;
+ return flags & FOLL_PTRACE;
}
typedef int (*pte_fn_t)(pte_t *pte, unsigned long addr, void *data);
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index d9e357b7e17c..6f67c1164f10 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -466,7 +466,7 @@ int uprobe_write_opcode(struct arch_uprobe *auprobe, struct mm_struct *mm,
struct vm_area_struct *vma;
int ret, is_register, ref_ctr_updated = 0;
bool orig_page_huge = false;
- unsigned int gup_flags = FOLL_FORCE;
+ unsigned int gup_flags = FOLL_PTRACE;
is_register = is_swbp_insn(&opcode);
uprobe = container_of(auprobe, struct uprobe, arch);
@@ -2028,7 +2028,7 @@ static int is_trap_at_addr(struct mm_struct *mm, unsigned long vaddr)
* but we treat this as a 'remote' access since it is
* essentially a kernel access to the memory.
*/
- result = get_user_pages_remote(mm, vaddr, 1, FOLL_FORCE, &page,
+ result = get_user_pages_remote(mm, vaddr, 1, FOLL_PTRACE, &page,
NULL, NULL);
if (result < 0)
return result;
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 54482193e1ed..81394ebd96aa 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -632,7 +632,7 @@ int ptrace_readdata(struct task_struct *tsk, unsigned long src, char __user *dst
int this_len, retval;
this_len = (len > sizeof(buf)) ? sizeof(buf) : len;
- retval = ptrace_access_vm(tsk, src, buf, this_len, FOLL_FORCE);
+ retval = ptrace_access_vm(tsk, src, buf, this_len, FOLL_PTRACE);
if (!retval) {
if (copied)
@@ -661,7 +661,7 @@ int ptrace_writedata(struct task_struct *tsk, char __user *src, unsigned long ds
if (copy_from_user(buf, src, this_len))
return -EFAULT;
retval = ptrace_access_vm(tsk, dst, buf, this_len,
- FOLL_FORCE | FOLL_WRITE);
+ FOLL_PTRACE | FOLL_WRITE);
if (!retval) {
if (copied)
break;
@@ -1309,7 +1309,7 @@ int generic_ptrace_peekdata(struct task_struct *tsk, unsigned long addr,
unsigned long tmp;
int copied;
- copied = ptrace_access_vm(tsk, addr, &tmp, sizeof(tmp), FOLL_FORCE);
+ copied = ptrace_access_vm(tsk, addr, &tmp, sizeof(tmp), FOLL_PTRACE);
if (copied != sizeof(tmp))
return -EIO;
return put_user(tmp, (unsigned long __user *)data);
@@ -1321,7 +1321,7 @@ int generic_ptrace_pokedata(struct task_struct *tsk, unsigned long addr,
int copied;
copied = ptrace_access_vm(tsk, addr, &data, sizeof(data),
- FOLL_FORCE | FOLL_WRITE);
+ FOLL_PTRACE | FOLL_WRITE);
return (copied == sizeof(data)) ? 0 : -EIO;
}
@@ -1339,7 +1339,7 @@ int compat_ptrace_request(struct task_struct *child, compat_long_t request,
case PTRACE_PEEKTEXT:
case PTRACE_PEEKDATA:
ret = ptrace_access_vm(child, addr, &word, sizeof(word),
- FOLL_FORCE);
+ FOLL_PTRACE);
if (ret != sizeof(word))
ret = -EIO;
else
@@ -1349,7 +1349,7 @@ int compat_ptrace_request(struct task_struct *child, compat_long_t request,
case PTRACE_POKETEXT:
case PTRACE_POKEDATA:
ret = ptrace_access_vm(child, addr, &data, sizeof(data),
- FOLL_FORCE | FOLL_WRITE);
+ FOLL_PTRACE | FOLL_WRITE);
ret = (ret != sizeof(data) ? -EIO : 0);
break;
diff --git a/mm/gup.c b/mm/gup.c
index 01116699c863..323edebd0399 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -482,7 +482,7 @@ static int follow_pfn_pte(struct vm_area_struct *vma, unsigned long address,
return -EEXIST;
}
-/* FOLL_FORCE can write to even unwritable PTEs in COW mappings. */
+/* FOLL_PTRACE can write to even unwritable PTEs in COW mappings. */
static inline bool can_follow_write_pte(pte_t pte, struct page *page,
struct vm_area_struct *vma,
unsigned int flags)
@@ -491,11 +491,11 @@ static inline bool can_follow_write_pte(pte_t pte, struct page *page,
if (pte_write(pte))
return true;
- /* Maybe FOLL_FORCE is set to override it? */
- if (!(flags & FOLL_FORCE))
+ /* Maybe FOLL_PTRACE is set to override it? */
+ if (!(flags & FOLL_PTRACE))
return false;
- /* But FOLL_FORCE has no effect on shared mappings */
+ /* But FOLL_PTRACE has no effect on shared mappings */
if (vma->vm_flags & (VM_MAYSHARE | VM_SHARED))
return false;
@@ -942,7 +942,7 @@ static int check_vma_flags(struct vm_area_struct *vma, unsigned long gup_flags)
if (write) {
if (!(vm_flags & VM_WRITE)) {
- if (!(gup_flags & FOLL_FORCE))
+ if (!(gup_flags & FOLL_PTRACE))
return -EFAULT;
/*
* We used to let the write,force case do COW in a
@@ -957,7 +957,7 @@ static int check_vma_flags(struct vm_area_struct *vma, unsigned long gup_flags)
return -EFAULT;
}
} else if (!(vm_flags & VM_READ)) {
- if (!(gup_flags & FOLL_FORCE))
+ if (!(gup_flags & FOLL_PTRACE))
return -EFAULT;
/*
* Is there actually any vma we can reach here which does not
@@ -1455,7 +1455,7 @@ long populate_vma_page_range(struct vm_area_struct *vma,
* other than PROT_NONE.
*/
if (vma_is_accessible(vma))
- gup_flags |= FOLL_FORCE;
+ gup_flags |= FOLL_PTRACE;
/*
* We made sure addr is within a VMA, so the following will
@@ -1507,11 +1507,11 @@ long faultin_vma_page_range(struct vm_area_struct *vma, unsigned long start,
/*
* FOLL_TOUCH: Mark page accessed and thereby young; will also mark
* the page dirty with FOLL_WRITE -- which doesn't make a
- * difference with !FOLL_FORCE, because the page is writable
+ * difference with !FOLL_PTRACE, because the page is writable
* in the page table.
* FOLL_HWPOISON: Return -EHWPOISON instead of -EFAULT when we hit
* a poisoned page.
- * !FOLL_FORCE: Require proper access permissions.
+ * !FOLL_PTRACE: Require proper access permissions.
*/
gup_flags = FOLL_TOUCH | FOLL_HWPOISON;
if (write)
@@ -1601,11 +1601,11 @@ static long __get_user_pages_locked(struct mm_struct *mm, unsigned long start,
long i;
/* calculate required read or write permissions.
- * If FOLL_FORCE is set, we only require the "MAY" flags.
+ * If FOLL_PTRACE is set, we only require the "MAY" flags.
*/
vm_flags = (foll_flags & FOLL_WRITE) ?
(VM_WRITE | VM_MAYWRITE) : (VM_READ | VM_MAYREAD);
- vm_flags &= (foll_flags & FOLL_FORCE) ?
+ vm_flags &= (foll_flags & FOLL_PTRACE) ?
(VM_MAYREAD | VM_MAYWRITE) : (VM_READ | VM_WRITE);
for (i = 0; i < nr_pages; i++) {
@@ -1807,7 +1807,7 @@ struct page *get_dump_page(unsigned long addr)
if (mmap_read_lock_killable(mm))
return NULL;
ret = __get_user_pages_locked(mm, addr, 1, &page, NULL, &locked,
- FOLL_FORCE | FOLL_DUMP | FOLL_GET);
+ FOLL_PTRACE | FOLL_DUMP | FOLL_GET);
if (locked)
mmap_read_unlock(mm);
return (ret == 1) ? page : NULL;
@@ -2198,7 +2198,7 @@ EXPORT_SYMBOL(get_user_pages);
*
* It is functionally equivalent to get_user_pages_fast so
* get_user_pages_fast should be used instead if specific gup_flags
- * (e.g. FOLL_FORCE) are not required.
+ * (e.g. FOLL_PTRACE) are not required.
*/
long get_user_pages_unlocked(unsigned long start, unsigned long nr_pages,
struct page **pages, unsigned int gup_flags)
@@ -2869,7 +2869,7 @@ static int internal_get_user_pages_fast(unsigned long start,
int ret;
if (WARN_ON_ONCE(gup_flags & ~(FOLL_WRITE | FOLL_LONGTERM |
- FOLL_FORCE | FOLL_PIN | FOLL_GET |
+ FOLL_PTRACE | FOLL_PIN | FOLL_GET |
FOLL_FAST_ONLY | FOLL_NOFAULT)))
return -EINVAL;
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index dec7a7c0eca8..695792d2495d 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1371,7 +1371,7 @@ static inline bool can_change_pmd_writable(struct vm_area_struct *vma,
return pmd_dirty(pmd);
}
-/* FOLL_FORCE can write to even unwritable PMDs in COW mappings. */
+/* FOLL_PTRACE can write to even unwritable PMDs in COW mappings. */
static inline bool can_follow_write_pmd(pmd_t pmd, struct page *page,
struct vm_area_struct *vma,
unsigned int flags)
@@ -1380,11 +1380,11 @@ static inline bool can_follow_write_pmd(pmd_t pmd, struct page *page,
if (pmd_write(pmd))
return true;
- /* Maybe FOLL_FORCE is set to override it? */
- if (!(flags & FOLL_FORCE))
+ /* Maybe FOLL_PTRACE is set to override it? */
+ if (!(flags & FOLL_PTRACE))
return false;
- /* But FOLL_FORCE has no effect on shared mappings */
+ /* But FOLL_PTRACE has no effect on shared mappings */
if (vma->vm_flags & (VM_MAYSHARE | VM_SHARED))
return false;
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index c3aab6d5b7aa..de78ff9db801 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -5315,7 +5315,7 @@ static vm_fault_t hugetlb_wp(struct mm_struct *mm, struct vm_area_struct *vma,
struct mmu_notifier_range range;
/*
- * hugetlb does not support FOLL_FORCE-style write faults that keep the
+ * hugetlb does not support FOLL_PTRACE-style write faults that keep the
* PTE mapped R/O such as maybe_mkwrite() would do.
*/
if (WARN_ON_ONCE(!unshare && !(vma->vm_flags & VM_WRITE)))
diff --git a/mm/memory.c b/mm/memory.c
index 56b21ab1e4d2..8b47cd40a7b9 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3383,7 +3383,7 @@ static vm_fault_t do_wp_page(struct vm_fault *vmf)
/*
* Private mapping: create an exclusive anonymous page copy if reuse
- * is impossible. We might miss VM_WRITE for FOLL_FORCE handling.
+ * is impossible. We might miss VM_WRITE for FOLL_PTRACE handling.
*/
if (folio && folio_test_anon(folio)) {
/*
@@ -5172,7 +5172,7 @@ static vm_fault_t sanitize_fault_flags(struct vm_area_struct *vma,
/* Write faults on read-only mappings are impossible ... */
if (WARN_ON_ONCE(!(vma->vm_flags & VM_MAYWRITE)))
return VM_FAULT_SIGSEGV;
- /* ... and FOLL_FORCE only applies to COW mappings. */
+ /* ... and FOLL_PTRACE only applies to COW mappings. */
if (WARN_ON_ONCE(!(vma->vm_flags & VM_WRITE) &&
!is_cow_mapping(vma->vm_flags)))
return VM_FAULT_SIGSEGV;
diff --git a/mm/util.c b/mm/util.c
index b56c92fb910f..04be917bfb1b 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -985,7 +985,7 @@ int get_cmdline(struct task_struct *task, char *buffer, int buflen)
if (len > buflen)
len = buflen;
- res = access_process_vm(task, arg_start, buffer, len, FOLL_FORCE);
+ res = access_process_vm(task, arg_start, buffer, len, FOLL_PTRACE);
/*
* If the nul at the end of args has been overwritten, then
@@ -1001,7 +1001,7 @@ int get_cmdline(struct task_struct *task, char *buffer, int buflen)
len = buflen - res;
res += access_process_vm(task, env_start,
buffer+res, len,
- FOLL_FORCE);
+ FOLL_PTRACE);
res = strnlen(buffer, res);
}
}
diff --git a/security/tomoyo/domain.c b/security/tomoyo/domain.c
index 31af29f669d2..c52a93631866 100644
--- a/security/tomoyo/domain.c
+++ b/security/tomoyo/domain.c
@@ -916,7 +916,7 @@ bool tomoyo_dump_page(struct linux_binprm *bprm, unsigned long pos,
*/
mmap_read_lock(bprm->mm);
ret = get_user_pages_remote(bprm->mm, pos, 1,
- FOLL_FORCE, &page, NULL, NULL);
+ FOLL_PTRACE, &page, NULL, NULL);
mmap_read_unlock(bprm->mm);
if (ret <= 0)
return false;
--
2.38.1
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
^ permalink raw reply related
* [PATCH mm-unstable v1 19/20] habanalabs: remove FOLL_FORCE usage
From: David Hildenbrand @ 2022-11-16 10:26 UTC (permalink / raw)
To: linux-kernel
Cc: x86, linux-alpha, linux-arm-kernel, linux-ia64, linux-mips,
linuxppc-dev, sparclinux, linux-um, etnaviv, dri-devel,
linux-samsung-soc, linux-rdma, linux-media, linux-fsdevel,
linux-mm, linux-perf-users, linux-security-module,
linux-kselftest, Linus Torvalds, Andrew Morton, Jason Gunthorpe,
John Hubbard, Peter Xu, Greg Kroah-Hartman, Andrea Arcangeli,
Hugh Dickins, Nadav Amit, Vlastimil Babka, Matthew Wilcox,
Mike Kravetz, Muchun Song, Shuah Khan, Lucas Stach, David Airlie,
Oded Gabbay, Arnd Bergmann, Christoph Hellwig, Alex Williamson,
David Hildenbrand
In-Reply-To: <20221116102659.70287-1-david@redhat.com>
FOLL_FORCE is really only for ptrace access. As we unpin the pinned pages
using unpin_user_pages_dirty_lock(true), the assumption is that all these
pages are writable.
FOLL_FORCE in this case seems to be due to copy-and-past from other
drivers. Let's just remove it.
Acked-by: Oded Gabbay <ogabbay@kernel.org>
Cc: Oded Gabbay <ogabbay@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: David Hildenbrand <david@redhat.com>
---
drivers/misc/habanalabs/common/memory.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/misc/habanalabs/common/memory.c b/drivers/misc/habanalabs/common/memory.c
index ef28f3b37b93..e35cca96bbef 100644
--- a/drivers/misc/habanalabs/common/memory.c
+++ b/drivers/misc/habanalabs/common/memory.c
@@ -2312,8 +2312,7 @@ static int get_user_memory(struct hl_device *hdev, u64 addr, u64 size,
if (!userptr->pages)
return -ENOMEM;
- rc = pin_user_pages_fast(start, npages,
- FOLL_FORCE | FOLL_WRITE | FOLL_LONGTERM,
+ rc = pin_user_pages_fast(start, npages, FOLL_WRITE | FOLL_LONGTERM,
userptr->pages);
if (rc != npages) {
--
2.38.1
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox