Re: [PATCH v2 1/1] scsi: libiscsi: fix NOP race condition

2020-10-20 Thread Lee Duncan
On 10/8/20 1:54 PM, Mike Christie wrote: > On 10/8/20 12:11 PM, Mike Christie wrote: >> On 9/25/20 1:41 PM, ldun...@suse.com wrote: >>> From: Lee Duncan >>> >>> iSCSI NOPs are sometimes "lost", mistakenly sent to the >>> user-land iscsid daemon instead of handled in the kernel, >>> as they should

Re: [PATCH v2 1/1] scsi: libiscsi: fix NOP race condition

2020-10-08 Thread Mike Christie
On 10/8/20 12:11 PM, Mike Christie wrote: > On 9/25/20 1:41 PM, ldun...@suse.com wrote: >> From: Lee Duncan >> >> 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:

Re: [PATCH v2 1/1] scsi: libiscsi: fix NOP race condition

2020-10-08 Thread Mike Christie
On 9/25/20 1:41 PM, ldun...@suse.com wrote: > From: Lee Duncan > > 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

Re: [PATCH v2 1/1] scsi: libiscsi: fix NOP race condition

2020-10-02 Thread Lee Duncan
On 9/25/20 11:41 AM, ldun...@suse.com wrote: > From: Lee Duncan > > 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

[PATCH v2 1/1] scsi: libiscsi: fix NOP race condition

2020-09-25 Thread lduncan
From: Lee Duncan 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 forward- and