Re: ecryptfs is unmaintained and untested

["Arnd Bergmann" <arnd@arndb.de>]

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