If the previous connection's uses iscsi_event_modify to change the waiting epoll events of the fd, is this possible that the second connection go into an unexpected state? in conn_close() might uses mgmt_end_notify() to do this. I am not sure if the epoll implementation treats two fd with the same number as identical one... 2011/5/23 FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>: > On Sun, 22 May 2011 12:27:57 +0800 > Kiefer Chang <zapchang@xxxxxxxxx> wrote: > >> I'll try to test the patch when I back to work. > > Thanks! > >> Right now we suspect the issue is caused by a unfinished command >> interfering a new logged in connection. >> Suppose a command is during KERNEL state, so tgtd won't abort the >> command immediately. > > Yeah, we can't abort I/O commands in progress. > > >> And the initiator try to logout and re-login the target. The accept >> function call returns the same fd as previous connection. >> After the commands in previous connection return from KERNEL state it >> will use the fd do something (which just the same as the new >> connection). > > The kernel might reuse the same fd but tgtd allocates a new iscsi_connection > strcuture. The fd is binded to the new structure. So commands belonging to the > previous connection don't affect the new conneciton. Do I miss something? > > >> And it may cause the new connection go into the TX state. We test an >> approach to close the fd in ep_release() rather then ep_close(). So a new >> connection won't share the same fd with a connection that has unfinished >> commands. Right now it looks good, more tests need to be done though. -- > > Closing a fd in ep_release() is fine by me but I'm not sure that it fixes > problems. > -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
