From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f47.google.com (mail-qv1-f47.google.com [209.85.219.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4DB543B775B for ; Tue, 7 Apr 2026 16:45:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775580311; cv=none; b=P5bpQbOC3dqaIWqTVaSWvBO1PkgRpxhL/zKqH9V5Ywx/mGmXmGRYlThK8W52K4V9VwBjTTIztHhgV/fGK5cHtQxuYWxcVZRu5yfpGemJNwiM1l1+TSaHwwxBwBihus/oxjo3/nlewPNc7C0xfxr05d0jS9BE9DjD2rWqQRrQnJ8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775580311; c=relaxed/simple; bh=nMz4Cp1/W4MQfWhAfPopO4o+f0BbbkrIOkniQ/TavHg=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=h+D5iEDSbFlwnbedsJcIxYEF0ASSoivQVbAjlaWwk4NUHLga2lOx5eoGVcpXCKHm8kb5OkT8sJNPb2XHhR1RMs7K23mfw+lJ3+h6Cigu8LPfpfqInxvyovBOjRB9hncekWaiqF5Sx9+AolWjWzPwzoPKf7cT2jLY7HwzfVSUdMM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=gQlTtSbs; arc=none smtp.client-ip=209.85.219.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="gQlTtSbs" Received: by mail-qv1-f47.google.com with SMTP id 6a1803df08f44-8a068db9989so754656d6.0 for ; Tue, 07 Apr 2026 09:45:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775580309; x=1776185109; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=gSINc38Cy5uCy/SOLZjP/5z73q6WQERusZs5SUoSVOk=; b=gQlTtSbsbNmRKdH4TgoZ/dCQ7fVSWgIhK2cWX8aqCSM6/hk/58D6cNK3GgrcgHIzIO KuO8wOIUn/xVpyY4JuEiaH+51VQFIVHJpR7ICjSLURLIqxkIHhVlzo/ixtJiuCNBtzhc blbccu76MH06Sb5wqrojQEsn8fc86sbEW8CKuooP30jUIYzV4pDzmqeNVhnCBdHr8s0K U4V84+/zinQIdNCLcFvtvjIeyes1Pz8TpM1aUCsDETPNfFfzG8+Z0jYYtFLN84SDMFO9 X3YIKosFKToethFw338Xb2j6hgQ8Wt/4WLDqQCZ1FDuCWkL6QY5sYEYcLPXL9hoV5kge o3CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775580309; x=1776185109; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=gSINc38Cy5uCy/SOLZjP/5z73q6WQERusZs5SUoSVOk=; b=RD+feFMcjhBus5GQDgAV6U6SfD2i8BhxommU53iTlRD0uHTMfvhhdq3BpC58y6yMLe S5af0dITE+d+o0r/MkKQzu6gumCwrqAy1ebVf4r0ZzI0v4+1Ftu35aLkJ2o7L0PAbgAs 6rnjuwXlCa0UlFC4S9pU/IaKTaOvfczvbPQLa/gfptdXfSOMVlgu3tL9+XH/H0QpxvoT sYHepDnJgMpJCD40E6AdtLXVDn/rgaL/7jjtdYk7LhDjDRqpd/1F2D9Juuth7UCFUlZF ouPgRegMhyApCiJThwX0adiyt++qVT4krRN8rvjLfjB5hnzYPTaD7j2O+qAIAnpc4qoI IMEg== X-Forwarded-Encrypted: i=1; AJvYcCVY18tHlwJ9ETglK+LbGRnpprOvtBCRCLKpAAAWQatiwk/sZEIm0nHgl9LvTL4P1uldOKCmH2D/1e5TdGE=@vger.kernel.org X-Gm-Message-State: AOJu0YxQo4I6TcMzALFSaWw8L/1WSKphRZ6s9rokjQ0hg++sBtclcaaO pk3rA4vIabwFW8hvHQxq6lCgJ7zx0F07PMHIxNR9wy4opmKx/uJ+Egyp X-Gm-Gg: AeBDietPdkfVctxHunMg4nSeTQ+Xx2Mb+9+FEDP5Bf3RlFjJ2J3NoTFd+ZgZhePK6lP ErJrUszt7MJLO0k6RZ8irh4aIZrccsdTOcliVRvh03H7T5/gFH0uyHGUtfrConovGaGO+Ptok72 ZsVQ6aDiVzBUMohjDyh/9MDy/1RNxJt0e7rKBj6UaNNkx2S77hoD2IB1q6VakXwihm/cs1vfOou PdhLvWvxnMU6kmTGUgdePXuJJLWqhRpSRWWC4qvrT11zTbOFbErwOLnzBwPMCYzSK5veD3f+9fh SrbBMlWRBLKaqP4SnaiNRFzWyg2L2df8BzpqH0kDYxf/XuHVEdbOFjerscb3HM0Ssh07V4/BGAd //G03TPW2ZrNHYL+HF2zNCliRQ2RCFVZPHCE5U6Wew/VyiAK/pxh8+aFS3UANYTXzuEpfp8U9Ih 4jx5FmO0i41GK1dPVUuTa9Ts1D87jxeNSEhUiWnJJBkDfnl737tT+sIkjZcd7chQtWQiqaIvdNr p3VT+fwDnA65Nk+aiDCKUGCiCk= X-Received: by 2002:a05:6214:4883:b0:89f:65be:998a with SMTP id 6a1803df08f44-8a5e6ccdf6emr330429436d6.0.1775580308286; Tue, 07 Apr 2026 09:45:08 -0700 (PDT) Received: from workstation1 (c-68-48-65-54.hsd1.mi.comcast.net. [68.48.65.54]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8aa70136e87sm62044156d6.22.2026.04.07.09.45.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Apr 2026 09:45:07 -0700 (PDT) From: Michael Bommarito To: Richard Weinberger , Anton Ivanov , Johannes Berg Cc: linux-um@lists.infradead.org, linux-kernel@vger.kernel.org, Michael Bommarito Subject: [PATCH 0/1] um: drivers: use libc strrchr() in cow_user.o Date: Tue, 7 Apr 2026 12:44:34 -0400 Message-ID: <20260407164435.726012-1-michael.bommarito@gmail.com> X-Mailer: git-send-email 2.53.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 \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 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