All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Hubbard <jhubbard@nvidia.com>
To: Jan Kara <jack@suse.cz>, <lsf-pc@lists.linux-foundation.org>
Cc: <linux-fsdevel@vger.kernel.org>, <linux-mm@kvack.org>,
	Dan Williams <dan.j.williams@intel.com>,
	Jerome Glisse <jglisse@redhat.com>
Subject: Re: [LSF/MM TOPIC] get_user_pages() pins in file mappings
Date: Fri, 25 Jan 2019 18:58:15 -0800	[thread overview]
Message-ID: <041368e5-7bca-4093-47da-13f1608b0692@nvidia.com> (raw)
In-Reply-To: <20190124090400.GE12184@quack2.suse.cz>

On 1/24/19 1:04 AM, Jan Kara wrote:
> This is a joint proposal with Dan Williams, John Hubbard, and Jérôme
> Glisse.
> 
> Last year we've talked with Dan about issues we have with filesystems and
> GUP [1]. The crux of the problem lies in the fact that there is no
> coordination (or even awareness) between filesystem working on a page (such
> as doing writeback) and GUP user modifying page contents and setting it
> dirty. This can (and we have user reports of this) lead to data corruption,
> kernel crashes, and other fun.
> 
> Since last year we have worked together on solving these problems and we
> have explored couple dead ends as well as hopefully found solutions to some
> of the partial problems. So I'd like to give some overview of where we
> stand and what remains to be solved and get thoughts from wider community
> about proposed solutions / problems to be solved.
> 
> In particular we hope to have reasonably robust mechanism of identifying
> pages pinned by GUP (patches will be posted soon) - I'd like to run that by
> MM folks (unless discussion happens on mailing lists before LSF/MM). We
> also have ideas how filesystems should react to pinned page in their
> writepages methods - there will be some changes needed in some filesystems
> to bounce the page if they need stable page contents. So I'd like to
> explain why we chose to do bouncing to fs people (i.e., why we cannot just
> wait, skip the page, do something else etc.) to save us from the same
> discussion with each fs separately and also hash out what the API for
> filesystems to do this should look like. Finally we plan to keep pinned
> page permanently dirty - again something I'd like to explain why we do this
> and gather input from other people.
> 
> This should be ideally shared MM + FS session.
> 
> [1] https://lwn.net/Articles/753027/
> 

Yes! I'd like to attend and discuss this, for sure. 

Meanwhile, as usual, I'm a bit late on posting an updated RFC for the page
identification part, but that's coming very soon.


thanks,
-- 
John Hubbard
NVIDIA

WARNING: multiple messages have this Message-ID (diff)
From: John Hubbard <jhubbard@nvidia.com>
To: Jan Kara <jack@suse.cz>, lsf-pc@lists.linux-foundation.org
Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
	Dan Williams <dan.j.williams@intel.com>,
	Jerome Glisse <jglisse@redhat.com>
Subject: Re: [LSF/MM TOPIC] get_user_pages() pins in file mappings
Date: Fri, 25 Jan 2019 18:58:15 -0800	[thread overview]
Message-ID: <041368e5-7bca-4093-47da-13f1608b0692@nvidia.com> (raw)
In-Reply-To: <20190124090400.GE12184@quack2.suse.cz>

On 1/24/19 1:04 AM, Jan Kara wrote:
> This is a joint proposal with Dan Williams, John Hubbard, and Jérôme
> Glisse.
> 
> Last year we've talked with Dan about issues we have with filesystems and
> GUP [1]. The crux of the problem lies in the fact that there is no
> coordination (or even awareness) between filesystem working on a page (such
> as doing writeback) and GUP user modifying page contents and setting it
> dirty. This can (and we have user reports of this) lead to data corruption,
> kernel crashes, and other fun.
> 
> Since last year we have worked together on solving these problems and we
> have explored couple dead ends as well as hopefully found solutions to some
> of the partial problems. So I'd like to give some overview of where we
> stand and what remains to be solved and get thoughts from wider community
> about proposed solutions / problems to be solved.
> 
> In particular we hope to have reasonably robust mechanism of identifying
> pages pinned by GUP (patches will be posted soon) - I'd like to run that by
> MM folks (unless discussion happens on mailing lists before LSF/MM). We
> also have ideas how filesystems should react to pinned page in their
> writepages methods - there will be some changes needed in some filesystems
> to bounce the page if they need stable page contents. So I'd like to
> explain why we chose to do bouncing to fs people (i.e., why we cannot just
> wait, skip the page, do something else etc.) to save us from the same
> discussion with each fs separately and also hash out what the API for
> filesystems to do this should look like. Finally we plan to keep pinned
> page permanently dirty - again something I'd like to explain why we do this
> and gather input from other people.
> 
> This should be ideally shared MM + FS session.
> 
> [1] https://lwn.net/Articles/753027/
> 

Yes! I'd like to attend and discuss this, for sure. 

Meanwhile, as usual, I'm a bit late on posting an updated RFC for the page
identification part, but that's coming very soon.


thanks,
-- 
John Hubbard
NVIDIA

  reply	other threads:[~2019-01-26  2:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-24  9:04 [LSF/MM TOPIC] get_user_pages() pins in file mappings Jan Kara
2019-01-26  2:58 ` John Hubbard [this message]
2019-01-26  2:58   ` John Hubbard
2019-02-04 23:46 ` John Hubbard
2019-02-05 11:21   ` Jan Kara
2019-02-06  2:10     ` John Hubbard

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=041368e5-7bca-4093-47da-13f1608b0692@nvidia.com \
    --to=jhubbard@nvidia.com \
    --cc=dan.j.williams@intel.com \
    --cc=jack@suse.cz \
    --cc=jglisse@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lsf-pc@lists.linux-foundation.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 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.