[PATCH v3] ovl: support layers on case-folding capable filesystems

[PATCH v3] ovl: support layers on case-folding capable filesystems

[Amir Goldstein]

Case folding is often applied to subtrees and not on an entire
filesystem.

Disallowing layers from filesystems that support case folding is over
limiting.

Replace the rule that case-folding capable are not allowed as layers
with a rule that case folded directories are not allowed in a merged
directory stack.

Should case folding be enabled on an underlying directory while
overlayfs is mounted the outcome is generally undefined.

Specifically in ovl_lookup(), we check the base underlying directory
and fail with -ESTALE and write a warning to kmsg if an underlying
directory case folding is enabled.

Suggested-by: Kent Overstreet <kent.overstreet@linux.dev>
Link: https://lore.kernel.org/linux-fsdevel/20250520051600.1903319-1-kent.overstreet@linux.dev/
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
---

Miklos,

This is my solution to Kent's request to allow overlayfs mount on
bcachefs subtrees that do not have casefolding enabled, while other
subtrees do have casefolding enabled.

I have written a test to cover the change of behavior [1].
This test does not run on old kernel's where the mount always fails
with casefold capable layers.

Let me know what you think.

Kent,

I have tested this on ext4.
Please test on bcachefs.

Thanks,
Amir.

Changes since v1,v2:
- Add ratelimited warnings for the lookup error cases
- Add helper ovl_dentry_casefolded()
- Write fstest [1]

[1] https://github.com/amir73il/xfstests/commits/ovl-casefold/

 fs/overlayfs/namei.c     | 31 ++++++++++++++++++++++++++++---
 fs/overlayfs/overlayfs.h |  6 ++++++
 fs/overlayfs/params.c    | 10 ++++------
 fs/overlayfs/util.c      | 15 +++++++++++----
 4 files changed, 49 insertions(+), 13 deletions(-)

diff --git a/fs/overlayfs/namei.c b/fs/overlayfs/namei.c
index d489e80feb6f..733beef7b810 100644
--- a/fs/overlayfs/namei.c
+++ b/fs/overlayfs/namei.c
@@ -230,13 +230,26 @@ static int ovl_lookup_single(struct dentry *base, struct ovl_lookup_data *d,
 			     struct dentry **ret, bool drop_negative)
 {
 	struct ovl_fs *ofs = OVL_FS(d->sb);
-	struct dentry *this;
+	struct dentry *this = NULL;
+	const char *warn;
 	struct path path;
 	int err;
 	bool last_element = !post[0];
 	bool is_upper = d->layer->idx == 0;
 	char val;
 
+	/*
+	 * We allow filesystems that are case-folding capable but deny composing
+	 * ovl stack from case-folded directories. If someone has enabled case
+	 * folding on a directory on underlying layer, the warranty of the ovl
+	 * stack is voided.
+	 */
+	if (ovl_dentry_casefolded(base)) {
+		warn = "case folded parent";
+		err = -ESTALE;
+		goto out_warn;
+	}
+
 	this = ovl_lookup_positive_unlocked(d, name, base, namelen, drop_negative);
 	if (IS_ERR(this)) {
 		err = PTR_ERR(this);
@@ -246,10 +259,17 @@ static int ovl_lookup_single(struct dentry *base, struct ovl_lookup_data *d,
 		goto out_err;
 	}
 
+	if (ovl_dentry_casefolded(this)) {
+		warn = "case folded child";
+		err = -EREMOTE;
+		goto out_warn;
+	}
+
 	if (ovl_dentry_weird(this)) {
 		/* Don't support traversing automounts and other weirdness */
+		warn = "unsupported object type";
 		err = -EREMOTE;
-		goto out_err;
+		goto out_warn;
 	}
 
 	path.dentry = this;
@@ -283,8 +303,9 @@ static int ovl_lookup_single(struct dentry *base, struct ovl_lookup_data *d,
 	} else {
 		if (ovl_lookup_trap_inode(d->sb, this)) {
 			/* Caught in a trap of overlapping layers */
+			warn = "overlapping layers";
 			err = -ELOOP;
-			goto out_err;
+			goto out_warn;
 		}
 
 		if (last_element)
@@ -316,6 +337,10 @@ static int ovl_lookup_single(struct dentry *base, struct ovl_lookup_data *d,
 	this = NULL;
 	goto out;
 
+out_warn:
+	pr_warn_ratelimited("failed lookup in %s (%pd2, name='%.*s', err=%i): %s\n",
+			    is_upper ? "upper" : "lower", base,
+			    namelen, name, err, warn);
 out_err:
 	dput(this);
 	return err;
diff --git a/fs/overlayfs/overlayfs.h b/fs/overlayfs/overlayfs.h
index aef942a758ce..6c51103d9305 100644
--- a/fs/overlayfs/overlayfs.h
+++ b/fs/overlayfs/overlayfs.h
@@ -446,6 +446,12 @@ void ovl_dentry_init_reval(struct dentry *dentry, struct dentry *upperdentry,
 void ovl_dentry_init_flags(struct dentry *dentry, struct dentry *upperdentry,
 			   struct ovl_entry *oe, unsigned int mask);
 bool ovl_dentry_weird(struct dentry *dentry);
+
+static inline bool ovl_dentry_casefolded(struct dentry *dentry)
+{
+	return sb_has_encoding(dentry->d_sb) && IS_CASEFOLDED(d_inode(dentry));
+}
+
 enum ovl_path_type ovl_path_type(struct dentry *dentry);
 void ovl_path_upper(struct dentry *dentry, struct path *path);
 void ovl_path_lower(struct dentry *dentry, struct path *path);
diff --git a/fs/overlayfs/params.c b/fs/overlayfs/params.c
index f42488c01957..2b9b31524c38 100644
--- a/fs/overlayfs/params.c
+++ b/fs/overlayfs/params.c
@@ -282,13 +282,11 @@ static int ovl_mount_dir_check(struct fs_context *fc, const struct path *path,
 		return invalfc(fc, "%s is not a directory", name);
 
 	/*
-	 * Root dentries of case-insensitive capable filesystems might
-	 * not have the dentry operations set, but still be incompatible
-	 * with overlayfs.  Check explicitly to prevent post-mount
-	 * failures.
+	 * Allow filesystems that are case-folding capable but deny composing
+	 * ovl stack from case-folded directories.
 	 */
-	if (sb_has_encoding(path->mnt->mnt_sb))
-		return invalfc(fc, "case-insensitive capable filesystem on %s not supported", name);
+	if (ovl_dentry_casefolded(path->dentry))
+		return invalfc(fc, "case-insensitive directory on %s not supported", name);
 
 	if (ovl_dentry_weird(path->dentry))
 		return invalfc(fc, "filesystem on %s not supported", name);
diff --git a/fs/overlayfs/util.c b/fs/overlayfs/util.c
index dcccb4b4a66c..593c4da107d6 100644
--- a/fs/overlayfs/util.c
+++ b/fs/overlayfs/util.c
@@ -206,10 +206,17 @@ bool ovl_dentry_weird(struct dentry *dentry)
 	if (!d_can_lookup(dentry) && !d_is_file(dentry) && !d_is_symlink(dentry))
 		return true;
 
-	return dentry->d_flags & (DCACHE_NEED_AUTOMOUNT |
-				  DCACHE_MANAGE_TRANSIT |
-				  DCACHE_OP_HASH |
-				  DCACHE_OP_COMPARE);
+	if (dentry->d_flags & (DCACHE_NEED_AUTOMOUNT | DCACHE_MANAGE_TRANSIT))
+		return true;
+
+	/*
+	 * Allow filesystems that are case-folding capable but deny composing
+	 * ovl stack from case-folded directories.
+	 */
+	if (sb_has_encoding(dentry->d_sb))
+		return IS_CASEFOLDED(d_inode(dentry));
+
+	return dentry->d_flags & (DCACHE_OP_HASH | DCACHE_OP_COMPARE);
 }
 
 enum ovl_path_type ovl_path_type(struct dentry *dentry)
-- 
2.34.1

Re: [PATCH v3] ovl: support layers on case-folding capable filesystems

[Kent Overstreet]

On Mon, Jun 02, 2025 at 07:17:02PM +0200, Amir Goldstein wrote:
> Case folding is often applied to subtrees and not on an entire
> filesystem.
> 
> Disallowing layers from filesystems that support case folding is over
> limiting.
> 
> Replace the rule that case-folding capable are not allowed as layers
> with a rule that case folded directories are not allowed in a merged
> directory stack.
> 
> Should case folding be enabled on an underlying directory while
> overlayfs is mounted the outcome is generally undefined.
> 
> Specifically in ovl_lookup(), we check the base underlying directory
> and fail with -ESTALE and write a warning to kmsg if an underlying
> directory case folding is enabled.
> 
> Suggested-by: Kent Overstreet <kent.overstreet@linux.dev>
> Link: https://lore.kernel.org/linux-fsdevel/20250520051600.1903319-1-kent.overstreet@linux.dev/
> Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> ---
> 
> Miklos,
> 
> This is my solution to Kent's request to allow overlayfs mount on
> bcachefs subtrees that do not have casefolding enabled, while other
> subtrees do have casefolding enabled.
> 
> I have written a test to cover the change of behavior [1].
> This test does not run on old kernel's where the mount always fails
> with casefold capable layers.
> 
> Let me know what you think.
> 
> Kent,
> 
> I have tested this on ext4.
> Please test on bcachefs.

This one fails with the proper error message in dmesg, and no other
errors :)

Reviewed-by: Kent Overstreet <kent.overstreet@linux.dev>

> 
> Thanks,
> Amir.
> 
> Changes since v1,v2:
> - Add ratelimited warnings for the lookup error cases
> - Add helper ovl_dentry_casefolded()
> - Write fstest [1]
> 
> [1] https://github.com/amir73il/xfstests/commits/ovl-casefold/
> 
>  fs/overlayfs/namei.c     | 31 ++++++++++++++++++++++++++++---
>  fs/overlayfs/overlayfs.h |  6 ++++++
>  fs/overlayfs/params.c    | 10 ++++------
>  fs/overlayfs/util.c      | 15 +++++++++++----
>  4 files changed, 49 insertions(+), 13 deletions(-)
> 
> diff --git a/fs/overlayfs/namei.c b/fs/overlayfs/namei.c
> index d489e80feb6f..733beef7b810 100644
> --- a/fs/overlayfs/namei.c
> +++ b/fs/overlayfs/namei.c
> @@ -230,13 +230,26 @@ static int ovl_lookup_single(struct dentry *base, struct ovl_lookup_data *d,
>  			     struct dentry **ret, bool drop_negative)
>  {
>  	struct ovl_fs *ofs = OVL_FS(d->sb);
> -	struct dentry *this;
> +	struct dentry *this = NULL;
> +	const char *warn;
>  	struct path path;
>  	int err;
>  	bool last_element = !post[0];
>  	bool is_upper = d->layer->idx == 0;
>  	char val;
>  
> +	/*
> +	 * We allow filesystems that are case-folding capable but deny composing
> +	 * ovl stack from case-folded directories. If someone has enabled case
> +	 * folding on a directory on underlying layer, the warranty of the ovl
> +	 * stack is voided.
> +	 */
> +	if (ovl_dentry_casefolded(base)) {
> +		warn = "case folded parent";
> +		err = -ESTALE;
> +		goto out_warn;
> +	}
> +
>  	this = ovl_lookup_positive_unlocked(d, name, base, namelen, drop_negative);
>  	if (IS_ERR(this)) {
>  		err = PTR_ERR(this);
> @@ -246,10 +259,17 @@ static int ovl_lookup_single(struct dentry *base, struct ovl_lookup_data *d,
>  		goto out_err;
>  	}
>  
> +	if (ovl_dentry_casefolded(this)) {
> +		warn = "case folded child";
> +		err = -EREMOTE;
> +		goto out_warn;
> +	}
> +
>  	if (ovl_dentry_weird(this)) {
>  		/* Don't support traversing automounts and other weirdness */
> +		warn = "unsupported object type";
>  		err = -EREMOTE;
> -		goto out_err;
> +		goto out_warn;
>  	}
>  
>  	path.dentry = this;
> @@ -283,8 +303,9 @@ static int ovl_lookup_single(struct dentry *base, struct ovl_lookup_data *d,
>  	} else {
>  		if (ovl_lookup_trap_inode(d->sb, this)) {
>  			/* Caught in a trap of overlapping layers */
> +			warn = "overlapping layers";
>  			err = -ELOOP;
> -			goto out_err;
> +			goto out_warn;
>  		}
>  
>  		if (last_element)
> @@ -316,6 +337,10 @@ static int ovl_lookup_single(struct dentry *base, struct ovl_lookup_data *d,
>  	this = NULL;
>  	goto out;
>  
> +out_warn:
> +	pr_warn_ratelimited("failed lookup in %s (%pd2, name='%.*s', err=%i): %s\n",
> +			    is_upper ? "upper" : "lower", base,
> +			    namelen, name, err, warn);
>  out_err:
>  	dput(this);
>  	return err;
> diff --git a/fs/overlayfs/overlayfs.h b/fs/overlayfs/overlayfs.h
> index aef942a758ce..6c51103d9305 100644
> --- a/fs/overlayfs/overlayfs.h
> +++ b/fs/overlayfs/overlayfs.h
> @@ -446,6 +446,12 @@ void ovl_dentry_init_reval(struct dentry *dentry, struct dentry *upperdentry,
>  void ovl_dentry_init_flags(struct dentry *dentry, struct dentry *upperdentry,
>  			   struct ovl_entry *oe, unsigned int mask);
>  bool ovl_dentry_weird(struct dentry *dentry);
> +
> +static inline bool ovl_dentry_casefolded(struct dentry *dentry)
> +{
> +	return sb_has_encoding(dentry->d_sb) && IS_CASEFOLDED(d_inode(dentry));
> +}
> +
>  enum ovl_path_type ovl_path_type(struct dentry *dentry);
>  void ovl_path_upper(struct dentry *dentry, struct path *path);
>  void ovl_path_lower(struct dentry *dentry, struct path *path);
> diff --git a/fs/overlayfs/params.c b/fs/overlayfs/params.c
> index f42488c01957..2b9b31524c38 100644
> --- a/fs/overlayfs/params.c
> +++ b/fs/overlayfs/params.c
> @@ -282,13 +282,11 @@ static int ovl_mount_dir_check(struct fs_context *fc, const struct path *path,
>  		return invalfc(fc, "%s is not a directory", name);
>  
>  	/*
> -	 * Root dentries of case-insensitive capable filesystems might
> -	 * not have the dentry operations set, but still be incompatible
> -	 * with overlayfs.  Check explicitly to prevent post-mount
> -	 * failures.
> +	 * Allow filesystems that are case-folding capable but deny composing
> +	 * ovl stack from case-folded directories.
>  	 */
> -	if (sb_has_encoding(path->mnt->mnt_sb))
> -		return invalfc(fc, "case-insensitive capable filesystem on %s not supported", name);
> +	if (ovl_dentry_casefolded(path->dentry))
> +		return invalfc(fc, "case-insensitive directory on %s not supported", name);
>  
>  	if (ovl_dentry_weird(path->dentry))
>  		return invalfc(fc, "filesystem on %s not supported", name);
> diff --git a/fs/overlayfs/util.c b/fs/overlayfs/util.c
> index dcccb4b4a66c..593c4da107d6 100644
> --- a/fs/overlayfs/util.c
> +++ b/fs/overlayfs/util.c
> @@ -206,10 +206,17 @@ bool ovl_dentry_weird(struct dentry *dentry)
>  	if (!d_can_lookup(dentry) && !d_is_file(dentry) && !d_is_symlink(dentry))
>  		return true;
>  
> -	return dentry->d_flags & (DCACHE_NEED_AUTOMOUNT |
> -				  DCACHE_MANAGE_TRANSIT |
> -				  DCACHE_OP_HASH |
> -				  DCACHE_OP_COMPARE);
> +	if (dentry->d_flags & (DCACHE_NEED_AUTOMOUNT | DCACHE_MANAGE_TRANSIT))
> +		return true;
> +
> +	/*
> +	 * Allow filesystems that are case-folding capable but deny composing
> +	 * ovl stack from case-folded directories.
> +	 */
> +	if (sb_has_encoding(dentry->d_sb))
> +		return IS_CASEFOLDED(d_inode(dentry));
> +
> +	return dentry->d_flags & (DCACHE_OP_HASH | DCACHE_OP_COMPARE);
>  }
>  
>  enum ovl_path_type ovl_path_type(struct dentry *dentry)
> -- 
> 2.34.1
> 

Re: [PATCH v3] ovl: support layers on case-folding capable filesystems

[Kent Overstreet]

On Mon, Jun 02, 2025 at 07:17:02PM +0200, Amir Goldstein wrote:
> Case folding is often applied to subtrees and not on an entire
> filesystem.
> 
> Disallowing layers from filesystems that support case folding is over
> limiting.
> 
> Replace the rule that case-folding capable are not allowed as layers
> with a rule that case folded directories are not allowed in a merged
> directory stack.
> 
> Should case folding be enabled on an underlying directory while
> overlayfs is mounted the outcome is generally undefined.
> 
> Specifically in ovl_lookup(), we check the base underlying directory
> and fail with -ESTALE and write a warning to kmsg if an underlying
> directory case folding is enabled.
> 
> Suggested-by: Kent Overstreet <kent.overstreet@linux.dev>
> Link: https://lore.kernel.org/linux-fsdevel/20250520051600.1903319-1-kent.overstreet@linux.dev/
> Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> ---
> 
> Miklos,
> 
> This is my solution to Kent's request to allow overlayfs mount on
> bcachefs subtrees that do not have casefolding enabled, while other
> subtrees do have casefolding enabled.
> 
> I have written a test to cover the change of behavior [1].
> This test does not run on old kernel's where the mount always fails
> with casefold capable layers.
> 
> Let me know what you think.
> 
> Kent,
> 
> I have tested this on ext4.
> Please test on bcachefs.

Where are we at with getting this in? I've got users who keep asking, so
hoping we can get it backported to 6.15

Re: [PATCH v3] ovl: support layers on case-folding capable filesystems

[Amir Goldstein]

On Sun, Jun 15, 2025 at 9:20 PM Kent Overstreet
<kent.overstreet@linux.dev> wrote:
>
> On Mon, Jun 02, 2025 at 07:17:02PM +0200, Amir Goldstein wrote:
> > Case folding is often applied to subtrees and not on an entire
> > filesystem.
> >
> > Disallowing layers from filesystems that support case folding is over
> > limiting.
> >
> > Replace the rule that case-folding capable are not allowed as layers
> > with a rule that case folded directories are not allowed in a merged
> > directory stack.
> >
> > Should case folding be enabled on an underlying directory while
> > overlayfs is mounted the outcome is generally undefined.
> >
> > Specifically in ovl_lookup(), we check the base underlying directory
> > and fail with -ESTALE and write a warning to kmsg if an underlying
> > directory case folding is enabled.
> >
> > Suggested-by: Kent Overstreet <kent.overstreet@linux.dev>
> > Link: https://lore.kernel.org/linux-fsdevel/20250520051600.1903319-1-kent.overstreet@linux.dev/
> > Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> > ---
> >
> > Miklos,
> >
> > This is my solution to Kent's request to allow overlayfs mount on
> > bcachefs subtrees that do not have casefolding enabled, while other
> > subtrees do have casefolding enabled.
> >
> > I have written a test to cover the change of behavior [1].
> > This test does not run on old kernel's where the mount always fails
> > with casefold capable layers.
> >
> > Let me know what you think.
> >
> > Kent,
> >
> > I have tested this on ext4.
> > Please test on bcachefs.
>
> Where are we at with getting this in? I've got users who keep asking, so
> hoping we can get it backported to 6.15

I'm planning to queue this for 6.17, but hoping to get an ACK from Miklos first.

Thanks,
Amir.

Re: [PATCH v3] ovl: support layers on case-folding capable filesystems

[Kent Overstreet]

On Mon, Jun 16, 2025 at 10:06:32AM +0200, Amir Goldstein wrote:
> On Sun, Jun 15, 2025 at 9:20 PM Kent Overstreet
> <kent.overstreet@linux.dev> wrote:
> >
> > On Mon, Jun 02, 2025 at 07:17:02PM +0200, Amir Goldstein wrote:
> > > Case folding is often applied to subtrees and not on an entire
> > > filesystem.
> > >
> > > Disallowing layers from filesystems that support case folding is over
> > > limiting.
> > >
> > > Replace the rule that case-folding capable are not allowed as layers
> > > with a rule that case folded directories are not allowed in a merged
> > > directory stack.
> > >
> > > Should case folding be enabled on an underlying directory while
> > > overlayfs is mounted the outcome is generally undefined.
> > >
> > > Specifically in ovl_lookup(), we check the base underlying directory
> > > and fail with -ESTALE and write a warning to kmsg if an underlying
> > > directory case folding is enabled.
> > >
> > > Suggested-by: Kent Overstreet <kent.overstreet@linux.dev>
> > > Link: https://lore.kernel.org/linux-fsdevel/20250520051600.1903319-1-kent.overstreet@linux.dev/
> > > Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> > > ---
> > >
> > > Miklos,
> > >
> > > This is my solution to Kent's request to allow overlayfs mount on
> > > bcachefs subtrees that do not have casefolding enabled, while other
> > > subtrees do have casefolding enabled.
> > >
> > > I have written a test to cover the change of behavior [1].
> > > This test does not run on old kernel's where the mount always fails
> > > with casefold capable layers.
> > >
> > > Let me know what you think.
> > >
> > > Kent,
> > >
> > > I have tested this on ext4.
> > > Please test on bcachefs.
> >
> > Where are we at with getting this in? I've got users who keep asking, so
> > hoping we can get it backported to 6.15
> 
> I'm planning to queue this for 6.17, but hoping to get an ACK from Miklos first.

This is a regression for bcachefs users, why isn't it being considered for
6.16?

Re: [PATCH v3] ovl: support layers on case-folding capable filesystems

[Amir Goldstein]

On Mon, Jun 16, 2025 at 2:28 PM Kent Overstreet
<kent.overstreet@linux.dev> wrote:
>
> On Mon, Jun 16, 2025 at 10:06:32AM +0200, Amir Goldstein wrote:
> > On Sun, Jun 15, 2025 at 9:20 PM Kent Overstreet
> > <kent.overstreet@linux.dev> wrote:
> > >
> > > On Mon, Jun 02, 2025 at 07:17:02PM +0200, Amir Goldstein wrote:
> > > > Case folding is often applied to subtrees and not on an entire
> > > > filesystem.
> > > >
> > > > Disallowing layers from filesystems that support case folding is over
> > > > limiting.
> > > >
> > > > Replace the rule that case-folding capable are not allowed as layers
> > > > with a rule that case folded directories are not allowed in a merged
> > > > directory stack.
> > > >
> > > > Should case folding be enabled on an underlying directory while
> > > > overlayfs is mounted the outcome is generally undefined.
> > > >
> > > > Specifically in ovl_lookup(), we check the base underlying directory
> > > > and fail with -ESTALE and write a warning to kmsg if an underlying
> > > > directory case folding is enabled.
> > > >
> > > > Suggested-by: Kent Overstreet <kent.overstreet@linux.dev>
> > > > Link: https://lore.kernel.org/linux-fsdevel/20250520051600.1903319-1-kent.overstreet@linux.dev/
> > > > Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> > > > ---
> > > >
> > > > Miklos,
> > > >
> > > > This is my solution to Kent's request to allow overlayfs mount on
> > > > bcachefs subtrees that do not have casefolding enabled, while other
> > > > subtrees do have casefolding enabled.
> > > >
> > > > I have written a test to cover the change of behavior [1].
> > > > This test does not run on old kernel's where the mount always fails
> > > > with casefold capable layers.
> > > >
> > > > Let me know what you think.
> > > >
> > > > Kent,
> > > >
> > > > I have tested this on ext4.
> > > > Please test on bcachefs.
> > >
> > > Where are we at with getting this in? I've got users who keep asking, so
> > > hoping we can get it backported to 6.15
> >
> > I'm planning to queue this for 6.17, but hoping to get an ACK from Miklos first.
>
> This is a regression for bcachefs users, why isn't it being considered for
> 6.16?

This is an ovl behavior change on fs like ext4 regardless of bcachefs.
This change of behavior, which is desired for your users, could expose other
users to other regressions.
I am not sure that it is a clear cut candidate for 6.16,
but I also don't feel very strongly this way or the other, so I will
let Miklos decide.

In any case, even if the change gets merged in 6.17, after the change
was exposed to the world for a bit and no regressions reported,
I have no objections backporting it to older kernels.

Thanks,
Amir.

Re: [PATCH v3] ovl: support layers on case-folding capable filesystems

[Kent Overstreet]

On Mon, Jun 16, 2025 at 02:36:35PM +0200, Amir Goldstein wrote:
> On Mon, Jun 16, 2025 at 2:28 PM Kent Overstreet
> <kent.overstreet@linux.dev> wrote:
> >
> > On Mon, Jun 16, 2025 at 10:06:32AM +0200, Amir Goldstein wrote:
> > > On Sun, Jun 15, 2025 at 9:20 PM Kent Overstreet
> > > <kent.overstreet@linux.dev> wrote:
> > > > Where are we at with getting this in? I've got users who keep asking, so
> > > > hoping we can get it backported to 6.15
> > >
> > > I'm planning to queue this for 6.17, but hoping to get an ACK from Miklos first.
> >
> > This is a regression for bcachefs users, why isn't it being considered for
> > 6.16?
> 
> This is an ovl behavior change on fs like ext4 regardless of bcachefs.
> This change of behavior, which is desired for your users, could expose other
> users to other regressions.

Regressions, like?

The behavioral change is only for casess that were an error before, so
we should only be concerned about regressions if we think there might be
a bug in your patch, and I think it's simple enough that we don't need
to be concerned about that.

Re: [PATCH v3] ovl: support layers on case-folding capable filesystems

[Amir Goldstein]

On Mon, Jun 16, 2025 at 2:54 PM Kent Overstreet
<kent.overstreet@linux.dev> wrote:
>
> On Mon, Jun 16, 2025 at 02:36:35PM +0200, Amir Goldstein wrote:
> > On Mon, Jun 16, 2025 at 2:28 PM Kent Overstreet
> > <kent.overstreet@linux.dev> wrote:
> > >
> > > On Mon, Jun 16, 2025 at 10:06:32AM +0200, Amir Goldstein wrote:
> > > > On Sun, Jun 15, 2025 at 9:20 PM Kent Overstreet
> > > > <kent.overstreet@linux.dev> wrote:
> > > > > Where are we at with getting this in? I've got users who keep asking, so
> > > > > hoping we can get it backported to 6.15
> > > >
> > > > I'm planning to queue this for 6.17, but hoping to get an ACK from Miklos first.
> > >
> > > This is a regression for bcachefs users, why isn't it being considered for
> > > 6.16?
> >
> > This is an ovl behavior change on fs like ext4 regardless of bcachefs.
> > This change of behavior, which is desired for your users, could expose other
> > users to other regressions.
>
> Regressions, like?
>
> The behavioral change is only for casess that were an error before, so
> we should only be concerned about regressions if we think there might be
> a bug in your patch,

Exactly my concern.
Before the change, it was not possible to have a casefolded dentry
in the overlay stack.
Now it is very much possible.
We detect it and report an error in some lookup cases, but not in all of them.
For example in ovl_lower_positive().
Does it matter? Can it cause harm? I hope not, but not sure.

> and I think it's simple enough that we don't need to be concerned about that.

Yes. famous last words.
I will let Miklos be the judge of that.

Thanks,
Amir.

Re: [PATCH v3] ovl: support layers on case-folding capable filesystems

[Amir Goldstein]

On Mon, Jun 16, 2025 at 10:06 AM Amir Goldstein <amir73il@gmail.com> wrote:
>
> On Sun, Jun 15, 2025 at 9:20 PM Kent Overstreet
> <kent.overstreet@linux.dev> wrote:
> >
> > On Mon, Jun 02, 2025 at 07:17:02PM +0200, Amir Goldstein wrote:
> > > Case folding is often applied to subtrees and not on an entire
> > > filesystem.
> > >
> > > Disallowing layers from filesystems that support case folding is over
> > > limiting.
> > >
> > > Replace the rule that case-folding capable are not allowed as layers
> > > with a rule that case folded directories are not allowed in a merged
> > > directory stack.
> > >
> > > Should case folding be enabled on an underlying directory while
> > > overlayfs is mounted the outcome is generally undefined.
> > >
> > > Specifically in ovl_lookup(), we check the base underlying directory
> > > and fail with -ESTALE and write a warning to kmsg if an underlying
> > > directory case folding is enabled.
> > >
> > > Suggested-by: Kent Overstreet <kent.overstreet@linux.dev>
> > > Link: https://lore.kernel.org/linux-fsdevel/20250520051600.1903319-1-kent.overstreet@linux.dev/
> > > Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> > > ---
> > >
> > > Miklos,
> > >
> > > This is my solution to Kent's request to allow overlayfs mount on
> > > bcachefs subtrees that do not have casefolding enabled, while other
> > > subtrees do have casefolding enabled.
> > >
> > > I have written a test to cover the change of behavior [1].
> > > This test does not run on old kernel's where the mount always fails
> > > with casefold capable layers.
> > >
> > > Let me know what you think.
> > >
> > > Kent,
> > >
> > > I have tested this on ext4.
> > > Please test on bcachefs.
> >
> > Where are we at with getting this in? I've got users who keep asking, so
> > hoping we can get it backported to 6.15
>
> I'm planning to queue this for 6.17, but hoping to get an ACK from Miklos first.
>

Hi Christian,

I would like to let this change soak in next for 6.17.
I can push to overlayfs-next, but since you have some changes on vfs.file,
I wanted to consult with you first.

The changes are independent so they could go through different trees,
but I don't like that so much, so I propose a few options.

1. make vfs.file a stable branch, so I can base overlayfs-next on it
2. rename to vfs.backing_file and make stable
3. take this single ovl patch via your tree, as I don't currently have
    any other ovl patches queued to 6.17

Let me know which is your preferred option.

Thanks,
Amir.

Re: [PATCH v3] ovl: support layers on case-folding capable filesystems

[Amir Goldstein]

On Sun, Jun 22, 2025 at 9:20 AM Amir Goldstein <amir73il@gmail.com> wrote:
>
> On Mon, Jun 16, 2025 at 10:06 AM Amir Goldstein <amir73il@gmail.com> wrote:
> >
> > On Sun, Jun 15, 2025 at 9:20 PM Kent Overstreet
> > <kent.overstreet@linux.dev> wrote:
> > >
> > > On Mon, Jun 02, 2025 at 07:17:02PM +0200, Amir Goldstein wrote:
> > > > Case folding is often applied to subtrees and not on an entire
> > > > filesystem.
> > > >
> > > > Disallowing layers from filesystems that support case folding is over
> > > > limiting.
> > > >
> > > > Replace the rule that case-folding capable are not allowed as layers
> > > > with a rule that case folded directories are not allowed in a merged
> > > > directory stack.
> > > >
> > > > Should case folding be enabled on an underlying directory while
> > > > overlayfs is mounted the outcome is generally undefined.
> > > >
> > > > Specifically in ovl_lookup(), we check the base underlying directory
> > > > and fail with -ESTALE and write a warning to kmsg if an underlying
> > > > directory case folding is enabled.
> > > >
> > > > Suggested-by: Kent Overstreet <kent.overstreet@linux.dev>
> > > > Link: https://lore.kernel.org/linux-fsdevel/20250520051600.1903319-1-kent.overstreet@linux.dev/
> > > > Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> > > > ---
> > > >
> > > > Miklos,
> > > >
> > > > This is my solution to Kent's request to allow overlayfs mount on
> > > > bcachefs subtrees that do not have casefolding enabled, while other
> > > > subtrees do have casefolding enabled.
> > > >
> > > > I have written a test to cover the change of behavior [1].
> > > > This test does not run on old kernel's where the mount always fails
> > > > with casefold capable layers.
> > > >
> > > > Let me know what you think.
> > > >
> > > > Kent,
> > > >
> > > > I have tested this on ext4.
> > > > Please test on bcachefs.
> > >
> > > Where are we at with getting this in? I've got users who keep asking, so
> > > hoping we can get it backported to 6.15
> >
> > I'm planning to queue this for 6.17, but hoping to get an ACK from Miklos first.
> >
>
> Hi Christian,
>
> I would like to let this change soak in next for 6.17.
> I can push to overlayfs-next, but since you have some changes on vfs.file,
> I wanted to consult with you first.
>
> The changes are independent so they could go through different trees,
> but I don't like that so much, so I propose a few options.
>
> 1. make vfs.file a stable branch, so I can base overlayfs-next on it

Sorry, I meant make vfs-6.17.file stable branch

> 2. rename to vfs.backing_file and make stable
> 3. take this single ovl patch via your tree, as I don't currently have
>     any other ovl patches queued to 6.17
>
> Let me know which is your preferred option.
>
> Thanks,
> Amir.

Re: [PATCH v3] ovl: support layers on case-folding capable filesystems

[Christian Brauner]

On Sun, Jun 22, 2025 at 09:20:24AM +0200, Amir Goldstein wrote:
> On Mon, Jun 16, 2025 at 10:06 AM Amir Goldstein <amir73il@gmail.com> wrote:
> >
> > On Sun, Jun 15, 2025 at 9:20 PM Kent Overstreet
> > <kent.overstreet@linux.dev> wrote:
> > >
> > > On Mon, Jun 02, 2025 at 07:17:02PM +0200, Amir Goldstein wrote:
> > > > Case folding is often applied to subtrees and not on an entire
> > > > filesystem.
> > > >
> > > > Disallowing layers from filesystems that support case folding is over
> > > > limiting.
> > > >
> > > > Replace the rule that case-folding capable are not allowed as layers
> > > > with a rule that case folded directories are not allowed in a merged
> > > > directory stack.
> > > >
> > > > Should case folding be enabled on an underlying directory while
> > > > overlayfs is mounted the outcome is generally undefined.
> > > >
> > > > Specifically in ovl_lookup(), we check the base underlying directory
> > > > and fail with -ESTALE and write a warning to kmsg if an underlying
> > > > directory case folding is enabled.
> > > >
> > > > Suggested-by: Kent Overstreet <kent.overstreet@linux.dev>
> > > > Link: https://lore.kernel.org/linux-fsdevel/20250520051600.1903319-1-kent.overstreet@linux.dev/
> > > > Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> > > > ---
> > > >
> > > > Miklos,
> > > >
> > > > This is my solution to Kent's request to allow overlayfs mount on
> > > > bcachefs subtrees that do not have casefolding enabled, while other
> > > > subtrees do have casefolding enabled.
> > > >
> > > > I have written a test to cover the change of behavior [1].
> > > > This test does not run on old kernel's where the mount always fails
> > > > with casefold capable layers.
> > > >
> > > > Let me know what you think.
> > > >
> > > > Kent,
> > > >
> > > > I have tested this on ext4.
> > > > Please test on bcachefs.
> > >
> > > Where are we at with getting this in? I've got users who keep asking, so
> > > hoping we can get it backported to 6.15
> >
> > I'm planning to queue this for 6.17, but hoping to get an ACK from Miklos first.
> >
> 
> Hi Christian,
> 
> I would like to let this change soak in next for 6.17.
> I can push to overlayfs-next, but since you have some changes on vfs.file,
> I wanted to consult with you first.
> 
> The changes are independent so they could go through different trees,
> but I don't like that so much, so I propose a few options.
> 
> 1. make vfs.file a stable branch, so I can base overlayfs-next on it
> 2. rename to vfs.backing_file and make stable
> 3. take this single ovl patch via your tree, as I don't currently have
>     any other ovl patches queued to 6.17

Let's start with 3. and switch to a stable branch on demand?

Re: [PATCH v3] ovl: support layers on case-folding capable filesystems

[Christian Brauner]

On Mon, 02 Jun 2025 19:17:02 +0200, Amir Goldstein wrote:
> Case folding is often applied to subtrees and not on an entire
> filesystem.
> 
> Disallowing layers from filesystems that support case folding is over
> limiting.
> 
> Replace the rule that case-folding capable are not allowed as layers
> with a rule that case folded directories are not allowed in a merged
> directory stack.
> 
> [...]

Applied to the vfs-6.17.file branch of the vfs/vfs.git tree.
Patches in the vfs-6.17.file branch should appear in linux-next soon.

Please report any outstanding bugs that were missed during review in a
new review to the original patch series allowing us to drop it.

It's encouraged to provide Acked-bys and Reviewed-bys even though the
patch has now been applied. If possible patch trailers will be updated.

Note that commit hashes shown below are subject to change due to rebase,
trailer updates or similar. If in doubt, please check the listed branch.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git
branch: vfs-6.17.file

[1/1] ovl: support layers on case-folding capable filesystems
      https://git.kernel.org/vfs/vfs/c/5810e7558fda

Re: [PATCH v3] ovl: support layers on case-folding capable filesystems

[Amir Goldstein]

On Mon, Jun 23, 2025 at 12:26 PM Christian Brauner <brauner@kernel.org> wrote:
>
> On Sun, Jun 22, 2025 at 09:20:24AM +0200, Amir Goldstein wrote:
> > On Mon, Jun 16, 2025 at 10:06 AM Amir Goldstein <amir73il@gmail.com> wrote:
> > >
> > > On Sun, Jun 15, 2025 at 9:20 PM Kent Overstreet
> > > <kent.overstreet@linux.dev> wrote:
> > > >
> > > > On Mon, Jun 02, 2025 at 07:17:02PM +0200, Amir Goldstein wrote:
> > > > > Case folding is often applied to subtrees and not on an entire
> > > > > filesystem.
> > > > >
> > > > > Disallowing layers from filesystems that support case folding is over
> > > > > limiting.
> > > > >
> > > > > Replace the rule that case-folding capable are not allowed as layers
> > > > > with a rule that case folded directories are not allowed in a merged
> > > > > directory stack.
> > > > >
> > > > > Should case folding be enabled on an underlying directory while
> > > > > overlayfs is mounted the outcome is generally undefined.
> > > > >
> > > > > Specifically in ovl_lookup(), we check the base underlying directory
> > > > > and fail with -ESTALE and write a warning to kmsg if an underlying
> > > > > directory case folding is enabled.
> > > > >
> > > > > Suggested-by: Kent Overstreet <kent.overstreet@linux.dev>
> > > > > Link: https://lore.kernel.org/linux-fsdevel/20250520051600.1903319-1-kent.overstreet@linux.dev/
> > > > > Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> > > > > ---
> > > > >
> > > > > Miklos,
> > > > >
> > > > > This is my solution to Kent's request to allow overlayfs mount on
> > > > > bcachefs subtrees that do not have casefolding enabled, while other
> > > > > subtrees do have casefolding enabled.
> > > > >
> > > > > I have written a test to cover the change of behavior [1].
> > > > > This test does not run on old kernel's where the mount always fails
> > > > > with casefold capable layers.
> > > > >
> > > > > Let me know what you think.
> > > > >
> > > > > Kent,
> > > > >
> > > > > I have tested this on ext4.
> > > > > Please test on bcachefs.
> > > >
> > > > Where are we at with getting this in? I've got users who keep asking, so
> > > > hoping we can get it backported to 6.15
> > >
> > > I'm planning to queue this for 6.17, but hoping to get an ACK from Miklos first.
> > >
> >
> > Hi Christian,
> >
> > I would like to let this change soak in next for 6.17.
> > I can push to overlayfs-next, but since you have some changes on vfs.file,
> > I wanted to consult with you first.
> >
> > The changes are independent so they could go through different trees,
> > but I don't like that so much, so I propose a few options.
> >
> > 1. make vfs.file a stable branch, so I can base overlayfs-next on it
> > 2. rename to vfs.backing_file and make stable
> > 3. take this single ovl patch via your tree, as I don't currently have
> >     any other ovl patches queued to 6.17
>
> Let's start with 3. and switch to a stable branch on demand?

works for me

Thanks,
Amir.

Re: [PATCH v3] ovl: support layers on case-folding capable filesystems

[Kent Overstreet]

On Sun, Jun 22, 2025 at 09:20:24AM +0200, Amir Goldstein wrote:
> On Mon, Jun 16, 2025 at 10:06 AM Amir Goldstein <amir73il@gmail.com> wrote:
> >
> > On Sun, Jun 15, 2025 at 9:20 PM Kent Overstreet
> > <kent.overstreet@linux.dev> wrote:
> > >
> > > On Mon, Jun 02, 2025 at 07:17:02PM +0200, Amir Goldstein wrote:
> > > > Case folding is often applied to subtrees and not on an entire
> > > > filesystem.
> > > >
> > > > Disallowing layers from filesystems that support case folding is over
> > > > limiting.
> > > >
> > > > Replace the rule that case-folding capable are not allowed as layers
> > > > with a rule that case folded directories are not allowed in a merged
> > > > directory stack.
> > > >
> > > > Should case folding be enabled on an underlying directory while
> > > > overlayfs is mounted the outcome is generally undefined.
> > > >
> > > > Specifically in ovl_lookup(), we check the base underlying directory
> > > > and fail with -ESTALE and write a warning to kmsg if an underlying
> > > > directory case folding is enabled.
> > > >
> > > > Suggested-by: Kent Overstreet <kent.overstreet@linux.dev>
> > > > Link: https://lore.kernel.org/linux-fsdevel/20250520051600.1903319-1-kent.overstreet@linux.dev/
> > > > Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> > > > ---
> > > >
> > > > Miklos,
> > > >
> > > > This is my solution to Kent's request to allow overlayfs mount on
> > > > bcachefs subtrees that do not have casefolding enabled, while other
> > > > subtrees do have casefolding enabled.
> > > >
> > > > I have written a test to cover the change of behavior [1].
> > > > This test does not run on old kernel's where the mount always fails
> > > > with casefold capable layers.
> > > >
> > > > Let me know what you think.
> > > >
> > > > Kent,
> > > >
> > > > I have tested this on ext4.
> > > > Please test on bcachefs.
> > >
> > > Where are we at with getting this in? I've got users who keep asking, so
> > > hoping we can get it backported to 6.15
> >
> > I'm planning to queue this for 6.17, but hoping to get an ACK from Miklos first.
> >
> 
> Hi Christian,
> 
> I would like to let this change soak in next for 6.17.
> I can push to overlayfs-next, but since you have some changes on vfs.file,
> I wanted to consult with you first.
> 
> The changes are independent so they could go through different trees,
> but I don't like that so much, so I propose a few options.
> 
> 1. make vfs.file a stable branch, so I can base overlayfs-next on it
> 2. rename to vfs.backing_file and make stable
> 3. take this single ovl patch via your tree, as I don't currently have
>     any other ovl patches queued to 6.17

I've got more users hitting the casefolding + overlayfs issue.

If we made the new behaviour bcachefs only, would that make it work for
you to get it into 6.16 + 6.15 backport?

Otherwise I'm going to have to get my own workaround out...

Re: [PATCH v3] ovl: support layers on case-folding capable filesystems

[Amir Goldstein]

On Thu, Jun 26, 2025 at 3:37 PM Kent Overstreet
<kent.overstreet@linux.dev> wrote:
>
> On Sun, Jun 22, 2025 at 09:20:24AM +0200, Amir Goldstein wrote:
> > On Mon, Jun 16, 2025 at 10:06 AM Amir Goldstein <amir73il@gmail.com> wrote:
> > >
> > > On Sun, Jun 15, 2025 at 9:20 PM Kent Overstreet
> > > <kent.overstreet@linux.dev> wrote:
> > > >
> > > > On Mon, Jun 02, 2025 at 07:17:02PM +0200, Amir Goldstein wrote:
> > > > > Case folding is often applied to subtrees and not on an entire
> > > > > filesystem.
> > > > >
> > > > > Disallowing layers from filesystems that support case folding is over
> > > > > limiting.
> > > > >
> > > > > Replace the rule that case-folding capable are not allowed as layers
> > > > > with a rule that case folded directories are not allowed in a merged
> > > > > directory stack.
> > > > >
> > > > > Should case folding be enabled on an underlying directory while
> > > > > overlayfs is mounted the outcome is generally undefined.
> > > > >
> > > > > Specifically in ovl_lookup(), we check the base underlying directory
> > > > > and fail with -ESTALE and write a warning to kmsg if an underlying
> > > > > directory case folding is enabled.
> > > > >
> > > > > Suggested-by: Kent Overstreet <kent.overstreet@linux.dev>
> > > > > Link: https://lore.kernel.org/linux-fsdevel/20250520051600.1903319-1-kent.overstreet@linux.dev/
> > > > > Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> > > > > ---
> > > > >
> > > > > Miklos,
> > > > >
> > > > > This is my solution to Kent's request to allow overlayfs mount on
> > > > > bcachefs subtrees that do not have casefolding enabled, while other
> > > > > subtrees do have casefolding enabled.
> > > > >
> > > > > I have written a test to cover the change of behavior [1].
> > > > > This test does not run on old kernel's where the mount always fails
> > > > > with casefold capable layers.
> > > > >
> > > > > Let me know what you think.
> > > > >
> > > > > Kent,
> > > > >
> > > > > I have tested this on ext4.
> > > > > Please test on bcachefs.
> > > >
> > > > Where are we at with getting this in? I've got users who keep asking, so
> > > > hoping we can get it backported to 6.15
> > >
> > > I'm planning to queue this for 6.17, but hoping to get an ACK from Miklos first.
> > >
> >
> > Hi Christian,
> >
> > I would like to let this change soak in next for 6.17.
> > I can push to overlayfs-next, but since you have some changes on vfs.file,
> > I wanted to consult with you first.
> >
> > The changes are independent so they could go through different trees,
> > but I don't like that so much, so I propose a few options.
> >
> > 1. make vfs.file a stable branch, so I can base overlayfs-next on it
> > 2. rename to vfs.backing_file and make stable
> > 3. take this single ovl patch via your tree, as I don't currently have
> >     any other ovl patches queued to 6.17
>
> I've got more users hitting the casefolding + overlayfs issue.
>
> If we made the new behaviour bcachefs only, would that make it work for
> you to get it into 6.16 + 6.15 backport?

Sorry, overlayfs is not going to special case bcachefs.

The patch is queued for 6.17 in Christian's tree
and is still waiting for an ACK from Miklos.

>
> Otherwise I'm going to have to get my own workaround out...

Not sure which workaround that is, but if it's in bcachefs then it's up to you.

Thanks,
Amir.

Re: [PATCH v3] ovl: support layers on case-folding capable filesystems

[Miklos Szeredi]

On Mon, 2 Jun 2025 at 19:17, Amir Goldstein <amir73il@gmail.com> wrote:
>
> Case folding is often applied to subtrees and not on an entire
> filesystem.
>
> Disallowing layers from filesystems that support case folding is over
> limiting.
>
> Replace the rule that case-folding capable are not allowed as layers
> with a rule that case folded directories are not allowed in a merged
> directory stack.
>
> Should case folding be enabled on an underlying directory while
> overlayfs is mounted the outcome is generally undefined.
>
> Specifically in ovl_lookup(), we check the base underlying directory
> and fail with -ESTALE and write a warning to kmsg if an underlying
> directory case folding is enabled.
>
> Suggested-by: Kent Overstreet <kent.overstreet@linux.dev>
> Link: https://lore.kernel.org/linux-fsdevel/20250520051600.1903319-1-kent.overstreet@linux.dev/
> Signed-off-by: Amir Goldstein <amir73il@gmail.com>

Acked-by: Miklos Szeredi <mszeredi@redhat.com>

Looks good.  Thanks for taking care of this.

The only think I don't like is the pr_warn_ratelimited().  I totally
understand why you did it, and I'd love to have generic infrastructure
for returning extra error info without spamming dmesg.   Oh well.

Thanks,
Miklos