kern/59219: umass(4): fails to give up on all I/O promptly when device is yanked

[campbell+netbsd%mumble.net@localhost]

>Number:         59219
>Category:       kern
>Synopsis:       umass(4): fails to give up on all I/O promptly when device is yanked
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Mar 26 16:05:01 +0000 2025
>Originator:     Taylor R Campbell
>Release:        current, 10, 9, ...
>Organization:
The NetUMass Yankation
>Environment:
>Description:
When a umass(4) device is yanked, the kernel has enough information to instantly conclude that the device is gone and all pending I/O should be abandoned, and yet it continues to hang and spew garbage like this:

[ 496464.497266] umass0: BBB reset failed, TIMEOUT
[ 496469.497333] umass0: BBB bulk-in clear stall failed, TIMEOUT
[ 496474.497402] umass0: BBB bulk-out clear stall failed, TIMEOUT
[ 496494.497688] umass0: BBB reset failed, TIMEOUT
[ 496499.497731] umass0: BBB bulk-in clear stall failed, TIMEOUT
[ 496504.497798] umass0: BBB bulk-out clear stall failed, TIMEOUT
[ 496524.498063] umass0: BBB reset failed, TIMEOUT
[ 496529.498130] umass0: BBB bulk-in clear stall failed, TIMEOUT
[ 496534.498196] umass0: BBB bulk-out clear stall failed, TIMEOUT
[ 496554.498462] umass0: BBB reset failed, TIMEOUT

>How-To-Repeat:
yank a umass(4) device while I/O is happening
>Fix:
Yes, please!

umass_detach already sets sc_dying (which really shouldn't be necessary) and aborts the pipes and detaches the children (which really should be enough), but something in the scsipi state machine or something keeps retrying things when it shouldn't.

Also, it looks like umass_detach attempts to abort the pipes multiple times -- first directly, and then via umass_disco.  There should be only one attempt to do this at exactly the correct time, not some flailing to bang on it like whack-a-mole until it's gone.