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