NetBSD Problem Report #60896

From tls@panix.com  Sun Oct 18 02:19:15 2026
Return-Path: <tls@panix.com>
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 "YR1" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 658861A923B
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 18 Oct 2026 02:19:15 +0000 (UTC)
Message-Id: <4j6j6S3k9lzfYm@panix5.panix.com>
Date: Sat, 17 Oct 2026 22:19:12 -0400 (EDT)
From: tls@panix.com
Reply-To: tls@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: RAIDframe: inconsistent handling of queue length
X-Send-Pr-Version: 3.95
X-From4GNATS: "tls@panix.com via gnats" <gnats-admin@NetBSD.org>

>Number:         60896
>Category:       kern
>Synopsis:       RAIDframe: multiple bugs interact so users' queue length settings are ignored or harmful
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          needs-pullups
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Oct 18 02:20:01 +0000 2026
>Closed-Date:    
>Last-Modified:  Sun Oct 18 15:20:02 +0000 2026
>Originator:     Thor Lancelot Simon
>Release:        NetBSD 11.0
>Organization:
>Environment:
System: NetBSD panix5.panix.com 11.0 NetBSD 11.0 (PANIX-WEBUSER) #0: Mon Oct 5 15:33:08 EDT 2026 root@juggler.panix.com:/misc/obj64/misc/devel/netbsd/11.0/src/sys/arch/amd64/compile/PANIX-WEBUSER amd64
Architecture: x86_64
Machine: amd64
>Description:
	The maxOutStandingDiskReqs parameter to RAIDFRAME_CONFIGURE is defined in raidframevar.h
	as a "char".  This of course means the range varies from platform to platform, which is
	"mitigated" in raidctl by the endearing idiom:

    		cfgPtr->maxOutstandingDiskReqs = val;
    		if (cfgPtr->maxOutstandingDiskReqs != val) {
    			warnx("Queue length for %s out of range"
    			    " [%d interp as %d], assuming 1",
    			    buf1, val, cfgPtr->maxOutstandingDiskReqs);
    			cfgPtr->maxOutstandingDiskReqs = 1;
    		}

	So, on different platforms, the range of possible values differs and clamping to 1 may
	or may not occur.  It's also nice that negative values are sometimes accepted.

	The newer "simple" mode (raidctl create) always uses queue length 1 but is
	documented as using 100.  Hooray.

	Finally, if a labelled RAID set is configured via raidframe -c to have a new queue
	length, the new queue length value is used, but not written back to the label, *except*
	in the special case of reconstruction.  Not actually harmless, because (though they
	really shouldn't), mismatched queue length values cause label mismatches and this will
	drop the reconstructed component out of the set at next autoconfigure.  Spooky.

>How-To-Repeat:
	Try to configure a RAID set with queue length 128.
>Fix:
	The "char" can be treated backwards-compatibly as an 8 bit integer ranging from 1 to
	256 (0 is already an illegal and impossible value).  The other two bugs have simple
	fixes as well.

>Release-Note:

>Audit-Trail:

State-Changed-From-To: open->needs-pullups
State-Changed-By: tls@NetBSD.org
State-Changed-When: Sun, 18 Oct 2026 15:00:43 +0000
State-Changed-Why:
Needs pullups.


From: "Thor Lancelot Simon" <tls@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/60896 CVS commit: src
Date: Sun, 18 Oct 2026 14:56:33 +0000

 Module Name:	src
 Committed By:	tls
 Date:		Sun Oct 18 14:56:33 UTC 2026

 Modified Files:
 	src/sbin/raidctl: raidctl.c rf_configure.c
 	src/sys/dev/raidframe: raidframevar.h rf_diskqueue.c rf_diskqueue.h
 	    rf_netbsdkintf.c

 Log Message:
 Fix PR kern/60896 queue-length bugs in RAIDframe configuration.

 Support queue lengths up to 255 (256 could technically be supported
 but this could cause trouble if a user boots an old kernel with a new RAID
 set, so we clamp at 255).

 Correctly update in-core and on-disk queue lengths when they are changed
 via raidctl for an existing set.  Don't treat a mismatched queue length
 in the on-disk label as an error, avoiding breaking RAID sets in some
 reconstruction-to-spare cases.

 Fix raidctl create to use the documented default queue length of 100
 instead of 1.


 To generate a diff of this commit:
 cvs rdiff -u -r1.89 -r1.90 src/sbin/raidctl/raidctl.c
 cvs rdiff -u -r1.37 -r1.38 src/sbin/raidctl/rf_configure.c
 cvs rdiff -u -r1.23 -r1.24 src/sys/dev/raidframe/raidframevar.h
 cvs rdiff -u -r1.65 -r1.66 src/sys/dev/raidframe/rf_diskqueue.c
 cvs rdiff -u -r1.31 -r1.32 src/sys/dev/raidframe/rf_diskqueue.h
 cvs rdiff -u -r1.419 -r1.420 src/sys/dev/raidframe/rf_netbsdkintf.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

>Unformatted:

Home	PR Database Search