From: Tyler Hicks <code@tyhicks.com>
To: Aditya Prakash Srivastava <aditya.ansh182@gmail.com>,
Christoph Hellwig <hch@lst.de>
Cc: Christian Brauner <brauner@kernel.org>,
ecryptfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ecryptfs: use filemap_dirty_folio for address space operations
Date: Tue, 14 Jul 2026 00:00:59 -0500 [thread overview]
Message-ID: <alXCix5IKavpp2Pr@elm> (raw)
In-Reply-To: <20260703090044.1649-1-aditya.ansh182@gmail.com>
On 2026-07-03 09:00:44, Aditya Prakash Srivastava wrote:
> ecryptfs does not use buffer_heads. The legacy block_dirty_folio and
> block_invalidate_folio mapping operations were only added as a
> temporary compatibility fallback under CONFIG_BLOCK.
>
> Since ecryptfs does not attach private metadata (such as buffer_heads)
> to its folios, block_dirty_folio is unnecessary.
>
> Modernize ecryptfs to use filemap_dirty_folio for its dirty_folio
> address space operation. This allows removing the block_dirty_folio
> and block_invalidate_folio fallbacks, removing the buffer_head header
> include, and removing the CONFIG_BLOCK dependency inside ecryptfs_aops.
>
> Signed-off-by: Aditya Prakash Srivastava <aditya.ansh182@gmail.com>
This looks correct to me and I've successfully ran the kernel tests in
the ecryptfs-utils test suite with the patch applied.
Adding Christoph for comment since this addresses the concern he
documented in the code comment below.
Tyler
> ---
> fs/ecryptfs/mmap.c | 15 +--------------
> 1 file changed, 1 insertion(+), 14 deletions(-)
>
> diff --git a/fs/ecryptfs/mmap.c b/fs/ecryptfs/mmap.c
> index 2c2b12fedeae..a057472b409c 100644
> --- a/fs/ecryptfs/mmap.c
> +++ b/fs/ecryptfs/mmap.c
> @@ -510,21 +510,8 @@ static sector_t ecryptfs_bmap(struct address_space *mapping, sector_t block)
> return block;
> }
>
> -#include <linux/buffer_head.h>
> -
> 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.
> - */
> -#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,
> --
> 2.47.3
>
next prev parent reply other threads:[~2026-07-14 5:01 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-03 9:00 [PATCH] ecryptfs: use filemap_dirty_folio for address space operations Aditya Prakash Srivastava
2026-07-14 5:00 ` Tyler Hicks [this message]
2026-07-14 5:18 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alXCix5IKavpp2Pr@elm \
--to=code@tyhicks.com \
--cc=aditya.ansh182@gmail.com \
--cc=brauner@kernel.org \
--cc=ecryptfs@vger.kernel.org \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.