This patch fixes the problem below. The problem can be reproduced by the
following steps:
1) Connecting all HiNIC interfaces
2) On server side
    # sudo ifconfig eth0 192.168.100.1 up #Using MLX CX4 card
    # iperf -s
3) On client side
    # sudo ifconfig eth0 192.168.100.2 up #Using our HiNIC card
    # iperf -c 192.168.101.1 -P 10 -t 100000

after hours of testing, we will see errors:

    hinic 0000:05:00.0: No MGMT msg handler, mod = 0
    hinic 0000:05:00.0: No MGMT msg handler, mod = 0
    hinic 0000:05:00.0: No MGMT msg handler, mod = 0
    hinic 0000:05:00.0: No MGMT msg handler, mod = 0

The errors are caused by the following problem.
1) The hinic_get_wqe() checks the "wq->delta" to allocate new WQEs:

	if (atomic_sub_return(num_wqebbs, &wq->delta) <= 0) {
		atomic_add(num_wqebbs, &wq->delta);
		return ERR_PTR(-EBUSY);
	}

If the WQE occupies multiple pages, the shadow WQE will be used. Then the
hinic_xmit_frame() fills the WQE.

2) While in parallel with 1), the free_tx_poll() checks the "wq->delta"
to free old WQEs:

	if ((atomic_read(&wq->delta) + num_wqebbs) > wq->q_depth)
		return ERR_PTR(-EBUSY);

There is a probability that the shadow WQE which hinic_xmit_frame() is
using will be damaged by copy_wqe_to_shadow():

	if (curr_pg != end_pg) {
		void *shadow_addr = &wq->shadow_wqe[curr_pg * wq->max_wqe_size];

		copy_wqe_to_shadow(wq, shadow_addr, num_wqebbs, *cons_idx);
		return shadow_addr;
	}

This can cause WQE data error and you will see the above error messages.
This patch fixes the problem.
Signed-off-by: Zhao Chen <zhaochen6@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>