Messages in this thread | | | Date | Tue, 21 Apr 2020 11:41:43 -0700 | From | Ira Weiny <> | Subject | Re: [PATCH RFC 3/8] fs/ext4: Disallow encryption if inode is DAX |
| |
On Wed, Apr 15, 2020 at 12:54:34PM -0700, 'Ira Weiny' wrote: > On Wed, Apr 15, 2020 at 12:03:07PM -0400, Theodore Y. Ts'o wrote: > > On Mon, Apr 13, 2020 at 09:00:25PM -0700, ira.weiny@intel.com wrote:
[snip]
> > > > Also note that encrypted files are read/write so we must never allow > > the combination of ENCRPYT_FL and DAX_FL. So that may be something > > where we should teach __ext4_iget() to check for this, and declare the > > file system as corrupted if it sees this combination. > > ok...
After thinking about this...
Do we really want to declare the FS corrupted?
If so, I think we need to return errors when such a configuration is attempted. If in the future we have an encrypted mode which can co-exist with DAX (such as Dan mentioned) we can change this.
FWIW I think we should return errors when such a configuration is attempted but _not_ declare the FS corrupted. That allows users to enable this configuration later if we can figure out how to support it.
> > > (For VERITY_FL > > && DAX_FL that is a combo that we might want to support in the future, > > so that's probably a case where arguably, we should just ignore the > > DAX_FL for now.) > > ok...
I think this should work the same.
It looks like VERITY_FL and ENCRYPT_FL are _not_ user modifiable? Is that correct?
You said that ENCRPYT_FL is set from the parent directory? But I'm not seeing where that occurs?
Similarly I don't see where VERITY_FL is being set either? :-/
I think to make this work correctly we should restrict setting those flags if DAX_FL is set and vice versa. But I'm not finding where to do that. :-/
Ira
> > Ira >
| |