From: Simon Horman <simon.horman@corigine•com>
To: Lorenzo Stoakes <lstoakes@gmail•com>
Cc: linux-mm@kvack•org, linux-kernel@vger•kernel.org,
Andrew Morton <akpm@linux-foundation•org>,
Jason Gunthorpe <jgg@ziepe•ca>, Jens Axboe <axboe@kernel•dk>,
Matthew Wilcox <willy@infradead•org>,
Dennis Dalessandro <dennis.dalessandro@cornelisnetworks•com>,
Leon Romanovsky <leon@kernel•org>,
Christian Benvenuti <benve@cisco•com>,
Nelson Escobar <neescoba@cisco•com>,
Bernard Metzler <bmt@zurich•ibm.com>,
Peter Zijlstra <peterz@infradead•org>,
Ingo Molnar <mingo@redhat•com>,
Arnaldo Carvalho de Melo <acme@kernel•org>,
Mark Rutland <mark.rutland@arm•com>,
Alexander Shishkin <alexander.shishkin@linux•intel.com>,
Jiri Olsa <jolsa@kernel•org>, Namhyung Kim <namhyung@kernel•org>,
Ian Rogers <irogers@google•com>,
Adrian Hunter <adrian.hunter@intel•com>,
Bjorn Topel <bjorn@kernel•org>,
Magnus Karlsson <magnus.karlsson@intel•com>,
Maciej Fijalkowski <maciej.fijalkowski@intel•com>,
Jonathan Lemon <jonathan.lemon@gmail•com>,
"David S . Miller" <davem@davemloft•net>,
Eric Dumazet <edumazet@google•com>,
Jakub Kicinski <kuba@kernel•org>, Paolo Abeni <pabeni@redhat•com>,
Christian Brauner <brauner@kernel•org>,
Richard Cochran <richardcochran@gmail•com>,
Alexei Starovoitov <ast@kernel•org>,
Daniel Borkmann <daniel@iogearbox•net>,
Jesper Dangaard Brouer <hawk@kernel•org>,
John Fastabend <john.fastabend@gmail•com>,
linux-fsdevel@vger•kernel.org, linux-perf-users@vger•kernel.org,
netdev@vger•kernel.org, bpf@vger•kernel.org
Subject: Re: [PATCH] mm/gup: disallow GUP writing to file-backed mappings by default
Date: Sun, 23 Apr 2023 21:32:01 +0200 [thread overview]
Message-ID: <ZEWHsbxhQlrSqnSC@corigine.com> (raw)
In-Reply-To: <f86dc089b460c80805e321747b0898fd1efe93d7.1682168199.git.lstoakes@gmail.com>
On Sat, Apr 22, 2023 at 02:37:05PM +0100, Lorenzo Stoakes wrote:
> It isn't safe to write to file-backed mappings as GUP does not ensure that
> the semantics associated with such a write are performed correctly, for
> instance filesystems which rely upon write-notify will not be correctly
> notified.
>
> There are exceptions to this - shmem and hugetlb mappings are (in effect)
> anonymous mappings by other names so we do permit this operation in these
> cases.
>
> In addition, if no pinning takes place (neither FOLL_GET nor FOLL_PIN is
> specified and neither flags gets implicitly set) then no writing can occur
> so we do not perform the check in this instance.
>
> This is an important exception, as populate_vma_page_range() invokes
> __get_user_pages() in this way (and thus so does __mm_populate(), used by
> MAP_POPULATE mmap() and mlock() invocations).
>
> There are GUP users within the kernel that do nevertheless rely upon this
> behaviour, so we introduce the FOLL_ALLOW_BROKEN_FILE_MAPPING flag to
> explicitly permit this kind of GUP access.
>
> This is required in order to not break userspace in instances where the
> uAPI might permit file-mapped addresses - a number of RDMA users require
> this for instance, as do the process_vm_[read/write]v() system calls,
> /proc/$pid/mem, ptrace and SDT uprobes. Each of these callers have been
> updated to use this flag.
>
> Making this change is an important step towards a more reliable GUP, and
> explicitly indicates which callers might encouter issues moving forward.
nit: s/encouter/encounter/
next prev parent reply other threads:[~2023-04-23 19:37 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-22 13:37 [PATCH] mm/gup: disallow GUP writing to file-backed mappings by default Lorenzo Stoakes
2023-04-23 19:32 ` Simon Horman [this message]
2023-04-23 19:40 ` Lorenzo Stoakes
2023-04-23 20:02 ` Simon Horman
2023-04-23 22:29 ` Dave Chinner
2023-04-23 22:56 ` Lorenzo Stoakes
2023-04-24 17:49 ` Jason Gunthorpe
2023-04-24 3:41 ` Mika Penttilä
2023-04-24 6:51 ` Lorenzo Stoakes
2023-04-24 12:02 ` Kirill A. Shutemov
2023-04-24 12:31 ` Lorenzo Stoakes
2023-04-24 13:40 ` Kirill A. Shutemov
2023-04-24 17:59 ` Jason Gunthorpe
2023-04-24 16:09 ` Jan Kara
2023-04-24 16:22 ` Lorenzo Stoakes
2023-04-24 17:53 ` Jason Gunthorpe
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=ZEWHsbxhQlrSqnSC@corigine.com \
--to=simon.horman@corigine$(echo .)com \
--cc=acme@kernel$(echo .)org \
--cc=adrian.hunter@intel$(echo .)com \
--cc=akpm@linux-foundation$(echo .)org \
--cc=alexander.shishkin@linux$(echo .)intel.com \
--cc=ast@kernel$(echo .)org \
--cc=axboe@kernel$(echo .)dk \
--cc=benve@cisco$(echo .)com \
--cc=bjorn@kernel$(echo .)org \
--cc=bmt@zurich$(echo .)ibm.com \
--cc=bpf@vger$(echo .)kernel.org \
--cc=brauner@kernel$(echo .)org \
--cc=daniel@iogearbox$(echo .)net \
--cc=davem@davemloft$(echo .)net \
--cc=dennis.dalessandro@cornelisnetworks$(echo .)com \
--cc=edumazet@google$(echo .)com \
--cc=hawk@kernel$(echo .)org \
--cc=irogers@google$(echo .)com \
--cc=jgg@ziepe$(echo .)ca \
--cc=john.fastabend@gmail$(echo .)com \
--cc=jolsa@kernel$(echo .)org \
--cc=jonathan.lemon@gmail$(echo .)com \
--cc=kuba@kernel$(echo .)org \
--cc=leon@kernel$(echo .)org \
--cc=linux-fsdevel@vger$(echo .)kernel.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-mm@kvack$(echo .)org \
--cc=linux-perf-users@vger$(echo .)kernel.org \
--cc=lstoakes@gmail$(echo .)com \
--cc=maciej.fijalkowski@intel$(echo .)com \
--cc=magnus.karlsson@intel$(echo .)com \
--cc=mark.rutland@arm$(echo .)com \
--cc=mingo@redhat$(echo .)com \
--cc=namhyung@kernel$(echo .)org \
--cc=neescoba@cisco$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=pabeni@redhat$(echo .)com \
--cc=peterz@infradead$(echo .)org \
--cc=richardcochran@gmail$(echo .)com \
--cc=willy@infradead$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox