public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@kernel.org>
To: Tyler Hicks <code@tyhicks.com>,
	"Matthew Wilcox (Oracle)" <willy@infradead.org>,
	Damien Le Moal <damien.lemoal@opensource.wdc.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
	ecryptfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH] eccryptfs: select CONFIG_BUFFER_HEAD
Date: Mon, 28 Oct 2024 14:18:45 +0000	[thread overview]
Message-ID: <20241028141955.639633-1-arnd@kernel.org> (raw)

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


             reply	other threads:[~2024-10-28 14:19 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-28 14:18 Arnd Bergmann [this message]
2024-10-28 15:02 ` ecryptfs is unmaintained and untested Matthew Wilcox
2024-10-28 21:50   ` Arnd Bergmann
2024-10-29  4:33     ` Theodore Ts'o
2024-10-30 21:06       ` Tyler Hicks
2026-02-16 11:53         ` René Herman
2025-10-14  6:07       ` John Stultz
2025-10-14 14:39         ` Theodore Ts'o
2025-10-14 16:38           ` John Stultz
2025-10-14 16:54             ` Martin Steigerwald
2025-10-14 17:52             ` Theodore Ts'o
2025-10-14 16:52           ` Martin Steigerwald
2025-10-14 20:35           ` Eric Biggers
2025-10-15  1:31             ` Theodore Ts'o
2025-10-15  2:23               ` Eric Biggers

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=20241028141955.639633-1-arnd@kernel.org \
    --to=arnd@kernel.org \
    --cc=arnd@arndb.de \
    --cc=code@tyhicks.com \
    --cc=damien.lemoal@opensource.wdc.com \
    --cc=ecryptfs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=willy@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox