[PATCH 0/1] um: drivers: use libc strrchr() in cow_user.o

[Michael Bommarito <michael.bommarito@gmail.com>]

Hi,

Building ARCH=um on hosts with glibc 2.43 fails due to an interaction
between UML's global -Dstrrchr=kernel_strrchr remap and glibc's new
C23 const-preserving macro for strrchr().

The failure is in arch/um/drivers/cow_user.c, a host-side helper that
calls libc strrchr().  The object is built whenever CONFIG_BLK_DEV_UBD=y,
which is the standard UML block device driver, so this affects most
non-trivial UML builds on Ubuntu/Debian today.

I caught this while testing on the release candidate for Ubuntu 26.04
LTS, whose libc is glibc 2.43.  With 26.04 LTS shipping in the next
few weeks and carrying five years of support, the affected user base
will grow quickly, which is the main rationale for the Cc: stable
trailer in the patch.

The root cause is that glibc 2.43 added (glibc commit cd748a63ab1a):

  #define strrchr(S,C) __glibc_const_generic(S, const char *, strrchr(S, C))

as part of C23 qualifier-generic support.  This function-like macro
replaces UML's -D object-like macro, and the recursive-expansion
protection in the C preprocessor causes the inner strrchr to resolve as
the bare symbol -- which was never declared under that name, because
the header declaration was already rewritten to kernel_strrchr by the
-D.

The remap itself (commit 2c51a4bc0233) is still needed for kernel-side
objects to prevent linker clashes.  This was re-affirmed very recently
in commit a74b6c0e53a6 ("um: Don't rename vmap to kernel_vmap"),
which removed the now-obsolete vmap remap and updated the comment in
arch/um/Makefile to explicitly call out -Dstrrchr=kernel_strrchr as
one of the remaps that still prevents libc symbol clashes.  This patch
only exempts the one host-side object that is proven to break:
cow_user.o.

A 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 Ubuntu with glibc 2.43-2ubuntu1 and gcc 15.2.0 against
v7.0-rc6 (3aae9383f42f).  v7.0-rc7 dropped on 2026-04-05 and neither
arch/um/drivers/Makefile nor arch/um/drivers/cow_user.c changed
between rc6 and rc7, so this patch applies and behaves identically on
both.  The patched kernel builds cleanly, boots a Debian bookworm
rootfs to multi-user, and boots with a COW overlay that exercises the
absolutize() -> strrchr() code path in cow_user.c.

cow_user.c is the only file under arch/um/ that calls strrchr(), so
this patch is complete for the current tree.  A broader discussion
about whether the global strrchr remap should be narrowed further
(given that glibc's C23 macros are here to stay for strchr, memchr,
strstr, etc.) may be warranted as a follow-up.

Compatibility and impact
========================

The patch only changes CFLAGS for one translation unit, cow_user.o.
By configuration:

  - glibc >= 2.43: build is fixed (the point).
  - glibc <  2.43: no observable change.  cow_user.o now calls libc
    strrchr() instead of being silently redirected to kernel_strrchr()
    by the global -D; both are functionally identical for the
    NUL-terminated path strings absolutize() uses.
  - CONFIG_STATIC_LINK=y + CONFIG_UML_NET_VDE=y (the original 2011
    case): unaffected.  The global remap is preserved for every
    other translation unit, so the linker clash that 2c51a4bc0233
    fixed cannot recur.
  - CONFIG_BLK_DEV_UBD=n: cow_user.o is not built; the new
    per-object CFLAGS line is inert.

Verified locally with nm: after the patch, cow_user.o references
libc strrchr (not kernel_strrchr), and the final UML binary cleanly
resolves both kernel_strrchr (kernel side, EXPORT_SYMBOL'd) and
strrchr@GLIBC_2.2.5 (libc) with no multiple-definition errors.

A small personal note
=====================

The last and only patch I sent to LKML was in December 2006 [1], a
two-line fix in the IEEE 802.11 softmac association code during the
dark days of laptop hardware support.  I have done my best to follow
the guidance, especially the recent AI assistance protocols in
Documentation/process/coding-assistants.rst and generated-content.rst,
but apologize in advance for anything I have done wrong regardless!

PS: see the note below about checkpatch.pl and Assisted-by: behavior.
I'd be happy to submit a patch for that as well, but suspect an
experienced maintainer might prefer to handle it.

[1] https://marc.info/?l=linux-kernel&m=116607116605310&w=2

Disclosure of tool assistance
=============================

Per Documentation/process/coding-assistants.rst and
generated-content.rst:

Tools used: Claude Code with Claude Opus 4.6 (Anthropic); Codex with
GPT-5.4 (OpenAI).

What the tools did: helped reason through the -D macro / glibc C23
macro interaction; helped narrow the failure to cow_user.o; suggested
-Ustrrchr as the minimal override; helped construct the standalone
gcc reproducer and the build/boot/COW test matrix; helped interpret
build and boot logs; drafted the changelog and this cover letter;
cross-checked against the glibc 2.43 release notes and the referenced
kernel/glibc commits; located recent precedent (a74b6c0e53a6) and the
Documentation/process/ disclosure guidance; ran checkpatch.pl and
get_maintainer.pl interactively.

What only the author did: manually reviewed every line of patch,
changelog, and cover letter; executed every build and boot test on
the host (ARCH=um build, bare kernel boot, Debian bookworm rootfs
boot, COW overlay boot exercising cow_user.c::absolutize());
inspected the resulting kernel binary, boot logs, and exercised code
path by hand; made all final scope, framing, recipient,
and Cc: stable decisions.

The author has read every line of this submission, understands it,
and takes full responsibility under the Developer Certificate of
Origin.

A note on the Assisted-by: trailers
-----------------------------------

The trailers in the patch use the format from
Documentation/process/coding-assistants.rst:

  Assisted-by: AGENT_NAME:MODEL_VERSION

scripts/checkpatch.pl in v7.0-rc6 does not yet recognize Assisted-by:
as a standard signature, so it emits a "Non-standard signature" warning
and (because the value is not a Name <email> pair) an "Unrecognized
email address" error for each trailer.  These are intentional: the
trailer format follows the in-tree documentation, and checkpatch has
not yet been updated to match.  Happy to reformat if maintainers
prefer a different convention.

Thanks,
Michael Bommarito

Michael Bommarito (1):
  um: drivers: use libc strrchr() in cow_user.o

 arch/um/drivers/Makefile | 3 +++
 1 file changed, 3 insertions(+)

--
2.49.0