net/mlx4_core: Fix FMR unmapping to allow remapping afterward

net/mlx4_core: Fix FMR unmapping to allow remapping afterward

According to device spec we only need to set ownership bit to SW at FMR
unmap, all other stuff we did are redundant and not essential.

This fix is ported from Mellanox OFED 3.1.

It covers some of the same issues fixed in UEK2 with the
following UEK2 commits:
 bbdc2821db04 "mlx4_core: Avoid recycling old FMR R_Keys too soon"
 5bddb281c0f1 "mlx4_ib: unmap FMR should update MPT status to 0xF"

Following comments from bbdc2821db04 patch by Olaf Kirch <okir@lst.de>
adds more useful information about impact of this change on RDS usage
in Oracle applications and copied here to retain useful context.

    When a FMR is unmapped, mlx4 resets the map count to 0, and clears the
    upper part of the R_Key which is used as the sequence counter.

    This poses a problem for RDS, which uses ib_fmr_unmap as a fence
    operation.  RDS assumes that after issuing an unmap, the old R_Keys
    will be invalid for a "reasonable" period of time. For instance,
    Oracle processes uses shared memory buffers allocated from a pool of
    buffers.  When a process dies, we want to reclaim these buffers -- but
    we must make sure there are no pending RDMA operations to/from those
    buffers.  The only way to achieve that is by using unmap and sync the
    TPT.

    However, when the sequence count is reset on unmap, there is a high
    likelihood that a new mapping will be given the same R_Key that was
    issued a few milliseconds ago.

    To prevent this, don't reset the sequence count when unmapping a FMR.

Orabug: 21473880

Signed-off-by: Maor Gottlieb <maorg@mellanox.com>
Signed-off-by: Mukesh Kacker <mukesh.kacker@oracle.com>
Reviewed-by: Yuval Shaia <yuval.shaia@oracle.com>