linux-kernel - linux-next: manual merge of the rdma tree with Linus' tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20191024110115.7cc32b99@canb.auug.org.au>
Date:   Thu, 24 Oct 2019 11:01:15 +1100
From:   Stephen Rothwell <sfr@...b.auug.org.au>
To:     Doug Ledford <dledford@...hat.com>,
        Jason Gunthorpe <jgg@...lanox.com>
Cc:     Linux Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Erez Alfasi <ereza@...lanox.com>
Subject: linux-next: manual merge of the rdma tree with Linus' tree

Hi all,

Today's linux-next merge of the rdma tree got a conflict in:

  drivers/infiniband/hw/mlx5/odp.c

between commit:

  9dc775e7f550 ("RDMA/odp: Lift umem_mutex out of ib_umem_odp_unmap_dma_pages()")

from Linus' tree and commit:

  a3de94e3d61e ("IB/mlx5: Introduce ODP diagnostic counters")

from the rdma tree.

I fixed it up (see below - but maybe the mlx5_update_odp_stats()
also needs to move after the moved mutex_unlock()?) and can carry the
fix as necessary. This is now fixed as far as linux-next is concerned,
but any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging.  You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/infiniband/hw/mlx5/odp.c
index 3f9478d19376,2ab6e44aeaae..000000000000
--- a/drivers/infiniband/hw/mlx5/odp.c
+++ b/drivers/infiniband/hw/mlx5/odp.c
@@@ -308,6 -282,10 +312,9 @@@ void mlx5_ib_invalidate_range(struct ib
  				   idx - blk_start_idx + 1, 0,
  				   MLX5_IB_UPD_XLT_ZAP |
  				   MLX5_IB_UPD_XLT_ATOMIC);
 -	mutex_unlock(&umem_odp->umem_mutex);
+ 
+ 	mlx5_update_odp_stats(mr, invalidations, invalidations);
+ 
  	/*
  	 * We are now sure that the device will not access the
  	 * memory. We can safely unmap it, and mark it as dirty if
@@@ -316,10 -294,10 +323,11 @@@
  
  	ib_umem_odp_unmap_dma_pages(umem_odp, start, end);
  
+ 
  	if (unlikely(!umem_odp->npages && mr->parent &&
  		     !umem_odp->dying)) {
 -		WRITE_ONCE(umem_odp->dying, 1);
 +		WRITE_ONCE(mr->live, 0);
 +		umem_odp->dying = 1;
  		atomic_inc(&mr->parent->num_leaf_free);
  		schedule_work(&umem_odp->work);
  	}
@@@ -567,8 -542,9 +573,10 @@@ struct mlx5_ib_mr *mlx5_ib_alloc_implic
  	init_waitqueue_head(&imr->q_leaf_free);
  	atomic_set(&imr->num_leaf_free, 0);
  	atomic_set(&imr->num_pending_prefetch, 0);
 +	smp_store_release(&imr->live, 1);
  
+ 	imr->is_odp_implicit = true;
+ 
  	return imr;
  }
  

Content of type "application/pgp-signature" skipped