When running the eCryptfs test suite on v6.19-rc2, I noticed BUG splats
from every test and that the umount utility was segfaulting when tearing
down after a test. Bisection led me to commit f046fbb4d81d ("ecryptfs:
use new start_creating/start_removing APIs").

This patch series addresses that regression and also a mknod problem
spotted during code review.

Tyler

Tyler Hicks (2):
  ecryptfs: Fix improper mknod pairing of
    start_creating()/end_removing()
  ecryptfs: Release lower parent dentry after creating dir

 fs/ecryptfs/inode.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)


base-commit: 9448598b22c50c8a5bb77a9103e2d49f134c9578
-- 
2.43.0

On Wed, 24 Dec 2025, Tyler Hicks wrote:
> When running the eCryptfs test suite on v6.19-rc2, I noticed BUG splats
> from every test and that the umount utility was segfaulting when tearing
> down after a test. Bisection led me to commit f046fbb4d81d ("ecryptfs:
> use new start_creating/start_removing APIs").
> 
> This patch series addresses that regression and also a mknod problem
> spotted during code review.
> 
> Tyler
> 
> Tyler Hicks (2):
>   ecryptfs: Fix improper mknod pairing of
>     start_creating()/end_removing()
>   ecryptfs: Release lower parent dentry after creating dir
> 
>  fs/ecryptfs/inode.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Thanks for finding and fixing these.
both
  Reviewed-by: NeilBrown <neil@brown.name>

I note that in https://lore.kernel.org/all/ZCuSLNnFQEdOHW0c@sequoia/ you
said of ecryptfs:

    I'll send a patch to deprecate and mark for removal in 2025.

Did it ever get marked for removal?  Is there a chance that it might be
removed?

Thanks,
NeilBrown

On Sat, Dec 27, 2025 at 3:06 AM NeilBrown <neilb@ownmail.net> wrote:
>
> On Wed, 24 Dec 2025, Tyler Hicks wrote:
> > When running the eCryptfs test suite on v6.19-rc2, I noticed BUG splats
> > from every test and that the umount utility was segfaulting when tearing
> > down after a test. Bisection led me to commit f046fbb4d81d ("ecryptfs:
> > use new start_creating/start_removing APIs").
> >
> > This patch series addresses that regression and also a mknod problem
> > spotted during code review.
> >
> > Tyler
> >
> > Tyler Hicks (2):
> >   ecryptfs: Fix improper mknod pairing of
> >     start_creating()/end_removing()
> >   ecryptfs: Release lower parent dentry after creating dir
> >
> >  fs/ecryptfs/inode.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
>
> Thanks for finding and fixing these.
> both
>   Reviewed-by: NeilBrown <neil@brown.name>
>
> I note that in https://lore.kernel.org/all/ZCuSLNnFQEdOHW0c@sequoia/ you
> said of ecryptfs:
>
>     I'll send a patch to deprecate and mark for removal in 2025.
>
> Did it ever get marked for removal?  Is there a chance that it might be
> removed?

If it does get removed I wonder how I and other users would access my
ecryptfs folders?

It sounds to me like the road to deprecation should go through creating
a FUSE alternative in ecryptfs-utils, before the kernel driver is deprecated.

Tyler, are there any problems with doing that?
I could give it a shot if I have your blessing.

Thanks,
Amir.

On 2025-12-27 19:15:18, Amir Goldstein wrote:
> On Sat, Dec 27, 2025 at 3:06 AM NeilBrown <neilb@ownmail.net> wrote:
> >
> > On Wed, 24 Dec 2025, Tyler Hicks wrote:
> > > When running the eCryptfs test suite on v6.19-rc2, I noticed BUG splats
> > > from every test and that the umount utility was segfaulting when tearing
> > > down after a test. Bisection led me to commit f046fbb4d81d ("ecryptfs:
> > > use new start_creating/start_removing APIs").
> > >
> > > This patch series addresses that regression and also a mknod problem
> > > spotted during code review.
> > >
> > > Tyler
> > >
> > > Tyler Hicks (2):
> > >   ecryptfs: Fix improper mknod pairing of
> > >     start_creating()/end_removing()
> > >   ecryptfs: Release lower parent dentry after creating dir
> > >
> > >  fs/ecryptfs/inode.c | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > Thanks for finding and fixing these.
> > both
> >   Reviewed-by: NeilBrown <neil@brown.name>
> >
> > I note that in https://lore.kernel.org/all/ZCuSLNnFQEdOHW0c@sequoia/ you
> > said of ecryptfs:
> >
> >     I'll send a patch to deprecate and mark for removal in 2025.
> >
> > Did it ever get marked for removal?  Is there a chance that it might be
> > removed?

I never did that, as I did hear from some folks that depend on it. Not a
lot of people but there were some.

> If it does get removed I wonder how I and other users would access my
> ecryptfs folders?

I have thought about stripping out the write abilities, after a warning
period, so that existing files could be read and migrated away but it
wouldn't grow new users.

> It sounds to me like the road to deprecation should go through creating
> a FUSE alternative in ecryptfs-utils, before the kernel driver is deprecated.
> 
> Tyler, are there any problems with doing that?
> I could give it a shot if I have your blessing.

That is a nice idea and I'd be happy if you did it! Do note that
ecryptfs-utils is even more stale than the kernel driver and hasn't seen
a release in a very long time. It is still stored in bzr instead of
git!

I'm not sure if Dustin Kirkland (cc'ed) has the bandwidth to make new
ecryptfs-utils releases to deliver a FUSE alternative but, if not, it
could be a good time to move to git and host new releases on GitHub or
maybe kernel.org.

Tyler

> 
> Thanks,
> Amir.

On Tue, 23 Dec 2025 13:41:51 -0600, Tyler Hicks wrote:
> When running the eCryptfs test suite on v6.19-rc2, I noticed BUG splats
> from every test and that the umount utility was segfaulting when tearing
> down after a test. Bisection led me to commit f046fbb4d81d ("ecryptfs:
> use new start_creating/start_removing APIs").
> 
> This patch series addresses that regression and also a mknod problem
> spotted during code review.
> 
> [...]

Applied to the vfs.fixes branch of the vfs/vfs.git tree.
Patches in the vfs.fixes 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.fixes

[1/2] ecryptfs: Fix improper mknod pairing of start_creating()/end_removing()
      https://git.kernel.org/vfs/vfs/c/5f9ad16bccd3
[2/2] ecryptfs: Release lower parent dentry after creating dir
      https://git.kernel.org/vfs/vfs/c/5c56afd204ad

On Tue, Dec 23, 2025 at 9:42 PM Tyler Hicks <code@tyhicks.com> wrote:
>
> When running the eCryptfs test suite on v6.19-rc2, I noticed BUG splats
> from every test and that the umount utility was segfaulting when tearing
> down after a test. Bisection led me to commit f046fbb4d81d ("ecryptfs:
> use new start_creating/start_removing APIs").
>
> This patch series addresses that regression and also a mknod problem
> spotted during code review.
>

Ouch!

Christian,

In retrospect, it's a shame that patches get merged with zero test coverage
and no ACK from the maintainer.

OTOH, relying on ACKs from all fs maintainers will seriously impair
the ability to make vfs wide changes like this one.

Feels like we need to find a better balance.

At least for ecryptfs, if we know that Tyler is at least testing rc1
regularly (?) that's a comfort.

Thanks,
Amir.

On 2025-12-24 07:31:59, Amir Goldstein wrote:
> On Tue, Dec 23, 2025 at 9:42 PM Tyler Hicks <code@tyhicks.com> wrote:
> >
> > When running the eCryptfs test suite on v6.19-rc2, I noticed BUG splats
> > from every test and that the umount utility was segfaulting when tearing
> > down after a test. Bisection led me to commit f046fbb4d81d ("ecryptfs:
> > use new start_creating/start_removing APIs").
> >
> > This patch series addresses that regression and also a mknod problem
> > spotted during code review.
> >
> 
> Ouch!
> 
> Christian,
> 
> In retrospect, it's a shame that patches get merged with zero test coverage
> and no ACK from the maintainer.

I wasn't able to be a very active maintainer over the last year. I think
Christian did the right thing here.

> OTOH, relying on ACKs from all fs maintainers will seriously impair
> the ability to make vfs wide changes like this one.

Exactly. The fringe filesystems shouldn't slow down the entire VFS.

> Feels like we need to find a better balance.
> 
> At least for ecryptfs, if we know that Tyler is at least testing rc1
> regularly (?) that's a comfort.

I will be more active going forward and now have an easy setup for
testing rc1's regularly.

Tyler

> 
> Thanks,
> Amir.