From: Nikitas Angelinas <nikitas_angeli...@xyratex.com> Checking the atomic oo_ref in nrs_orr_hop_put_free() and then taking the bucket lock leaves a race window open, by which a second thread can attempt to free an already-freed nrs_orr_object. Fix this, and change the hash bucket lock type from an rwlock to a spinlock, as there are now as many calls on the write path, as there are on the read path. Rehashing is not used on the hashes, so libcfs_hash API usage can also be simplified.
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3430 Lustre-change: http://review.whamcloud.com/7623 Signed-off-by: Nikitas Angelinas <nikitas_angeli...@xyratex.com> Reviewed-by: Liang Zhen <liang.z...@intel.com> Reviewed-by: Emoly Liu <emoly....@intel.com> Reviewed-by: Li Xi <pkuelel...@gmail.com> Reviewed-by: Oleg Drokin <oleg.dro...@intel.com> [pick up only client side of change -- Peng Tao] Signed-off-by: Peng Tao <bergw...@gmail.com> Signed-off-by: Andreas Dilger <andreas.dil...@intel.com> --- drivers/staging/lustre/lustre/include/lustre_net.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/lustre/lustre/include/lustre_net.h b/drivers/staging/lustre/lustre/include/lustre_net.h index 80227e9..8edf542 100644 --- a/drivers/staging/lustre/lustre/include/lustre_net.h +++ b/drivers/staging/lustre/lustre/include/lustre_net.h @@ -1569,7 +1569,7 @@ struct nrs_orr_data { struct ptlrpc_nrs_resource od_res; cfs_binheap_t *od_binheap; struct cfs_hash *od_obj_hash; - struct kmem_cache *od_cache; + struct kmem_cache *od_cache; /** * Used when a new scheduling round commences, in order to synchronize * all object or OST batches with the new round number. @@ -1626,7 +1626,7 @@ struct nrs_orr_object { * scheduling RPCs */ struct nrs_orr_key oo_key; - atomic_t oo_ref; + long oo_ref; /** * Round Robin quantum; the maximum number of RPCs that are allowed to * be scheduled for the object or OST in a single batch of each round. -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
