linux-kernel - Re: [PATCH 0/2] Fix two regressions from start_creating()/start

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOQ4uxjp_Rgz7guv0wR6Bg40JuCiZP1L49wt_iUVnWqJjE2DLQ@mail.gmail.com>
Date: Sat, 27 Dec 2025 19:15:18 +0100
From: Amir Goldstein <amir73il@...il.com>
To: NeilBrown <neil@...wn.name>
Cc: Tyler Hicks <code@...icks.com>, Christian Brauner <brauner@...nel.org>, 
	Jeff Layton <jlayton@...nel.org>, ecryptfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] Fix two regressions from start_creating()/start_removing()
 conversion

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