From: Dennis Dalessandro <dennis.dalessandro@intel.com>

On 1/14/2020 12:00 PM, Dennis Dalessandro wrote:
> On 1/14/2020 11:57 AM, Jason Gunthorpe wrote:
>> On Tue, Jan 14, 2020 at 09:53:45PM +0530,
>> madhuparnabhowmik04@gmail.com wrote:
>>> From: Madhuparna Bhowmik <madhuparnabhowmik04@gmail.com>
>>>
>>> list_for_each_entry_rcu has built-in RCU and lock checking.
>>> Pass cond argument to list_for_each_entry_rcu.
>>>
>>> Signed-off-by: Madhuparna Bhowmik <madhuparnabhowmik04@gmail.com>
>>>   drivers/infiniband/hw/hfi1/verbs.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/infiniband/hw/hfi1/verbs.c
>>> b/drivers/infiniband/hw/hfi1/verbs.c
>>> index 089e201d7550..22f2d4fd2577 100644
>>> +++ b/drivers/infiniband/hw/hfi1/verbs.c
>>> @@ -515,7 +515,7 @@ static inline void hfi1_handle_packet(struct
>>> hfi1_packet *packet,
>>>                          opa_get_lid(packet->dlid, 9B));
>>>           if (!mcast)
>>>               goto drop;
>>> -        list_for_each_entry_rcu(p, &mcast->qp_list, list) {
>>> +        list_for_each_entry_rcu(p, &mcast->qp_list, list,
>>> lockdep_is_held(&(ibp->rvp.lock))) {
>>
>> Okay, this looks reasonable
>>
>> Mike, Dennis, is this the right lock to test?
>>
>
> I'm looking at that right now actually, I don't think this is correct.
> Wanted to talk to Mike before I send a response though.
>
> -Denny

That's definitely going to throw a ton of lock dep messages. It's not
really the right lock either. Instead what we probably need to do is
what we do in the non-multicast part of the code and take the
rcu_read_lock().

I'd say hold off on this and we'll fix it right. Same goes for the qib one.

Alright, thank you for reviewing.

The rdmavt one though looks to be OK. I'll give it a test.

Thank you,
Madhuparna

-Denny