On 8/10/2016 1:51 AM, ira.weiny wrote:
> On Tue, Aug 09, 2016 at 09:11:46PM +0300, Leon Romanovsky wrote:
>> On Tue, Aug 09, 2016 at 11:16:26AM -0400, ira.weiny@xxxxxxxxx wrote:
>>> From: Mike Marciniszyn <mike.marciniszyn@xxxxxxxxx>
>>>
>
> [snip]
>
>>> diff --git a/drivers/infiniband/hw/hfi1/debugfs.c b/drivers/infiniband/hw/hfi1/debugfs.c
>>> index dbab9d9cc288..c35bef8dd5aa 100644
>>> --- a/drivers/infiniband/hw/hfi1/debugfs.c
>>> +++ b/drivers/infiniband/hw/hfi1/debugfs.c
>>> @@ -223,28 +223,35 @@ DEBUGFS_SEQ_FILE_OPEN(ctx_stats)
>>> DEBUGFS_FILE_OPS(ctx_stats);
>>>
>>> static void *_qp_stats_seq_start(struct seq_file *s, loff_t *pos)
>>> -__acquires(RCU)
>>> + __acquires(RCU)
>>> {
>>> struct qp_iter *iter;
>>> loff_t n = *pos;
>>>
>>> - rcu_read_lock();
>>> iter = qp_iter_init(s->private);
>>> +
>>> + /* stop calls rcu_read_unlock */
>>> + rcu_read_lock();
>>
>> IMHO, it should be placed after your if(!iter) check below.
>
> I know this seems weird but this makes the rcu locking "balanced". Returning
> NULL here still calls "stop" which is going to call rcu_read_unlock. If we
> move rcu_read_lock we need to maintain state to determine if we called lock or
> not. This is easier. To me it does seem odd that the sequence operation does
> not stop on its own when NULL is returned but that is the way it works.
>
>>
>>> +
>>> if (!iter)
>>> return NULL;
>>>
>>> - while (n--) {
>>> + if (qp_iter_next(iter)) {
>>> + kfree(iter);
>>> + return NULL;
>>> + }
>>> + while (n--)
>>> if (qp_iter_next(iter)) {
>>> kfree(iter);
>>> return NULL;
>>> }
>>
>> It looks like you forgot to remove the lines above.
>
> Nope this replaces a call to qp_iter_next which was in qp_iter_init.
>
> As the commit messages says we move the implict next's back into the respective
> start functions.
>
> Ira
Thanks, applied.
--
Doug Ledford <dledford@xxxxxxxxxx>
GPG Key ID: 0E572FDD
Attachment:
signature.asc
Description: OpenPGP digital signature
