BMC/Intel-BMC/linux.git/drivers/md/md-cluster.c, branch dev-4.3

md-cluster: remove inappropriate try_module_get from join()

2015-08-31T17:43:17+00:00

md_setup_cluster already calls try_module_get(), so this try_module_get isn't needed. Also, there is no matching module_put (except in error patch), so this leaves an unbalanced module count. Signed-off-by: NeilBrown

md-cluster: Read the disk bitmap sb and check if it needs recovery

2015-08-31T17:42:41+00:00

In gather_all_resync_info, we need to read the disk bitmap sb and check if it needs recovery. Reviewed-by: Goldwyn Rodrigues Signed-off-by: Guoqing Jiang Signed-off-by: NeilBrown

md-cluster: only call complete(&cinfo->completion) when node join cluster

2015-08-31T17:42:31+00:00

Introduce MD_CLUSTER_BEGIN_JOIN_CLUSTER flag to make sure complete(&cinfo->completion) is only be invoked when node join cluster. Otherwise node failure could also call the complete, and it doesn't make sense to do it. Reviewed-by: Goldwyn Rodrigues Signed-off-by: Guoqing Jiang Signed-off-by: NeilBrown

md-cluster: add missed lockres_free

2015-08-31T17:42:23+00:00

We also need to free the lock resource before goto out. Reviewed-by: Goldwyn Rodrigues Signed-off-by: Guoqing Jiang Signed-off-by: NeilBrown

md-cluster: remove the unused sb_lock

2015-08-31T17:42:14+00:00

The sb_lock is not used anywhere, so let's remove it. Reviewed-by: Goldwyn Rodrigues Signed-off-by: Guoqing Jiang Signed-off-by: NeilBrown

md-cluster: init suspend_list and suspend_lock early in join

2015-08-31T17:42:05+00:00

If the node just join the cluster, and receive the msg from other nodes before init suspend_list, it will cause kernel crash due to NULL pointer dereference, so move the initializations early to fix the bug. md-cluster: Joined cluster 3578507b-e0cb-6d4f-6322-696cd7b1b10c slot 3 BUG: unable to handle kernel NULL pointer dereference at (null) ... ... ... Call Trace: [] process_recvd_msg+0x2e4/0x330 [md_cluster] [] recv_daemon+0x96/0x170 [md_cluster] [] md_thread+0x11d/0x170 [md_mod] [] kthread+0xb4/0xc0 [] ret_from_fork+0x7c/0xb0 ... ... ... RIP [] __remove_suspend_info+0x11/0xa0 [md_cluster] Reviewed-by: Goldwyn Rodrigues Signed-off-by: Guoqing Jiang Signed-off-by: NeilBrown

md-cluster: add the error check if failed to get dlm lock

2015-08-31T17:41:56+00:00

In complicated cluster environment, it is possible that the dlm lock couldn't be get/convert on purpose, the related err info is added for better debug potential issue. For lockres_free, if the lock is blocking by a lock request or conversion request, then dlm_unlock just put it back to grant queue, so need to ensure the lock is free finally. Signed-off-by: Guoqing Jiang Signed-off-by: NeilBrown

md-cluster: init completion within lockres_init

2015-08-31T17:41:50+00:00

We should init completion within lockres_init, otherwise completion could be initialized more than one time during it's life cycle. Reviewed-by: Goldwyn Rodrigues Signed-off-by: Guoqing Jiang Signed-off-by: NeilBrown

md-cluster: fix deadlock issue on message lock

2015-08-31T17:41:41+00:00

There is problem with previous communication mechanism, and we got below deadlock scenario with cluster which has 3 nodes. Sender Receiver Receiver token(EX) message(EX) writes message downconverts message(CR) requests ack(EX) get message(CR) gets message(CR) reads message reads message requests EX on message requests EX on message To fix this problem, we do the following changes: 1. the sender downconverts MESSAGE to CW rather than CR. 2. and the receiver request PR lock not EX lock on message. And in case we failed to down-convert EX to CW on message, it is better to unlock message otherthan still hold the lock. Reviewed-by: Goldwyn Rodrigues Signed-off-by: Lidong Zhong Signed-off-by: Guoqing Jiang Signed-off-by: NeilBrown

md-cluster: transfer the resync ownership to another node

2015-08-31T17:41:12+00:00

When node A stops an array while the array is doing a resync, we need to let another node B take over the resync task. To achieve the goal, we need the A send an explicit BITMAP_NEEDS_SYNC message to the cluster. And the node B which received that message will invoke __recover_slot to do resync. Reviewed-by: Goldwyn Rodrigues Signed-off-by: Guoqing Jiang Signed-off-by: NeilBrown