Re: [PATCH 0/2] Fix two regressions from start_creating()/start_removing() conversion

[Tyler Hicks <code@tyhicks.com>]

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.