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@xxxxxxxxx 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 >
