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
