Fix a missing kref put when isert_conn_established return an error.
By removing set bit ISERT_CONNECTION_ABORTED the connection teardown
will start when recieving the flush WRs.
Signed-off-by: Israel Rukshin <israelr@mellanox.com>
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@6947 d57e44dd-8a1f-0410-8b47-8ef2f437770f
We must wait for both the send and recv cqs to flush all pending work
requests.
To make sure that the drain will be the last flush we post a second
drain work request on the recv queue.
Signed-off-by: Israel Rukshin <israelr@mellanox.com>
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@6946 d57e44dd-8a1f-0410-8b47-8ef2f437770f
Timewait exit event handler start to close iscsi conn
before poll cq finish to handle all the good completions.
This may lead to NULL deref at poll cq context or post recv
after post drain.
This commit close iscsi conn only when start getting flush.
Flush is guaranteed if iscsi conn was created because when allocating
iscsi conn we call post recv.
Signed-off-by: Israel Rukshin <israelr@mellanox.com>
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@6945 d57e44dd-8a1f-0410-8b47-8ef2f437770f
After post drain we are not allowed to call post_recv or post_send,
because the drain must be the last flush to let us know that we may
close the conection safely.
Signed-off-by: Israel Rukshin <israelr@mellanox.com>
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@6943 d57e44dd-8a1f-0410-8b47-8ef2f437770f
The ioctl events may arive after the isert connection has
started the teardown flow.
This scenario may occur on login logout stress.
It may lead to NULL derefrence bugs.
Signed-off-by: Israel Rukshin <israelr@mellanox.com>
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@6940 d57e44dd-8a1f-0410-8b47-8ef2f437770f
On login logout stress we can start a teardown flow before connection is
fully established.
In this case we have one less refcount on isert connection.
Signed-off-by: Israel Rukshin <israelr@mellanox.com>
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@6937 d57e44dd-8a1f-0410-8b47-8ef2f437770f
Clean pointers not to point to invalid memory.
- While conn is released set conn_dev->conn to null as conn is invalid now.
- While conn_dev is released set priv(conn) to null as conn_dev is invalid now.
Signed-off-by: Israel Rukshin <israelr@mellanox.com>
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@6935 d57e44dd-8a1f-0410-8b47-8ef2f437770f
This patch avoids that the following kernel warning appears while
starting SCST after having loaded APTPL PR information:
WARNING: scst/src/scst_dlm.c:461 scst_copy_to_dlm()
Reported-by: <consus@gmx.com>
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@6912 d57e44dd-8a1f-0410-8b47-8ef2f437770f
target_del() calls handle_iscsi_events() which may recursively call target_del().
The 1st target_del() may resume its execution after the target object was already freed.
Signed-off-by: Erez Zilber <erezzi.list@gmail.com>
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@6908 d57e44dd-8a1f-0410-8b47-8ef2f437770f
1. Make PR logging available in the release mode
2. Make /sys/kernel/scst_tgt/trace_level reflect currently available logging
3. Cleanup unused log levels from /sys/kernel/scst_tgt/trace_level
Suggested-by: Consus <consus@gmx.com>
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@6907 d57e44dd-8a1f-0410-8b47-8ef2f437770f
It could happen, if a non-pass-through dev handler erroneously returned
SCST_EXEC_NOT_COMPLETED and TRAGE_DBG() statements enabled in debug mode.
Reported-by: Jeff Goldszer <jeff.goldszer@alebra.com>
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@6905 d57e44dd-8a1f-0410-8b47-8ef2f437770f
manager, and change ALUA state. After that the zvol would be in constant busy
state, even if we remove all scst modules.
The problem is that blockio_on_alua_state_change_finish will unconditionally
vdisk_open_fd. But for the above mentioned case, tgt_dev_cnt will be zero, so
the fd is permanently leaked. We fix this by only do vdisk_open_fd when
tgt_dev_cnt is not zero.
Signed-off-by: Chunwei Chen <david.chen@osnexus.com>
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@6902 d57e44dd-8a1f-0410-8b47-8ef2f437770f
