kern/60919: RAIDframe: failed and spared component autoconfigures as a

["tls%panix.com@localhost via gnats" <gnats-admin%NetBSD.org@localhost>]

>Number:         60919
>Category:       kern
>Synopsis:       RAIDframe: failed and spared component autoconfigures as a
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Oct 24 01:20:00 +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@localhost:/misc/obj64/misc/devel/netbsd/11.0/src/sys/arch/amd64/compile/PANIX-WEBUSER amd64
Architecture: x86_64
Machine: amd64
>Description:
	When a component of an autoconfigurable RAID set is spared out
	and reconstructed onto a spare (or the set is left degraded),
	if that component is present and responsive when the system is
	rebooted, it may autoconfigure as a new, degraded RAID set of
	its own (e.g. half a new mirror) and can even hijack root
	autoconfiguration if the set was root-eligible.

>How-To-Repeat:
	1) Create an autoconfigurable RAID 1 mirror.  Add a hot spare.
	2) Fail one of the drives in the mirror and reconstruct onto the
	   spare.
	3) Reboot the system after reconstruction completes; both the
	   original RAID set, now composed of one original drive plus
	   the spare, will autoconfigure, but so will the drive that
	   was failed out.

	It appears that this happens because when rf_buildroothack()
	loops attempting to configure stacked RAID sets, at the second
	iteration the non-failed drives from the original RAID set are
	held busy, so they are skipped; the spared-out component appears
	to be a lonely remnant of "some other" RAID set and is configured
	as its own new thing.
>Fix:
	

>Unformatted:
 separate RAD set on reboot