scsi: libiscsi: Fix NOP race condition
iSCSI NOPs are sometimes "lost", mistakenly sent to the user-land iscsid daemon instead of handled in the kernel, as they should be, resulting in a message from the daemon like: iscsid: Got nop in, but kernel supports nop handling. This can occur because of the new forward- and back-locks, and the fact that an iSCSI NOP response can occur before processing of the NOP send is complete. This can result in "conn->ping_task" being NULL in iscsi_nop_out_rsp(), when the pointer is actually in the process of being set. To work around this, we add a new state to the "ping_task" pointer. In addition to NULL (not assigned) and a pointer (assigned), we add the state "being set", which is signaled with an INVALID pointer (using "-1"). Link: https://lore.kernel.org/r/20201106193317.16993-1-leeman.duncan@gmail.com Reviewed-by: Mike Christie <michael.christie@oracle.com> Signed-off-by: Lee Duncan <lduncan@suse.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
This commit is contained in:

committed by
Martin K. Petersen

parent
2e6f11a797
commit
fe0a8a95e7
@@ -132,6 +132,9 @@ struct iscsi_task {
|
||||
void *dd_data; /* driver/transport data */
|
||||
};
|
||||
|
||||
/* invalid scsi_task pointer */
|
||||
#define INVALID_SCSI_TASK (struct iscsi_task *)-1l
|
||||
|
||||
static inline int iscsi_task_has_unsol_data(struct iscsi_task *task)
|
||||
{
|
||||
return task->unsol_r2t.data_length > task->unsol_r2t.sent;
|
||||
|
Reference in New Issue
Block a user