I am working on a DriverKit driver and we are subclassing IOUserSCSIParallelInterfaceController. I have implemented UserLogicalUnitResetRequest end-to-end and it sends a real Task management IU to the controller and returns the correct kSCSIServiceResponse_*. When I call the hook from within the dext manually it works but I am not able to invoke this UserLogicalUnitResetRequest from macOS.
My question is, under what conditions does macOS itself invoke this hook (or the other five TMF hooks - abort/set, TargetReset, ClearACA/TaskSet)?
I tried to insert a gate at the top of UserProcessParallelTask, which for one chosen target, swallows the incoming task without submitting it to the controller and without completing the OSAction. I then ran normal APFS filesystem IO against the target and observed following:
- Every stalled command arrives with SCSIUserParallelTask.fTimeoutInMilliSec = 0.
- The command hang indefinitely.
- None of the TMF hooks are ever invoked by the framework.
I am not sure if I am doing something wrong here. Is fTimeoutInMilliSec = 0 on filesystem IO expected? Is there a way for the dext to surface a shorter deadline that the framework will watchdog?
What actually invokes the TMF hooks- filesystem-IO timeout escalation, storage recovery, or is there an expectation that the dext runs its own per-command watchdog and invokes its reset code internally?
Any help would be really appreciated!
Thank you for your time!
My question is, under what conditions does macOS itself invoke this hook (or the other five TMF hooks - abort/set, TargetReset, ClearACA/TaskSet)?
So, the answer is that it doesn't. The hooks were added in it's initial implementation but never actually used. They were supposed to be removed before the family was released(r.53420232) but that didn't happen, so they ended up shipping. There's a bug to have them removed (r.185932486), but that hasn't happened yet.
Is fTimeoutInMilliSec = 0 on filesystem IO expected?
Basically, yes. More specifically, the IOKit SCSI/storage layer fully supports timeouts, but the UNIX level I/O layer basically doesn't[1] and, even worse, doesn't necessarily handle failed I/O all that well. Adding to the fun, the FULL range of possible I/O times can be VERY long[2], which makes picking the "right" value quite difficult... so it didn't, and passed "0" instead. That's how it's worked ever since.
Is there a way for the dext to surface a shorter deadline that the framework will watchdog?
Hypothetically, something sending direct SCSI commands (for example, a CD burner) might behave differently, but I think those end up using a totally different command architecture. I'm actually not sure how those would behave, but I can tell you that it won't involve the TMF hooks.
[1] It's very old and kind of terrible.
[2] People used to use tape drives as block storage devices.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
