From: Michael Bommarito <michael.bommarito@gmail.com>
To: Richard Weinberger <richard@nod.at>,
Anton Ivanov <anton.ivanov@cambridgegreys.com>,
Johannes Berg <johannes@sipsolutions.net>
Cc: linux-um@lists.infradead.org, linux-kernel@vger.kernel.org,
Michael Bommarito <michael.bommarito@gmail.com>,
stable@vger.kernel.org
Subject: [PATCH] um: drivers: use libc strrchr() in cow_user.o
Date: Tue, 7 Apr 2026 12:44:35 -0400 [thread overview]
Message-ID: <20260407164435.726012-2-michael.bommarito@gmail.com> (raw)
In-Reply-To: <20260407164435.726012-1-michael.bommarito@gmail.com>
Building ARCH=um on a host with glibc >= 2.43 fails:
arch/um/drivers/cow_user.c:156:17: error: implicit declaration of
function 'strrchr' [-Wimplicit-function-declaration]
cow_user.o is a host-side helper (compiled with -D__UM_HOST__) that
calls libc strrchr(). It inherits the global -Dstrrchr=kernel_strrchr
remap from arch/um/Makefile, which is intentionally kept in USER_CFLAGS
to prevent linker clashes between libc and kernel symbols.
This combination was harmless until glibc 2.43, which added (glibc
commit cd748a63ab1a, "Implement C23 const-preserving standard library
macros"):
#define strrchr(S,C) __glibc_const_generic(S, const char *, strrchr(S, C))
The glibc function-like macro replaces the -D object-like macro. The
inner strrchr token in the expansion is protected from recursive
expansion, so it refers to the bare symbol strrchr -- but the header
declaration was already rewritten to kernel_strrchr by the -D. The
result is an implicit-declaration error.
The remap was originally added in commit 2c51a4bc0233 ("um: fix
strrchr() problems") to resolve a linker clash when both
CONFIG_STATIC_LINK and CONFIG_UML_NET_VDE are set. Recently, commit
a74b6c0e53a6 ("um: Don't rename vmap to kernel_vmap") trimmed
the now-obsolete vmap remap from arch/um/Makefile and updated the
comment to explicitly call out -Dstrrchr=kernel_strrchr as one of the
remaps that still prevents libc symbol clashes. That framing is kept
here: the global strrchr remap is still needed for kernel-side
objects, but cow_user.o is host-side and should use libc strrchr
directly.
cow_user.o is built whenever CONFIG_BLK_DEV_UBD=y (the standard UML
block device), so this affects most non-trivial UML configurations.
cow_user.c is the only file under arch/um/ that calls strrchr().
Fix this by undoing the remap for just this translation unit via
per-object CFLAGS. In UML's Makefile.rules, CFLAGS_$(basetarget).o
is appended after USER_CFLAGS, so -Ustrrchr correctly overrides the
earlier -Dstrrchr=kernel_strrchr.
Standalone reproducer (fails on glibc >= 2.43, succeeds on older):
printf '#include <string.h>\nvoid f(void) { char *p = strrchr("foo", 47); }\n' \
| gcc -c -Dstrrchr=kernel_strrchr -x c - -o /dev/null
Tested on:
- Host: Ubuntu, glibc 2.43-2ubuntu1, gcc 15.2.0
- Kernel: v7.0.0-rc6 (3aae9383f42f)
- Build: ARCH=um defconfig + CONFIG_BLK_DEV_UBD=y, clean compile
- Boot: UML boots to Debian bookworm multi-user target
- COW: UML boots with COW overlay (ubd0=cow,backing), exercising
the absolutize() -> strrchr() path in cow_user.c
AI coding tools (Claude Code with Opus 4.6, and Codex with GPT-5.4)
assisted with debugging, test design, and drafting; the author
manually reviewed every line and executed every build and boot test
on the host. Full disclosure in the cover letter.
Fixes: 2c51a4bc0233 ("um: fix strrchr() problems")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4-6
Assisted-by: Codex:gpt-5-4
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
---
arch/um/drivers/Makefile | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/um/drivers/Makefile b/arch/um/drivers/Makefile
index 36dc57840..e387ae33f 100644
--- a/arch/um/drivers/Makefile
+++ b/arch/um/drivers/Makefile
@@ -49,6 +49,9 @@ obj-$(CONFIG_UML_PCI_OVER_VFIO) += vfio_uml.o
# pcap_user.o must be added explicitly.
USER_OBJS := fd.o null.o pty.o tty.o xterm.o vector_user.o
CFLAGS_null.o = -DDEV_NULL=$(DEV_NULL_PATH)
+# cow_user.o is a host-side helper that uses libc strrchr(); undo the global
+# UML remap to kernel_strrchr for this translation unit.
+CFLAGS_cow_user.o += -Ustrrchr
CFLAGS_xterm.o += '-DCONFIG_XTERM_CHAN_DEFAULT_EMULATOR="$(CONFIG_XTERM_CHAN_DEFAULT_EMULATOR)"'
--
2.49.0
next prev parent reply other threads:[~2026-04-07 16:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-07 16:44 [PATCH 0/1] um: drivers: use libc strrchr() in cow_user.o Michael Bommarito
2026-04-07 16:44 ` Michael Bommarito [this message]
2026-04-07 16:57 ` [PATCH] " Johannes Berg
2026-04-07 18:15 ` [PATCH v2] um: drivers: call kernel_strrchr() explicitly in cow_user.c Michael Bommarito
2026-04-08 6:46 ` Johannes Berg
2026-04-08 7:06 ` Michael Bommarito
2026-04-08 7:01 ` [PATCH v3] " Michael Bommarito
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=20260407164435.726012-2-michael.bommarito@gmail.com \
--to=michael.bommarito@gmail.com \
--cc=anton.ivanov@cambridgegreys.com \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-um@lists.infradead.org \
--cc=richard@nod.at \
--cc=stable@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.