> I feel definition of "strict" has been expanding as we are discussing.
>
> - Initilaly, I thought that it only meant that any options specified
> as mount option can'e be disabled and if system configuration does
> not support it (for older mount options), we will fail mount.
>
> - Now it also means that Kconfig/module can lock down value of a
> varibale and it can't be disabled from mount option (until and unless
> user passes in strict=off).
>
I managed to confuse you. 'strict' doesn't mean that you cannot
change defaults with mount options at all.
It simply means that every instance of pr_warn("...falling back to")
is going to error instead of disabling a feature whose requirements
are not met.
Better wait for patches it will be clearer to read the code than my
emails...
> Have a quick question. Does backward compatibility applies even if
> both upper/ and workdir/ are empty. IOW, can't we automatically enable
> "strict" when we know that this is the first time overlayfs mount is
> being created (otherwise both upper and workdir will not have been empty)
> and we can enable strict policy without breaking backward compatibility.
>
I have already discussed this with Zhangyi in the context of "overlay
format v2".
There is not backward compat issue if both upper/work dirs are empty.
> /me is assuming that if a overlay mount has been successfuly mounted once,
> workdir will atleast have a subdir named "work".
The check for empty upper & work (including index) dirs should be done after
the cleanup of 'work' dir on mount.
Thanks,
Amir.
