linux-toradex.git/drivers/block/drbd/drbd_receiver.c, branch v3.9

drbd: close race between drbd_set_role and drbd_connect

2012-12-06T12:00:33+00:00

drbd_set_role(, R_PRIMARY, ) does the state change to Primary,
some more housekeeping, and possibly generates a new UUID set.

All of this holding the "state_mutex".

The connection handshake involves sending of various state information,
including the current data generation UUID set, and two connection
state changes from C_WF_CONNECTION to C_WF_REPORT_PARAMS further to
a number of different outcomes, resync being one of them.

If the connection handshake happens between the state change to Primary
and the generation of the new UUIDs, the resync decision based on the
old UUID set may be confused, depending on circumstances.

Make sure that, before we do the handshake, any promotion to Primary
role will either be complete (including the housekeeping stuff), or can
see, and serialize with, the ongoing handshake, based on the
"STATE_SENT" bit, which is set when we start the handshake, and cleared
only when we leave C_WF_REPORT_PARAMS again.

Signed-off-by: Philipp Reisner 
Signed-off-by: Lars Ellenberg

drbd: if the replication link breaks during handshake, keep retrying

2012-11-09T13:22:19+00:00

The 8.3.12 commit drbd: Bugfix for the connection behavior fixes a
"wasted established connection", if a former connection attempt failed
during its early stages.

However it opened a window for a regression, if a connection attempt
fails during its last stages.  The result was a terminated receiver
thread, that left behind the supposedly transient "C_UNCONNECTED" state.
Any later requests to change the connection state fail, as they wait for
the connection state to "stabilize".

Fix: short circuit and keep retrying to restablish a new connection,
if we don't reach C_WF_REPORT_PARAMS.

Signed-off-by: Philipp Reisner 
Signed-off-by: Lars Ellenberg

drbd: check return of kmalloc in receive_uuids

2012-11-09T13:22:10+00:00

Signed-off-by: Jing Wang 
Signed-off-by: Philipp Reisner 
Signed-off-by: Lars Ellenberg

Merge branch 'drbd-8.4_ed6' into for-3.8-drivers-drbd-8.4_ed6

2012-11-09T13:20:23+00:00

drbd: Remove duplicate code

2012-11-09T13:11:38+00:00

Signed-off-by: Philipp Reisner 
Signed-off-by: Lars Ellenberg

drbd: Call drbd_md_sync() explicitly after a state change on the connection

2012-11-09T13:11:08+00:00

Without this, the meta-data gets updates after 5 seconds by the
md_sync_timer. Better to do it immeditaly after a state change.

If the asender detects a network failure, it may take a bit until
the worker processes the according after-conn-state-change work item.

  The worker might be blocked in sending something, i.e. it
  takes until it gets into its timeout. That is 6 seconds by
  default which is longer than the 5 seconds of the md_sync_timer.

Signed-off-by: Philipp Reisner 
Signed-off-by: Lars Ellenberg

drbd: properly call drbd_rs_cancel_all() in drbd_disconnected()

2012-11-09T13:08:19+00:00

drbd_disconnected() is supposed to clear the resync lru cache,
by calling drbd_rs_cancel_all().

We must do so before we call drbd_flush_workqueue(), as at least the
callback w_restart_disk_io() may wait for resync progres, and would
otherwise deadlock.

drbd_finish_peer_reqs() may again populate that cache, which will
then potentially be stale after the next resync handshake and bitmap
exchange, we have to do it again after that.

A stale resync lru cache causes no harm but ugly messages like this:
 BAD! sector=196608s enr=6 rs_left=-256 rs_failed=0 count=256 cstate=SyncTarget

Signed-off-by: Philipp Reisner 
Signed-off-by: Lars Ellenberg

drbd: Remove dead code

2012-11-09T13:08:19+00:00

Signed-off-by: Philipp Reisner 
Signed-off-by: Lars Ellenberg

drbd: Avoid NetworkFailure state during disconnect

2012-11-09T13:08:18+00:00

Disconnecting is a cluster wide state change. In case the peer node agrees
to the state transition, it sends back the fact on the meta-data connection
and closes both sockets.

In case the node node that initiated the state transfer sees the closing
action on the data-socket, before the P_STATE_CHG_REPLY packet, it was
going into one of the network failure states.

At least with the fencing option set to something else thatn "dont-care",
the unclean shutdown of the connection causes a short IO freeze or
a fence operation.

Signed-off-by: Philipp Reisner 
Signed-off-by: Lars Ellenberg

drbd: Protect accesses to the uuid set with a spinlock

2012-11-09T13:08:04+00:00

There is at least the worker context, the receiver context, the context of
receiving netlink packts.

Signed-off-by: Philipp Reisner 
Signed-off-by: Lars Ellenberg