linux-kernel-mentees.lists.linuxfoundation.org archive mirror
 help / color / mirror / Atom feed
From: Dennis Dalessandro <dennis.dalessandro@intel.com>
To: Jason Gunthorpe <jgg@ziepe.ca>, madhuparnabhowmik04@gmail.com
Cc: mike.marciniszyn@intel.com, paulmck@kernel.org,
	linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org,
	rcu@vger.kernel.org, joel@joelfernandes.org,
	linux-kernel-mentees@lists.linuxfoundation.org
Subject: Re: [Linux-kernel-mentees] [PATCH 1/3] infiniband: hw: hfi1: verbs.c: Use built-in RCU list checking
Date: Tue, 14 Jan 2020 13:24:00 -0500	[thread overview]
Message-ID: <25133367-6544-d0af-ae30-5178909748b1@intel.com> (raw)
In-Reply-To: <74adec84-ec5b-ea1b-7adf-3f8608838259@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.

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

-Denny
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees

WARNING: multiple messages have this Message-ID (diff)
From: madhuparnabhowmik04@gmail.com
To: dennis.dalessandro@intel.com, Jason Gunthorpe <jgg@ziepe.ca>,
	madhuparnabhowmik04@gmail.com
Cc: mike.marciniszyn@intel.com, paulmck@kernel.org,
	linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org,
	rcu@vger.kernel.org, joel@joelfernandes.org,
	linux-kernel-mentees@lists.linuxfoundation.org
Subject: Re: [Linux-kernel-mentees] [PATCH 1/3] infiniband: hw: hfi1: verbs.c: Use built-in RCU list checking
Date: Wed, 15 Jan 2020 00:04:58 +0530	[thread overview]
Message-ID: <25133367-6544-d0af-ae30-5178909748b1@intel.com> (raw)
Message-ID: <20200114183458.i3u-I4saoSJzxzYptVB6fGxnHvkp60A65SD9o9bG4S0@z> (raw)
In-Reply-To: <74adec84-ec5b-ea1b-7adf-3f8608838259@intel.com>

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
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees

  reply	other threads:[~2020-01-14 18:24 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-14 16:23 [Linux-kernel-mentees] [PATCH 1/3] infiniband: hw: hfi1: verbs.c: Use built-in RCU list checking madhuparnabhowmik04
2020-01-14 16:57 ` Jason Gunthorpe
2020-01-14 17:00   ` Dennis Dalessandro
2020-01-14 18:24     ` Dennis Dalessandro [this message]
2020-01-14 18:34       ` madhuparnabhowmik04
2020-01-14 19:17       ` Joel Fernandes
2020-01-14 19:41       ` Jason Gunthorpe
2020-01-14 19:46         ` Dennis Dalessandro
2020-02-14 15:43       ` Madhuparna Bhowmik
2020-02-14 17:24         ` Dennis Dalessandro
2020-02-14 17:32           ` Madhuparna Bhowmik
  -- strict thread matches above, loose matches on Subject: below --
2020-01-07 19:29 madhuparnabhowmik04
2020-01-07 20:33 ` Jason Gunthorpe
2020-01-08  8:05   ` madhuparnabhowmik04
2020-01-08  8:08   ` madhuparnabhowmik04
2020-01-09 18:10   ` Jason Gunthorpe
2020-01-10 15:54   ` Joel Fernandes
2020-01-07 17:35 madhuparnabhowmik04
2020-01-07 18:26 ` Jason Gunthorpe
2020-01-07 18:35   ` Madhuparna Bhowmik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=25133367-6544-d0af-ae30-5178909748b1@intel.com \
    --to=dennis.dalessandro@intel.com \
    --cc=jgg@ziepe.ca \
    --cc=joel@joelfernandes.org \
    --cc=linux-kernel-mentees@lists.linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=madhuparnabhowmik04@gmail.com \
    --cc=mike.marciniszyn@intel.com \
    --cc=paulmck@kernel.org \
    --cc=rcu@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).