10640f1bfc
scsipi_xfer structures. When scsipi_execute_xs() calls the driver's scsi_cmd function, it assumes that it can still dereference a pointer to the scsipi_xfer struct. Since scsipi_done() has already been called, which in turn has called scsipi_free_xs(), the struct has already been returned to the pool! In other words, xs->flags has been compromised, but we are still testing it. These changes resolve the problem by doing the following: - In scsipi_execute_xs(), if the lower-level driver's scsi_cmd function returns SUCCESSFULLY_QUEUED and SCSI_NOSLEEP is set in xs->flags, set a new flag (SCSI_ASYNCREQ). This indicates that scsipi_done() should free the scsipi_xfer struct. If the lower-level driver's scsi_cmd function returns SUCCESSFULLY_QUEUED but SCSI_NOSLEEP is not set, we wait (via tsleep()) for the request to complete, then fall through to the COMPLETE case. If the lower-level driver's scsi_cmd function returns COMPLETE, we now simply return any actual errors, or 0 if none occurred. (Previously, we may have returned EJUSTRETURN, of which the sole effect was to avoid freeing the scsipi_xfer struct in our caller. No code seems to depend on this behavior, however.) - In scsipi_done(), only free the scsipi_xfer struct for async requests. The contents of the struct will otherwise remain valid until the function that initiated the transfer frees it. With this change, responsibility for freeing the struct now lies in two places, depending on the type of the request: - For synchronous requests, the routine calling scsipi_execute_xs() must clean up. - For asynchronous requests, scsipi_done() cleans up (as it always has). [Note: this change also corrects a problem with sddump(): scsipi_done() was attempting to return a static scsipi_xfer struct to the pool! Since dumps are performed synchronously, we now handle this correctly.] This solution was provided by Jason Thorpe, after I got him to look at some related (but insufficient) attempts of my own.