From: Jan Kara <jack@suse.cz>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH] mm: Avoid returning VM_FAULT_RETRY from ->page_mkwrite handlers
Date: Mon, 6 Feb 2017 10:24:15 +0100 [thread overview]
Message-ID: <20170206092415.GD4004@quack2.suse.cz> (raw)
In-Reply-To: <20170203152054.6ee9f8a920e6d0ac8a93d2b9@linux-foundation.org>
On Fri 03-02-17 15:20:54, Andrew Morton wrote:
> On Fri, 3 Feb 2017 16:07:29 +0100 Jan Kara <jack@suse.cz> wrote:
>
> > Some ->page_mkwrite handlers may return VM_FAULT_RETRY as its return
> > code (GFS2 or Lustre can definitely do this). However VM_FAULT_RETRY
> > from ->page_mkwrite is completely unhandled by the mm code and results
> > in locking and writeably mapping the page which definitely is not what
> > the caller wanted. Fix Lustre and block_page_mkwrite_ret() used by other
> > filesystems (notably GFS2) to return VM_FAULT_NOPAGE instead which
> > results in bailing out from the fault code, the CPU then retries the
> > access, and we fault again effectively doing what the handler wanted.
>
> I'm not getting any sense of the urgency of this fix. The bug *sounds*
> bad? Which kernel versions need fixing?
So I did more analysis of GFS2 and Lustre behavior. AFAICS GFS2 returns
EAGAIN only for truncated page, when we then return with VM_FAULT_RETRY,
do_page_mkwrite() locks the page, sees it is truncated and bails out
properly thus silently fixes up the problem. The Lustre bug looks like it
could actually result in some real problems and the bug is there since the
initial commit in which Lustre was added in 3.11 (d7e09d0397e84).
So overall the issue doesn't look like too serious currently but it is
certainly a serious bug waiting to happen.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2017-02-06 9:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-03 15:07 [Cluster-devel] [PATCH] mm: Avoid returning VM_FAULT_RETRY from ->page_mkwrite handlers Jan Kara
2017-02-03 15:13 ` Matthew Wilcox
2017-02-03 15:46 ` Jan Kara
2017-02-03 15:53 ` Matthew Wilcox
2017-02-03 16:10 ` Jan Kara
2017-02-03 23:20 ` Andrew Morton
2017-02-06 9:24 ` Jan Kara [this message]
2017-02-03 23:44 ` [Cluster-devel] [lustre-devel] " Xiong, Jinshan
2017-02-06 8:59 ` Jan Kara
2017-02-06 20:52 ` Xiong, Jinshan
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=20170206092415.GD4004@quack2.suse.cz \
--to=jack@suse.cz \
/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).