From: Andy Lutomirski <luto@amacapital.net>
To: David Herrmann <dh.herrmann@gmail.com>,
Tony Battersby <tonyb@cybernetics.com>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 2/6] shm: add sealing API
Date: Thu, 10 Apr 2014 18:27:56 -0700 [thread overview]
Message-ID: <5347451C.4060106@amacapital.net> (raw)
In-Reply-To: <CANq1E4RWf_VbzF+dPYhzHKJvnrh86me5KajmaaB1u9f9FLzftA@mail.gmail.com>
On 04/10/2014 05:22 PM, David Herrmann wrote:
> Hi
>
> On Thu, Apr 10, 2014 at 11:33 PM, Tony Battersby <tonyb@cybernetics.com> wrote:
>> For O_DIRECT the kernel pins the submitted pages in memory for DMA by
>> incrementing the page reference counts when the I/O is submitted,
>> allowing the pages to be modified by DMA even if they are no longer
>> mapped in the address space of the process. This is different from a
>> regular read(), which uses the CPU to copy the data and will fail if the
>> pages are not mapped.
>
> Can you please provide an example code-path? For instance,
> file_read_actor() does not pin any pages but only keeps the user-space
> address and resolves it once it has data to write.
This may be an issue for anything in the kernel that calls
get_user_pages and holds onto the result at any time that mmap_sem isn't
held.
I don't know exactly what does that, but RDMA comes to mind. So does
(ugh!) vmsplice, although I suspect that vmsplice doesn't write.
--Andy
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Andy Lutomirski <luto@amacapital.net>
To: David Herrmann <dh.herrmann@gmail.com>,
Tony Battersby <tonyb@cybernetics.com>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 2/6] shm: add sealing API
Date: Thu, 10 Apr 2014 18:27:56 -0700 [thread overview]
Message-ID: <5347451C.4060106@amacapital.net> (raw)
In-Reply-To: <CANq1E4RWf_VbzF+dPYhzHKJvnrh86me5KajmaaB1u9f9FLzftA@mail.gmail.com>
On 04/10/2014 05:22 PM, David Herrmann wrote:
> Hi
>
> On Thu, Apr 10, 2014 at 11:33 PM, Tony Battersby <tonyb@cybernetics.com> wrote:
>> For O_DIRECT the kernel pins the submitted pages in memory for DMA by
>> incrementing the page reference counts when the I/O is submitted,
>> allowing the pages to be modified by DMA even if they are no longer
>> mapped in the address space of the process. This is different from a
>> regular read(), which uses the CPU to copy the data and will fail if the
>> pages are not mapped.
>
> Can you please provide an example code-path? For instance,
> file_read_actor() does not pin any pages but only keeps the user-space
> address and resolves it once it has data to write.
This may be an issue for anything in the kernel that calls
get_user_pages and holds onto the result at any time that mmap_sem isn't
held.
I don't know exactly what does that, but RDMA comes to mind. So does
(ugh!) vmsplice, although I suspect that vmsplice doesn't write.
--Andy
next prev parent reply other threads:[~2014-04-11 1:27 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-10 21:33 [PATCH 2/6] shm: add sealing API Tony Battersby
2014-04-10 21:33 ` Tony Battersby
2014-04-11 0:22 ` David Herrmann
2014-04-11 0:22 ` David Herrmann
2014-04-11 0:22 ` David Herrmann
2014-04-11 1:27 ` Andy Lutomirski [this message]
2014-04-11 1:27 ` Andy Lutomirski
2014-04-11 13:43 ` Tony Battersby
2014-04-11 13:43 ` Tony Battersby
2014-04-11 21:31 ` David Herrmann
2014-04-11 21:31 ` David Herrmann
2014-04-11 21:31 ` David Herrmann
2014-04-11 21:36 ` Andy Lutomirski
2014-04-11 21:36 ` Andy Lutomirski
2014-04-11 21:42 ` David Herrmann
2014-04-11 21:42 ` David Herrmann
2014-04-11 21:42 ` David Herrmann
2014-04-11 22:07 ` Andy Lutomirski
2014-04-11 22:07 ` Andy Lutomirski
2014-04-14 0:03 ` David Herrmann
2014-04-14 0:03 ` David Herrmann
2014-04-14 0:03 ` David Herrmann
-- strict thread matches above, loose matches on Subject: below --
2014-03-19 19:06 [PATCH 0/6] File Sealing & memfd_create() David Herrmann
2014-03-19 19:06 ` [PATCH 2/6] shm: add sealing API David Herrmann
2014-03-19 19:06 ` David Herrmann
2014-03-19 19:06 ` David Herrmann
2014-03-19 19:06 ` David Herrmann
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=5347451C.4060106@amacapital.net \
--to=luto@amacapital.net \
--cc=dh.herrmann@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=tonyb@cybernetics.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.