lkml.org 
[lkml]   [2007]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    Subject[patch 02/33] IB/mthca: Fix data corruption after FMR unmap on Sinai
    -stable review patch.  If anyone has any objections, please let us know.

    ------------------
    From: Michael S. Tsirkin <mst@dev.mellanox.co.il>

    In mthca_arbel_fmr_unmap(), the high bits of the key are masked off.
    This gets rid of the effect of adjust_key(), which makes sure that
    bits 3 and 23 of the key are equal when the Sinai throughput
    optimization is enabled, and so it may happen that an FMR will end up
    with bits 3 and 23 in the key being different. This causes data
    corruption, because when enabling the throughput optimization, the
    driver promises the HCA firmware that bits 3 and 23 of all memory keys
    will always be equal.

    Fix by re-applying adjust_key() after masking the key.

    Thanks to Or Gerlitz for reproducing the problem, and Ariel Shahar for
    help in debug.

    Signed-off-by: Michael S. Tsirkin <mst@dev.mellanox.co.il>
    Signed-off-by: Roland Dreier <rolandd@cisco.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

    ---
    drivers/infiniband/hw/mthca/mthca_mr.c | 1 +
    1 file changed, 1 insertion(+)

    --- a/drivers/infiniband/hw/mthca/mthca_mr.c
    +++ b/drivers/infiniband/hw/mthca/mthca_mr.c
    @@ -751,6 +751,7 @@ void mthca_arbel_fmr_unmap(struct mthca_

    key = arbel_key_to_hw_index(fmr->ibmr.lkey);
    key &= dev->limits.num_mpts - 1;
    + key = adjust_key(dev, key);
    fmr->ibmr.lkey = fmr->ibmr.rkey = arbel_hw_index_to_key(key);

    fmr->maps = 0;
    --
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-04-26 19:03    [W:2.678 / U:0.352 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site