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

[Amir Goldstein]

On Sat, Dec 27, 2025 at 3:06 AM NeilBrown <neilb@xxxxxxxxxxx> 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@xxxxxxxxxx>
>
> 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.