port-sparc/60838: sparc fails to enforce RLIMIT_DATA on exec

["campbell+netbsd%mumble.net@localhost via gnats" <gnats-admin%NetBSD.org@localhost>]

>Number:         60838
>Category:       port-sparc
>Synopsis:       sparc fails to enforce RLIMIT_DATA on exec
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-sparc-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Oct 02 15:30:00 +0000 2026
>Originator:     Taylor R Campbell
>Release:        current
>Organization:
The NexecBSData Limitation, Inc.
>Environment:
NetBSD 11.99.8 (GENERIC) #0: Thu Oct 1 15:43:13 UTC 2026 root%babylon5.netbsd.org@localhost:/tmp/build/2026.10.01.07.32.34-sparc/obj/sys/arch/sparc/compile/GENERIC
>Description:

	sparc -- and only sparc, as far as I have seen -- apparently
	fails to enforce RLIMIT_DATA on exec/spawn, which is weird
	because the RLIMIT_DATA logic is machine-independent.

	The evidence of this is that the kernel/t_signal_and_sp test
	case getstack_failedexec_rlimit_data `exited normally but
	failed to create the results file', which means that the exec
	call unexpectedly _succeeded_ and replaced the atf process
	image by another one, confusing atf:

FAILED: Test case exited normally but failed to create the results file: Failed to open /tmp/atf-run.6XWFoY/tcr

	https://releng.netbsd.org/b5reports/sparc/2026/2026.10.01.07.32.34/test.html#kernel_t_signal_and_sp_getstack_failedexec_rlimit_data

	Similarly, posix_spawn failed to fail:

*** Check failed: /tmp/build/2026.10.01.07.32.34-sparc/src/tests/kernel/t_signal_and_sp.c:884: Expected true value in (errno = posix_spawn(&pid, argv[0], NULL, NULL, argv, NULL)) != 0

	https://releng.netbsd.org/b5reports/sparc/2026/2026.10.01.07.32.34/test.html#kernel_t_signal_and_sp_getstack_failedspawn_rlimit_data

>How-To-Repeat:

	cd /usr/tests/kernel
	atf-run t_signal_and_sp | atf-report

>Fix:

	Yes, please!

	Perhaps there is something funny about ELF images on sparc that
	makes the machine-independent RLIMIT_DATA check logic not apply
	like it does everywhere else?