From: Jason Gunthorpe <jgg@nvidia.com>
To: Lorenzo Stoakes <lstoakes@gmail.com>
Cc: Christoph Hellwig <hch@infradead.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
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,
Oleg Nesterov <oleg@redhat.com>
Subject: Re: [PATCH v2] mm/gup: disallow GUP writing to file-backed mappings by default
Date: Mon, 24 Apr 2023 10:39:25 -0300 [thread overview]
Message-ID: <ZEaGjad50lqRNTWD@nvidia.com> (raw)
In-Reply-To: <c8fff8b3-ead6-4f52-bf17-f2ef2e752b57@lucifer.local>
On Mon, Apr 24, 2023 at 01:38:49PM +0100, Lorenzo Stoakes wrote:
> I was being fairly conservative in that list, though we certainly need to
> set the flag for /proc/$pid/mem and ptrace to avoid breaking this
> functionality (I observed breakpoints breaking without it which obviously
> is a no go :). I'm not sure if there's a more general way we could check
> for this though?
More broadly we should make sure these usages of GUP safe somehow so
that it can reliably write to those types of pages without breaking
the current FS contract..
I forget exactly, but IIRC, don't you have to hold some kind of page
spinlock while writing to the page memory?
So, users that do this, or can be fixed to do this, can get file
backed pages. It suggests that a flag name is more like
FOLL_CALLER_USES_FILE_WRITE_LOCKING
> I wouldn't be totally opposed to dropping it for RDMA too, because I
> suspect accessing file-backed mappings for that is pretty iffy.
>
> Do you have a sense of which in the list you feel could be pared back?
Anything using FOLL_LONGTERM should not set the flag, GUP should even
block the combination.
And we need to have in mind that the flag indicates the code is
buggy, so if you set it then we should understand how is that caller
expected to be fixed.
Jason
next prev parent reply other threads:[~2023-04-24 13:40 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-24 7:43 [PATCH v2] mm/gup: disallow GUP writing to file-backed mappings by default Lorenzo Stoakes
2023-04-24 9:43 ` Christoph Hellwig
2023-04-24 10:17 ` Lorenzo Stoakes
2023-04-24 12:28 ` Jason Gunthorpe
2023-04-24 12:38 ` Christoph Hellwig
2023-04-24 13:26 ` Jason Gunthorpe
2023-04-24 12:38 ` Lorenzo Stoakes
2023-04-24 13:39 ` Jason Gunthorpe [this message]
2023-04-24 14:29 ` Lorenzo Stoakes
2023-04-24 17:36 ` Jason Gunthorpe
2023-04-24 18:22 ` Lorenzo Stoakes
2023-04-24 18:54 ` Jason Gunthorpe
2023-04-24 19:18 ` Lorenzo Stoakes
2023-04-24 22:53 ` Jason Gunthorpe
2023-04-24 23:03 ` Lorenzo Stoakes
2023-04-24 23:17 ` Jason Gunthorpe
2023-04-24 23:26 ` Lorenzo Stoakes
2023-04-24 23:30 ` 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=ZEaGjad50lqRNTWD@nvidia.com \
--to=jgg@nvidia.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=akpm@linux-foundation.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=ast@kernel.org \
--cc=axboe@kernel.dk \
--cc=benve@cisco.com \
--cc=bjorn@kernel.org \
--cc=bmt@zurich.ibm.com \
--cc=bpf@vger.kernel.org \
--cc=brauner@kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=dennis.dalessandro@cornelisnetworks.com \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=hch@infradead.org \
--cc=irogers@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=jonathan.lemon@gmail.com \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=lstoakes@gmail.com \
--cc=maciej.fijalkowski@intel.com \
--cc=magnus.karlsson@intel.com \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=neescoba@cisco.com \
--cc=netdev@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=pabeni@redhat.com \
--cc=peterz@infradead.org \
--cc=richardcochran@gmail.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).