Hey Sagi, Apologies for the extended delay to follow-up on this.. On Tue, 2015-07-07 at 15:04 +0300, Sagi Grimberg wrote: > On 7/7/2015 12:01 PM, Nicholas A. Bellinger wrote: > > Hey Sagi, > > > > This addresses a regression with traditional iscsi-target that I noticed > > recently, but has not been tested with iser-target yet. > > > > Would you mind taking a quick spin with iser-target to verify, and try > > to intentionally fail iscsit_start_kthreads() into the two out_bitmap + > > out_tx error paths..? > > Umm, I hit a BUG() statement while start to test this. > > The easy reproducer is: > - create 20 iser targets (listen on any 0.0.0.0:3260) > - discover targets 2 initiator ports ports (40 target instances) > - run: for i in `seq 100`; do iscsiadm -m node -l && iscsiadm -m node > -u; done > > Note: I wasn't able to reproduce this with iscsi/tcp. > > Stack dump: > kernel: isert: isert_wait4logout: conn ffff8803db5a9800 > kernel: ------------[ cut here ]------------ > kernel: isert: isert_wait4logout: conn ffff8803db5a9800 wait for conn_logout_comp > kernel: kernel BUG at drivers/target/iscsi/iscsi_target.c:4465! So the proper resolution for this ended up involving moving the call to iscsi_start_kthreads() immediately preceding sending the last login response. This is to ensure that once the last login response is sent signaling transition to full-feature-phase, no resource allocation failures should ever occur. I've verified this with iscsi/tcp and iser-target, and AFAICT the failure cases for iscsi_start_kthreads() are now working as expected. The updated version of this was just sent out as patch #2 in the v4.2-rc fixes series, and has been pushed to target-pending/master here: iscsi-target: Fix iscsit_start_kthreads failure OOPs https://git.kernel.org/cgit/linux/kernel/git/nab/target-pending.git/commit/?id=7238eef0914764211a89c069eef569bc83cb3714 Please review. --nab -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
