NetBSD Problem Report #59280

From www@netbsd.org  Fri Apr 11 15:21:39 2025
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id CC3741A9239
	for <gnats-bugs@gnats.NetBSD.org>; Fri, 11 Apr 2025 15:21:39 +0000 (UTC)
Message-Id: <20250411152138.281C31A923F@mollari.NetBSD.org>
Date: Fri, 11 Apr 2025 15:21:38 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: uarea is a page larger under DIAGNOSTIC without a redzone
X-Send-Pr-Version: www-1.0

>Number:         59280
>Category:       port-i386
>Synopsis:       uarea is a page larger under DIAGNOSTIC without a redzone
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-i386-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Apr 11 15:25:00 +0000 2025
>Originator:     Taylor R Campbell
>Release:        current, 10, 9, ...
>Organization:
The i386BSD Diagnostackian
>Environment:
>Description:
Back in 2008, ad@ made the redzone (guard page) in the i386 and amd64 uarea conditional on DIAGNOSTIC:

https://mail-index.netbsd.org/source-changes/2008/12/20/msg214261.html
https://mail-index.netbsd.org/source-changes/2008/12/20/msg214262.html

A few months later, in 2009, rmind@ merged i386/vm_machdep.c and amd64/vm_machdep.c into x86/vm_machdep.c:

https://mail-index.netbsd.org/source-changes/2009/03/30/msg219023.html

Late in 2009, rmind@ disabled the kernel stack redzone altogether for reasons unclear -- but left the DIAGNOSTIC-conditional definitions of UPAGES intact on both i386 and amd64:

https://mail-index.netbsd.org/source-changes/2009/11/25/msg003510.html

    100 #ifndef UPAGES
    101 # ifdef DIAGNOSTIC
    102 #  define	UPAGES		3	/* 2 + 1 page for redzone */
    103 # else
    104 #  define	UPAGES		2	/* normal pages of u-area */
    105 # endif /* DIAGNOSTIC */
    106 #endif /* !defined(UPAGES) */

https://nxr.netbsd.org/xref/src/sys/arch/i386/include/param.h?r=1.71#100

     61 #ifdef DIAGNOSTIC
     62 #define	UPAGES		4		/* pages of u-area (1 for redzone) */
     63 #else
     64 #define	UPAGES		3		/* pages of u-area */
     65 #endif
     66 #define	USPACE		(UPAGES * NBPG)	/* total size of u-area */

https://nxr.netbsd.org/xref/src/sys/arch/amd64/include/param.h?r=1.12#61

A decade later, at the start of the Eternal March, maxv@ restored the redzone -- but only on amd64, not on i386:

https://mail-index.netbsd.org/port-amd64/2020/03/14/msg003179.html
https://mail-index.netbsd.org/source-changes/2020/03/17/msg115178.html

--- a/sys/arch/amd64/include/param.h
+++ b/sys/arch/amd64/include/param.h
...
@@ -69,10 +69,8 @@

 #if defined(KASAN) || defined(KMSAN)
 #define	UPAGES		8
-#elif defined(DIAGNOSTIC)
-#define	UPAGES		5		/* pages of u-area (1 for redzone) */
 #else
-#define	UPAGES		4		/* pages of u-area */
+#define	UPAGES		5		/* pages of u-area (1 for redzone) */
 #endif

In all this time, i386 has had a stack one page larger with DIAGNOSTIC than with non-DIAGNOSTIC.

I think this is a mistake: the memory usage of DIAGNOSTIC and non-DIAGNOSTIC kernels should be essentially the same.
>How-To-Repeat:
code inspection
>Fix:
We should remove the conditional, having DIAGNOSTIC use a stack of the same size as non-DIAGNOSTIC, and either nix the extra page unconditionally, or make it a guard page unconditionally like we do on amd64.

Home	PR Database Search