From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Ira Weiny <ira.weiny@intel.com>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>,
syzkaller-bugs@googlegroups.com, stable@kernel.org,
syzbot+bca9799bf129256190da@syzkaller.appspotmail.com
Subject: Re: [PATCH] ext4: reject mount options not supported when remounting in handle_mount_opt()
Date: Wed, 15 Apr 2020 18:07:52 -0400 [thread overview]
Message-ID: <20200415220752.GA5187@mit.edu> (raw)
In-Reply-To: <20200415202537.GA2309605@iweiny-DESK2.sc.intel.com>
On Wed, Apr 15, 2020 at 01:25:37PM -0700, Ira Weiny wrote:
> This fundamentally changes the behavior from forcing the dax mode to be the
> same across the remount to only failing if we are going from non-dax to dax,
> adding -o dax on the remount?
>
> But going from -o dax to 'not -o dax' would be ok?
>
> FWIW after thinking about it some I _think_ it would be ok to allow the dax
> mode to change on a remount and let the inodes in memory stay in the mode they
> are at. And newly loaded inodes would get the new mode... Unfortunately
> without the STATX patch I have proposed the user does not have any way of
> knowing which files are in which mode.
We don't currently support mount -o nodax. So the intention of the
current code is that the dax mode can't change in either direction
(enabling or disabling) as a remount option.
The syzkaller report was because changing dax mode racing with other
operations given the current code base, could result in a kernel OOPS.
So we *do* need to rule it out at least for now.
I certainly don't object to allowing changing dax mode as a remount
--- so long as we have tests to make sure that if we stress opening,
reading, writing, mmap'ing files, etc., while another thread is
flipping back and forth between dax=never and dax=always is mount -o
remount --- and make sure that we don't end up crashing.
And this test needs to be in xfstests, because trying to figure out
what triggers a syzkaller failures in file system land is a pain in
the *ss so we really want a dedicated xfstests for this case. Have
you tested your patch series to make sure we don't have some potential
races here?
- Ted
next prev parent reply other threads:[~2020-04-15 22:08 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <to=00000000000098a5d505a34d1e48@google.com>
2020-04-15 17:48 ` [PATCH] ext4: reject mount options not supported when remounting in handle_mount_opt() Theodore Ts'o
2020-04-15 18:12 ` Andreas Dilger
2020-04-15 20:25 ` Ira Weiny
2020-04-15 22:07 ` Theodore Y. Ts'o [this message]
2020-04-16 5:23 ` Ira Weiny
2020-04-22 16:10 ` Jan Kara
2020-05-14 14:34 ` Theodore Y. Ts'o
2020-05-16 1:49 ` Ira Weiny
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=20200415220752.GA5187@mit.edu \
--to=tytso@mit.edu \
--cc=ira.weiny@intel.com \
--cc=linux-ext4@vger.kernel.org \
--cc=stable@kernel.org \
--cc=syzbot+bca9799bf129256190da@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.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.