From: Arnd Bergmann <arnd@arndb.de>

The ecryptfs file system uses functions from fs/buffer.c that
are only available when CONFIG_BUFFER_HEAD is enabled:

ld.lld-20: error: undefined symbol: block_dirty_folio
>>>               vmlinux.o:(ecryptfs_aops)
ld.lld-20: error: undefined symbol: block_invalidate_folio
>>>               vmlinux.o:(ecryptfs_aops)

When CONFIG_BLOCK is turned off completely, this is not needed,
so add a conditional 'select BUFFER_HEAD'.

Fixes: 7ba13abbd31e ("fs: Turn block_invalidatepage into block_invalidate_folio")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
Ideally we would not depend on buffer heads and instead remove
the dependency here, but I could not immediately figure out how
to do that.
---
 fs/ecryptfs/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/ecryptfs/Kconfig b/fs/ecryptfs/Kconfig
index 1bdeaa6d5790..b3c603c4f808 100644
--- a/fs/ecryptfs/Kconfig
+++ b/fs/ecryptfs/Kconfig
@@ -2,6 +2,7 @@
 config ECRYPT_FS
 	tristate "eCrypt filesystem layer support"
 	depends on KEYS && CRYPTO && (ENCRYPTED_KEYS || ENCRYPTED_KEYS=n)
+	select BUFFER_HEAD if BLOCK
 	select CRYPTO_ECB
 	select CRYPTO_CBC
 	select CRYPTO_MD5
-- 
2.39.5

On Mon, Oct 28, 2024 at 02:18:45PM +0000, Arnd Bergmann wrote:
> The ecryptfs file system uses functions from fs/buffer.c that
> are only available when CONFIG_BUFFER_HEAD is enabled:
> 
> ld.lld-20: error: undefined symbol: block_dirty_folio
> >>>               vmlinux.o:(ecryptfs_aops)
> ld.lld-20: error: undefined symbol: block_invalidate_folio
> >>>               vmlinux.o:(ecryptfs_aops)
> 
> When CONFIG_BLOCK is turned off completely, this is not needed,
> so add a conditional 'select BUFFER_HEAD'.

The comment says it doesn't work without CONFIG_BLOCK:

        /*
         * XXX: This is pretty broken for multiple reasons: ecryptfs does not
         * actually use buffer_heads, and ecryptfs will crash without
         * CONFIG_BLOCK.  But it matches the behavior before the default for
         * address_space_operations without the ->dirty_folio method was
         * cleaned up, so this is the best we can do without maintainer
         * feedback.

This comment has been there since June 2021, so I think we can just
delete ecryptfs now?

If we can't delete it for some reason, I think we can use
filemap_dirty_folio() and remove the setting of invalidate_folio()
as block_invalidate_folio() is a no-op if there are no folio_buffers.
ie this in lieu of your patch:

+++ b/fs/ecryptfs/mmap.c
@@ -514,17 +514,9 @@ static sector_t ecryptfs_bmap(struct address_space *mapping, sector_t block)
 
 const struct address_space_operations ecryptfs_aops = {
        /*
-        * XXX: This is pretty broken for multiple reasons: ecryptfs does not
-        * actually use buffer_heads, and ecryptfs will crash without
-        * CONFIG_BLOCK.  But it matches the behavior before the default for
-        * address_space_operations without the ->dirty_folio method was
-        * cleaned up, so this is the best we can do without maintainer
-        * feedback.
+        * XXX: This entire filesystem is unmaintained and untested.
         */
-#ifdef CONFIG_BLOCK
-       .dirty_folio    = block_dirty_folio,
-       .invalidate_folio = block_invalidate_folio,
-#endif
+       .dirty_folio = filemap_dirty_folio,
        .writepages = ecryptfs_writepages,
        .read_folio = ecryptfs_read_folio,
        .write_begin = ecryptfs_write_begin,

On Mon, Oct 28, 2024, at 15:02, Matthew Wilcox wrote:
> On Mon, Oct 28, 2024 at 02:18:45PM +0000, Arnd Bergmann wrote:
>
> The comment says it doesn't work without CONFIG_BLOCK:
>
>         /*
>          * XXX: This is pretty broken for multiple reasons: ecryptfs does not
>          * actually use buffer_heads, and ecryptfs will crash without
>          * CONFIG_BLOCK.  But it matches the behavior before the default for
>          * address_space_operations without the ->dirty_folio method was
>          * cleaned up, so this is the best we can do without maintainer
>          * feedback.
>
> This comment has been there since June 2021, so I think we can just
> delete ecryptfs now?

I have no opinion on removing ecryptfs, but I don't how possibly
removing it is related to the patch I sent, as far as I can tell
it just means it relies on both CONFIG_BLOCK and CONFIG_BUFFER_HEAD
then.

Is there any indication that the last users that had files on
ecryptfs are unable to update their kernels?

> If we can't delete it for some reason, I think we can use
> filemap_dirty_folio() and remove the setting of invalidate_folio()
> as block_invalidate_folio() is a no-op if there are no folio_buffers.
> ie this in lieu of your patch:
>
> -#ifdef CONFIG_BLOCK
> -       .dirty_folio    = block_dirty_folio,
> -       .invalidate_folio = block_invalidate_folio,
> -#endif
> +       .dirty_folio = filemap_dirty_folio,
>         .writepages = ecryptfs_writepages,

This clearly addresses the build failure as well, so no objections
from me, but I don't understand what the functional difference is
here and would rely on you to write a changelog text for that change.

     Arnd

On Mon, Oct 28, 2024 at 09:50:37PM +0000, Arnd Bergmann wrote:
> On Mon, Oct 28, 2024, at 15:02, Matthew Wilcox wrote:
> >
> > This comment has been there since June 2021, so I think we can just
> > delete ecryptfs now?
> 
> I have no opinion on removing ecryptfs, but I don't how possibly
> removing it is related to the patch I sent, as far as I can tell
> it just means it relies on both CONFIG_BLOCK and CONFIG_BUFFER_HEAD
> then.
> 
> Is there any indication that the last users that had files on
> ecryptfs are unable to update their kernels?

Debian is still shipping ecryptfs-utils and is building and including
the ecryptfs kernel module in their distro kernel.`

So it seems likely that there are probably a non-zero (although
probably relatively small) number of ecryptfs users out there.

	 	    	   	     	      - Ted

On Mon, Oct 28, 2024 at 9:33 PM Theodore Ts'o <tytso@mit.edu> wrote:
> On Mon, Oct 28, 2024 at 09:50:37PM +0000, Arnd Bergmann wrote:
> > On Mon, Oct 28, 2024, at 15:02, Matthew Wilcox wrote:
> > >
> > > This comment has been there since June 2021, so I think we can just
> > > delete ecryptfs now?
> >
> > I have no opinion on removing ecryptfs, but I don't how possibly
> > removing it is related to the patch I sent, as far as I can tell
> > it just means it relies on both CONFIG_BLOCK and CONFIG_BUFFER_HEAD
> > then.
> >
> > Is there any indication that the last users that had files on
> > ecryptfs are unable to update their kernels?
>
> Debian is still shipping ecryptfs-utils and is building and including
> the ecryptfs kernel module in their distro kernel.`
>
> So it seems likely that there are probably a non-zero (although
> probably relatively small) number of ecryptfs users out there.

Yeah. Sadly I'm one, as I needed something to migrate off of when
encfs was deprecated.

Is there another soon-to-be-deprecated filesystem to encrypt
directories I should move to? :)

I definitely think we need some loud warnings and Tylers' suggestion
for a read-only grace period would be helpful.

thanks
-john

On Mon, Oct 13, 2025 at 11:07:56PM -0700, John Stultz wrote:
> 
> Yeah. Sadly I'm one, as I needed something to migrate off of when
> encfs was deprecated.
> 
> Is there another soon-to-be-deprecated filesystem to encrypt
> directories I should move to? :)

Well, the closest way of encrypting directories is fscrypt.  The good
news is that it works on top of btrfs, ext4, f2fs, and ubifs, and it's
not likely to be deprecated given that it is used by chromeos and
android.  The bad news is that the integration with traditional Linux
desktop setups (e.g., login, etc.) was never completed.

This is probably because for many desktop and server configurations,
using dm-crypt is actually better suited and more secure.  It
certainly doesn't solve the "just encrypt a directory hierarchy in a
file system" and the "support multiple users' who might have different
encryption keys and which are mutually suspicious" use cases.  But
this appears to not be sufficiently interesting for distributions to
do that integration work.

					- Ted

On 2024-10-28 21:33:28, Theodore Ts'o wrote:
> On Mon, Oct 28, 2024 at 09:50:37PM +0000, Arnd Bergmann wrote:
> > On Mon, Oct 28, 2024, at 15:02, Matthew Wilcox wrote:
> > >
> > > This comment has been there since June 2021, so I think we can just
> > > delete ecryptfs now?
> > 
> > I have no opinion on removing ecryptfs, but I don't how possibly
> > removing it is related to the patch I sent, as far as I can tell
> > it just means it relies on both CONFIG_BLOCK and CONFIG_BUFFER_HEAD
> > then.
> > 
> > Is there any indication that the last users that had files on
> > ecryptfs are unable to update their kernels?
> 
> Debian is still shipping ecryptfs-utils and is building and including
> the ecryptfs kernel module in their distro kernel.`
> 
> So it seems likely that there are probably a non-zero (although
> probably relatively small) number of ecryptfs users out there.

It would be good to discuss how we can get the message out to users to
migrate off of eCryptfs so that functionality can be reduced and
eventually it can be removed.

What do folks think about the following?

1. Print loud warnings at mount time that eCryptfs is deprecated and
   give a specific date when write support will be removed.
2. Remove write support at that date, while retaining read-only support
   to allow any lagging users to move their data to fscrypt or other
   alternatives.
3. Print loud warnings at mount that eCryptfs will be removed and give a
   specific date.
4. Remove it.

Suggestions on lead times for #2 and #4 would be appreciated.

Tyler