From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fout-a4-smtp.messagingengine.com (fout-a4-smtp.messagingengine.com [103.168.172.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D52BD2DC791; Tue, 14 Jul 2026 05:01:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.147 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784005266; cv=none; b=rWo6UoC4V+O4rpQBrfGYgrHNKGoukLVM6W7PC4XDxNbWPPtaSiodh6amOxFAzJIVrB4wZHhhhqSelSFlHd5rAjZnij/icJqBP55cUMvvlpoRVRKNBdng7HGQPrNw96QHKPWCDzYLTddfsyC3KV4E+OYkXZ1X52sb/Hyfy0avebU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784005266; c=relaxed/simple; bh=r5kVwbzZXDrQt06gepry3W29dv0WR2DwavXWHYXyt5M=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=j7zCR25nf5Wr33w/HcFeT3R91bOsb+mJ4BxfbYnjfbB4MJ4JjVVtL/qPvKnyZx5Blvpl+vtBuUA1J+HvAghDCbzgWeQJJghF1B1nM98YCPEPEQ5DIdMYzvXvi1H3hzTPooW413ZZ0CDK/KbdwXka8aRmM9peNdf0SOn0YPloQ4Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=tyhicks.com; spf=pass smtp.mailfrom=tyhicks.com; dkim=pass (2048-bit key) header.d=tyhicks.com header.i=@tyhicks.com header.b=kE+VslfX; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=JnE06WuO; arc=none smtp.client-ip=103.168.172.147 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=tyhicks.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=tyhicks.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=tyhicks.com header.i=@tyhicks.com header.b="kE+VslfX"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="JnE06WuO" Received: from phl-compute-12.internal (phl-compute-12.internal [10.202.2.52]) by mailfout.phl.internal (Postfix) with ESMTP id 1C497EC0177; Tue, 14 Jul 2026 01:01:04 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-12.internal (MEProxy); Tue, 14 Jul 2026 01:01:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tyhicks.com; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm1; t=1784005264; x=1784091664; bh=+cwBk161SS 3UuNqbC94GvXgpGs2bozCaS5y9RituKbY=; b=kE+VslfXkGkezhMQ/hxZ+B0IYU FVuBfJ7BwnnLa1jNWwcqlj5GnhrDa0kRoDOVbOlJ4LPAE6mpo1Py84tVqaQfGvMO q0zlvMcgcP1x1tRL3xoJMoPz5DVgbWqJRtFF8/LWkJ7TKnJ/DuIlKD2AiXwoizTh N+YoKkR04pv7j3V7hUkxaSj5pITB+ZwhtGzGiSPsK2PmSfASBaaYuiWZpum1xHoT rzJ31b6OU+Fo6cWolgJNMrWGwoU08uvLZsYGpc+BQeeeV9Hj+lXNCYK0iUS4ixi8 4KUmgLZysMrGnaTN0ZQ7epk7KODJtGW8f0xNpZVZpA8oGz+55u7G9MnreD+w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1784005264; x=1784091664; bh=+cwBk161SS3UuNqbC94GvXgpGs2bozCaS5y 9RituKbY=; b=JnE06WuOEg5c6qCpWjfPLbc84I59xuA/yFpElRKOgAAGIZwQTwt CYLenYpllenmrAPbzUpOrXJFz0lrJqq7WzgOnflQaq3ckyUDb9L7WiHlswj4RpK8 73Ay3JknuoFqS3NNpd9cIHB/MwkFT6HZKyJtz4XQjJ9KSZXZvxWhlx/o5MladNre HZJ3QWJvw8vQsm2qOYhd3fqvDnaRv9cQE9e+Rb5La3tRQxsOpiDNsVqex+HvJJRS ZNw1p/vF+2EWbAnAq+lK4jr0PoAYrzZsQgIc5PbWvC4v6U76FCZZ48Mf3XEoVMVz UAbFdi4eWsLUHaxybWoV/q1meNsheYcD0oQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTGcNI4D8OeFqi8luv7qzpUT1BY9mHdEHCiQV2jLC6iP5sG2sSt/c0k0x8+DEX8q60 TrxMe16cE9IB8/VrvXMOvz8It0w5hg5gAAWjPUHntblebgmBAh844pKc+vrAw4YJM4Lhbr kTpk8PNv2b++Zdb1m1yshRVqjZceDgs1X6FqCJ31VqwxGwE7PfAPwba5gy3CqMj6YRHNf0 ynMeJjL33bzdVbY/fdj+cZAigwFK8grFn8kyE+4B9ksjt31phmT7+cEe5JUwF4dYvmTYfJ HbmgCno0RSvlBF6YpvV2FHsHXwiYfZU4DINJK85e/Ce0xs1qMdG3I1g1vCURbxSN3pXbj6 Hgmrs7z0/vJEFMTND15bq3kCCwKcSp7dUXZj+IkjTwkIx+axwfiM1Sb61lN/suQNNK9Mav eFH1XWZLO4vLHM06oELO6vazYZsDYV7XgZU+ufqhQd2ecPJ0pbI2ImOSQ3P42KitGKkKfP HwnvahAFQDww0eiEhHtpb+8obAAtWKYin+S7XOWGjO5jFnCpCtUJMC+vSibKxi1GsNd3ry 4OQWKMSctJ6cmR06yStTyrU71lBPoJSYJbDl6lGzqrckgIkaPEpiqiD0+900/KtqVxd6R5 V4kEND14GNpjYxkyt0miPHAgrMtJSMFSvvSSElD3JZL/apqRo70/ze3ZmkVg X-ME-Proxy: Feedback-ID: i78e14604:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 14 Jul 2026 01:01:02 -0400 (EDT) Date: Tue, 14 Jul 2026 00:00:59 -0500 From: Tyler Hicks To: Aditya Prakash Srivastava , Christoph Hellwig Cc: Christian Brauner , ecryptfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] ecryptfs: use filemap_dirty_folio for address space operations Message-ID: References: <20260703090044.1649-1-aditya.ansh182@gmail.com> Precedence: bulk X-Mailing-List: ecryptfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 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 > - > 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 >