NetBSD Problem Report #54800

From martin@aprisoft.de  Thu Dec 26 09:04:20 2019
Return-Path: <martin@aprisoft.de>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id C85427A1E0
	for <gnats-bugs@gnats.NetBSD.org>; Thu, 26 Dec 2019 09:04:20 +0000 (UTC)
Message-Id: <20191226090411.AC66D5CC7A2@emmas.aprisoft.de>
Date: Thu, 26 Dec 2019 10:04:11 +0100 (CET)
From: martin@NetBSD.org
Reply-To: martin@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: pool memory corruption
X-Send-Pr-Version: 3.95

>Number:         54800
>Category:       kern
>Synopsis:       pool memory corruption
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Dec 26 09:05:00 +0000 2019
>Closed-Date:    Sun Nov 21 08:43:37 +0000 2021
>Last-Modified:  Sun Nov 21 08:43:37 +0000 2021
>Originator:     Martin Husemann
>Release:        NetBSD 9.99.30
>Organization:
The NetBSD Foundation, Inc.
>Environment:
System: NetBSD whoever-brings-the-night.aprisoft.de 9.99.17 NetBSD 9.99.17 (WHOEVER) #320: Wed Nov 20 14:36:21 CET 2019 martin@seven-days-to-the-wolves.aprisoft.de:/work/src/sys/arch/sparc64/compile/WHOEVER sparc64
Architecture: sparc64
Machine: sparc64
>Description:

Hidden in the log of the currently failing qemu / anita sparc64 tesst
runs you can find this gem:

[ 422.4170018] pool_redzone_check: 0x1257a0c20: 0x00 != 0x66
[ 422.4170018] pool_redzone_check: 0x1257a0c21: 0x00 != 0x05

If I read that correctly, a single 16bit halfword supposed to be 0x0f66
has been overwritten with 0.

Side question: why is that not worth a panic?

>How-To-Repeat:

See
http://releng.netbsd.org/b5reports/sparc64/2019/2019.12.25.15.56.35/install.log

>Fix:
n/a

>Release-Note:

>Audit-Trail:
From: Andrew Doran <ad@netbsd.org>
To: maxv@netbsd.org, gnats-bugs@netbsd.org, kern-bug-people@netbsd.org,
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc: 
Subject: Re: kern/54800: pool memory corruption
Date: Fri, 27 Dec 2019 01:20:01 +0000

 Max,

 On Thu, Dec 26, 2019 at 09:05:00AM +0000, martin@NetBSD.org wrote:

 > Hidden in the log of the currently failing qemu / anita sparc64 tesst
 > runs you can find this gem:
 > 
 > [ 422.4170018] pool_redzone_check: 0x1257a0c20: 0x00 != 0x66
 > [ 422.4170018] pool_redzone_check: 0x1257a0c21: 0x00 != 0x05
 > 
 > If I read that correctly, a single 16bit halfword supposed to be 0x0f66
 > has been overwritten with 0.
 > 
 > Side question: why is that not worth a panic?

 In rev 1.225 of subr_pool.c you changed this from a panic to a printf.
 It looks like we can make this a panic again.  Do you agree?

 Andrew

From: Maxime Villard <max@m00nbsd.net>
To: Andrew Doran <ad@netbsd.org>, gnats-bugs@netbsd.org,
 kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc: 
Subject: Re: kern/54800: pool memory corruption
Date: Fri, 27 Dec 2019 09:04:40 +0100

 Le 27/12/2019 à 02:20, Andrew Doran a écrit :
 > Max,
 > 
 > On Thu, Dec 26, 2019 at 09:05:00AM +0000, martin@NetBSD.org wrote:
 > 
 >> Hidden in the log of the currently failing qemu / anita sparc64 tesst
 >> runs you can find this gem:
 >>
 >> [ 422.4170018] pool_redzone_check: 0x1257a0c20: 0x00 != 0x66
 >> [ 422.4170018] pool_redzone_check: 0x1257a0c21: 0x00 != 0x05
 >>
 >> If I read that correctly, a single 16bit halfword supposed to be 0x0f66
 >> has been overwritten with 0.
 >>
 >> Side question: why is that not worth a panic?
 > 
 > In rev 1.225 of subr_pool.c you changed this from a panic to a printf.
 > It looks like we can make this a panic again.  Do you agree?
 > 
 > Andrew

 (Have to leave right now but will look at and fix it tonight)

State-Changed-From-To: open->closed
State-Changed-By: hgutch@NetBSD.org
State-Changed-When: Sun, 21 Nov 2021 08:43:37 +0000
State-Changed-Why:
printf() changed back to panic() in r1.264 of subr_pool.c
The actual issue was addressed in PR 54810.


>Unformatted:

Home	PR Database Search