[KERNEL] Fix several connect/disconnect race conditions

Previously disconnect was protected against concurrent calls, but connect
wasn't. It was easy to crash the kernel when calling connect and
disconnect IOCTLs in a tight loop concurrently.
A global lock was introduced to make sure only one caller can change the
connection state at a time. dev->connection_lock needs to be aquired
when calling dnbd3_net_connect or _disconnect.
This atomic_t based locking mechanism should be turned into a mutex in a
next step, relying on mutex_trylock for cases where we don't have the
cmpxchg-schedule() loop.

Along the way it was noticed that the send/receive timeouts don't apply
to kernel_connect, which might have been the case in older 3.x kernel
versions. A crude workaround using nonblocking connect has been
introduced to emulate this, but a clean solution for this is welcomed.

Also, devices are now properly closed on module unload.

0 files changed, 0 insertions, 0 deletions