public inbox for linux-um@lists.infradead.org
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Michael Bommarito <michael.bommarito@gmail.com>,
	Richard Weinberger <richard@nod.at>,
	Anton Ivanov <anton.ivanov@cambridgegreys.com>
Cc: linux-um@lists.infradead.org, linux-kernel@vger.kernel.org,
	 stable@vger.kernel.org
Subject: Re: [PATCH v2] um: drivers: call kernel_strrchr() explicitly in cow_user.c
Date: Wed, 08 Apr 2026 08:46:04 +0200	[thread overview]
Message-ID: <a2efd8145cfbc207fef5884e93d09f787811becb.camel@sipsolutions.net> (raw)
In-Reply-To: <20260407181528.879358-1-michael.bommarito@gmail.com> (sfid-20260407_201538_551551_67B5DCE6)

On Tue, 2026-04-07 at 14:15 -0400, Michael Bommarito wrote:
> 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 strrchr().  It inherits the global -Dstrrchr=kernel_strrchr
> remap from arch/um/Makefile, which is intentionally kept in
> USER_CFLAGS to prevent libc/kernel symbol clashes.
> 
> 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 global -Dstrrchr=kernel_strrchr 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 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.  That global remap stays in place.
> 
> Rather than exempting cow_user.o from the remap at build time, call
> kernel_strrchr() explicitly in the source.  This is slightly more
> honest about which strrchr the code wants (the kernel's, as it has
> been since 2011), sidesteps the interaction with glibc's C23 macro
> entirely, avoids adding a new libc strrchr dependency to the UML
> binary, and is robust to future C23 const-preserving macros for
> strchr, memchr, strstr, etc.
> 
> 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(), so
> no other translation units need changes.
> 
> 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-rc6 (3aae9383f42f); verified that neither
>             arch/um/drivers/Makefile nor arch/um/drivers/cow_user.c
>             changed between rc6 and rc7, so the fix applies and
>             behaves identically on both
>   - Build:  ARCH=um defconfig + CONFIG_BLK_DEV_UBD=y, clean compile
>             with no warnings
>   - nm:     cow_user.o references 'U kernel_strrchr' (not libc
>             strrchr), and the final linux binary has no
>             strrchr@GLIBC_2.2.5 symbol anywhere; kernel_strrchr is
>             defined exactly once by lib/string.o and
>             EXPORT_SYMBOL'd
>   - Boot:   UML boots to Debian bookworm multi-user and graphical
>             targets with a COW overlay (ubd0=cow,backing), which
>             exercises the patched absolutize() -> kernel_strrchr()
>             code 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 was posted with v1; a shorter summary
> is in the Assisted-by: trailers below.

I think you should remove about 75% of that commit message, much of it
is noise, and some of it is simply wrong (in particular, "exempting
cow_user.o" really ever only existed in your earlier patch.)

Try without an LLM perhaps.

johannes


  reply	other threads:[~2026-04-08  6:46 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 ` [PATCH] " Michael Bommarito
2026-04-07 16:57   ` 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 [this message]
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=a2efd8145cfbc207fef5884e93d09f787811becb.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=anton.ivanov@cambridgegreys.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-um@lists.infradead.org \
    --cc=michael.bommarito@gmail.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox