All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Battersby <tonyb@cybernetics.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: David Herrmann <dh.herrmann@gmail.com>,
	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: Fri, 11 Apr 2014 09:43:36 -0400	[thread overview]
Message-ID: <5347F188.10408@cybernetics.com> (raw)
In-Reply-To: <5347451C.4060106@amacapital.net>

Andy Lutomirski wrote:
> 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.
>
>   

Exactly.  For O_DIRECT, that would be the call to get_user_pages_fast()
from dio_refill_pages() in fs/direct-io.c, which is ultimately called
from blkdev_direct_IO().

>From the comment for get_user_pages_fast(): "Attempt to pin user pages
in memory..."

Tony

--
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: Tony Battersby <tonyb@cybernetics.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: David Herrmann <dh.herrmann@gmail.com>,
	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: Fri, 11 Apr 2014 09:43:36 -0400	[thread overview]
Message-ID: <5347F188.10408@cybernetics.com> (raw)
In-Reply-To: <5347451C.4060106@amacapital.net>

Andy Lutomirski wrote:
> 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.
>
>   

Exactly.  For O_DIRECT, that would be the call to get_user_pages_fast()
from dio_refill_pages() in fs/direct-io.c, which is ultimately called
from blkdev_direct_IO().

>From the comment for get_user_pages_fast(): "Attempt to pin user pages
in memory..."

Tony

  reply	other threads:[~2014-04-11 13:43 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
2014-04-11  1:27     ` Andy Lutomirski
2014-04-11 13:43     ` Tony Battersby [this message]
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=5347F188.10408@cybernetics.com \
    --to=tonyb@cybernetics.com \
    --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=luto@amacapital.net \
    /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.