Re: [PATCH RFC for-next] net/mlx4_core: Fix racy flow in the driver CQ completion handler

[Or Gerlitz <ogerlitz-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>]

On 10/09/2012 09:57, Jack Morgenstein wrote:
> + *
> + * For API usage, in general,
> + * - any function _modifying_ the the tree or tags (inserting or deleting
> + *   items, setting or clearing tags must exclude other modifications, and
> + *   exclude any functions reading the tree.
> + * - any function _reading_ the the tree or tags (looking up items or tags,
> + *   gang lookups) must exclude modifications to the tree, but may occur
> + *   concurrently with other readers.
> + *
> + * The notable exceptions to this rule are the following functions:
> + * radix_tree_lookup
> + * radix_tree_tag_get
> + * radix_tree_gang_lookup
> + * radix_tree_gang_lookup_tag
> + * radix_tree_tagged
> + *
>
> ======= JPM -- Note the following text! =========================
> + * The first 4 functions are able to be called locklessly, using RCU. The
> + * caller must ensure calls to these functions are made within rcu_read_lock()
> + * regions.
> ===========================================
>
> + * Other readers (lock-free or otherwise) and modifications may be
> + * running concurrently.
>
> Roland, the above states explicitly that radix_tree_lookup should be called only under rcu_read_lock()!
> This is NOT the case in our driver, in mlx4_eq_int()/mlx4_cq_completion() .
>
> Looks to me, then, that the spinlock in mlx4_cq_completion() is required.
>
>

Jack,  Max

Actually, can't we do well with rcu_read_lock() in mlx4_cq_completion() 
as that commit documentation suggests?

Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html