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

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

[Michael Bommarito]

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

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

[Michael Bommarito]

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

Re: [PATCH] um: drivers: use libc strrchr() in cow_user.o

[Johannes Berg]

On Tue, 2026-04-07 at 12:44 -0400, Michael Bommarito wrote:
> 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.

Not sure. glibc has an unfortunate tendency to use a huge amount of
stack space for just about anything (though I admit that's unlikely for
strrchr) - we should probably just explicitly call kernel_strrchr() in
the file instead.

johannes

[PATCH v2] um: drivers: call kernel_strrchr() explicitly in cow_user.c

[Michael Bommarito]

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.

Fixes: 2c51a4bc0233 ("um: fix strrchr() problems")
Suggested-by: Johannes Berg <johannes@sipsolutions.net>
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>
---
v1:     https://lore.kernel.org/all/20260407164435.726012-2-michael.bommarito@gmail.com/
Review: https://lore.kernel.org/linux-um/1e15d25c23b444eae1dcfc01432e7ec1e19e25a0.camel@sipsolutions.net/

Changes since v1:
 - Per Johannes Berg's review (link above): rather than exempting
   cow_user.o from the global -Dstrrchr=kernel_strrchr remap via
   -Ustrrchr in arch/um/drivers/Makefile, call kernel_strrchr()
   explicitly in cow_user.c.  This keeps the existing semantic that
   cow_user.o uses the kernel's strrchr (no new libc dependency on
   the host side), and the source no longer relies on the build-time
   rewrite at all.
 - Reverted the arch/um/drivers/Makefile CFLAGS change from v1.
 - Verified locally on v7.0-rc6: clean build, cow_user.o references
   'U kernel_strrchr' (no libc strrchr), the final linux binary has
   no strrchr@GLIBC_2.2.5 reference anywhere, and the kernel boots
   to multi-user with a COW overlay that exercises the patched
   code path.  Full boot log captured locally.

 arch/um/drivers/cow_user.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/um/drivers/cow_user.c b/arch/um/drivers/cow_user.c
index 29b46581ddd1..ec8e6121b402 100644
--- a/arch/um/drivers/cow_user.c
+++ b/arch/um/drivers/cow_user.c
@@ -15,6 +15,12 @@
 #include "cow.h"
 #include "cow_sys.h"

+/*
+ * arch/um/Makefile remaps strrchr to kernel_strrchr; call the kernel
+ * name directly to avoid glibc >= 2.43's C23 strrchr macro.
+ */
+extern char *kernel_strrchr(const char *, int);
+
 #define PATH_LEN_V1 256

 /* unsigned time_t works until year 2106 */
@@ -153,7 +159,7 @@ static int absolutize(char *to, int size, char *from)
 			   errno);
 		return -1;
 	}
-	slash = strrchr(from, '/');
+	slash = kernel_strrchr(from, '/');
 	if (slash != NULL) {
 		*slash = '\0';
 		if (chdir(from)) {
--
2.49.0

Re: [PATCH v2] um: drivers: call kernel_strrchr() explicitly in cow_user.c

[Johannes Berg]

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

[PATCH v3] um: drivers: call kernel_strrchr() explicitly in cow_user.c

[Michael Bommarito]

Building ARCH=um on glibc >= 2.43 fails:

  arch/um/drivers/cow_user.c: error: implicit declaration of
  function 'strrchr' [-Wimplicit-function-declaration]

glibc 2.43's C23 const-preserving strrchr() macro does not survive
UML's global -Dstrrchr=kernel_strrchr remap from arch/um/Makefile.
Call kernel_strrchr() directly in cow_user.c so the source no longer
depends on the -D rewrite.

Fixes: 2c51a4bc0233 ("um: fix strrchr() problems")
Suggested-by: Johannes Berg <johannes@sipsolutions.net>
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>
---
v2: https://lore.kernel.org/all/20260407181528.879358-1-michael.bommarito@gmail.com/

Changes since v2: trim commit message per review.

 arch/um/drivers/cow_user.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/um/drivers/cow_user.c b/arch/um/drivers/cow_user.c
index 29b46581ddd1..ec8e6121b402 100644
--- a/arch/um/drivers/cow_user.c
+++ b/arch/um/drivers/cow_user.c
@@ -15,6 +15,12 @@
 #include "cow.h"
 #include "cow_sys.h"

+/*
+ * arch/um/Makefile remaps strrchr to kernel_strrchr; call the kernel
+ * name directly to avoid glibc >= 2.43's C23 strrchr macro.
+ */
+extern char *kernel_strrchr(const char *, int);
+
 #define PATH_LEN_V1 256

 /* unsigned time_t works until year 2106 */
@@ -153,7 +159,7 @@ static int absolutize(char *to, int size, char *from)
 			   errno);
 		return -1;
 	}
-	slash = strrchr(from, '/');
+	slash = kernel_strrchr(from, '/');
 	if (slash != NULL) {
 		*slash = '\0';
 		if (chdir(from)) {
--
2.49.0

Re: [PATCH v2] um: drivers: call kernel_strrchr() explicitly in cow_user.c

[Michael Bommarito]

On Wed, 2026-04-08, Johannes Berg wrote:
> I think you should remove about 75% of that commit message, much
> of it is noise [...]
>
> Try without an LLM perhaps.

Thanks.  The irony of using these tools right now to help is that
since none of us fully trust them, we push them to more verbosity,
which ends up creating extra effort.  Appreciate your patience as
we all adapt to this new world and hope v3 hits the mark.