On Tue, May 20, 2025 at 7:16 AM Kent Overstreet <kent.overstreet@xxxxxxxxx> wrote: > > This series allows overlayfs and casefolding to safely be used on the > same filesystem by providing exclusion to ensure that overlayfs never > has to deal with casefolded directories. > > Currently, overlayfs can't be used _at all_ if a filesystem even > supports casefolding, which is really nasty for users. > > Components: > > - filesystem has to track, for each directory, "does any _descendent_ > have casefolding enabled" > > - new inode flag to pass this to VFS layer > > - new dcache methods for providing refs for overlayfs, and filesystem > methods for safely clearing this flag > > - new superblock flag for indicating to overlayfs & dcache "filesystem > supports casefolding, it's safe to use provided new dcache methods are > used" > I don't think that this is really needed. Too bad you did not ask before going through the trouble of this implementation. I think it is enough for overlayfs to know the THIS directory has no casefolding. in ovl_lookup() that returns a merged directory, ovl_dentry_weird() would result in -EIO if any of the real directories have casefolding and we can add another sanotify in ovl_lookup_single() that the 'base' dentry is not weird() to cover the case of casefolder changed on an underlying reference directory. Obviously, if any of the overlayfs layer root dirs have casefolding enabled the mount would fail. w.r.t enabling casefolding underneath overlayfs, overlayfs documentation says: "Changes to underlying filesystems --------------------------------- Changes to the underlying filesystems while part of a mounted overlay filesystem are not allowed. If the underlying filesystem is changed, the behavior of the overlay is undefined, though it will not result in a crash or deadlock." So why is enabling casefolding on underlying layers so special that we should have specific protection for that?
