All of lore.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 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.