From: Jan Kara <jack@suse.cz>
To: Ira Weiny <ira.weiny@intel.com>
Cc: "Theodore Y. Ts'o" <tytso@mit.edu>,
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, 22 Apr 2020 18:10:29 +0200 [thread overview]
Message-ID: <20200422161029.GD20756@quack2.suse.cz> (raw)
In-Reply-To: <20200416052352.GK2309605@iweiny-DESK2.sc.intel.com>
On Wed 15-04-20 22:23:52, Ira Weiny wrote:
> On Wed, Apr 15, 2020 at 06:07:52PM -0400, Theodore Y. Ts'o wrote:
> > 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.
>
> But we do support not supplying the option which means 'nodax' right?
Yeah, I second what Ira wrote. The new code does not seem to properly
detect a case when enabled mount option is removed for remount and thus the
feature would get disabled during remount as a result...
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2020-04-22 16:10 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
2020-04-16 5:23 ` Ira Weiny
2020-04-22 16:10 ` Jan Kara [this message]
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=20200422161029.GD20756@quack2.suse.cz \
--to=jack@suse.cz \
--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 \
--cc=tytso@mit.edu \
/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.