All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@kernel.org>
To: Niels Dossche <dossche.niels@gmail.com>
Cc: ath11k@lists.infradead.org, linux-wireless@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Carl Huang <cjhuang@codeaurora.org>
Subject: Re: [PATCH] ath11k: acquire ab->base_lock in unassign when finding the peer by addr
Date: Wed, 16 Mar 2022 16:34:19 +0200	[thread overview]
Message-ID: <87k0cuotjo.fsf@kernel.org> (raw)
In-Reply-To: <c0874b06-116d-7471-3b50-21099c729c3d@gmail.com> (Niels Dossche's message of "Wed, 16 Mar 2022 11:43:30 +0100")

Niels Dossche <dossche.niels@gmail.com> writes:

> On 3/16/22 07:13, Kalle Valo wrote:
>> Niels Dossche <dossche.niels@gmail.com> writes:
>> 
>>> ath11k_peer_find_by_addr states via lockdep that ab->base_lock must be
>>> held when calling that function in order to protect the list. All
>>> callers except ath11k_mac_op_unassign_vif_chanctx have that lock
>>> acquired when calling ath11k_peer_find_by_addr. That lock is also not
>>> transitively held by a path towards ath11k_mac_op_unassign_vif_chanctx.
>>> The solution is to acquire the lock when calling
>>> ath11k_peer_find_by_addr inside ath11k_mac_op_unassign_vif_chanctx.
>>>
>>> Fixes: 701e48a43e15 ("ath11k: add packet log support for QCA6390")
>>> Signed-off-by: Niels Dossche <dossche.niels@gmail.com>
>> 
>> On what hardware and firmware version did you test this?
>> 
>
> Thanks for your reply.
> I am currently working on a static analyser to detect missing locks.
> This was a reported case. I manually verified the report by looking
> at the code, so that I do not send wrong information or patches.
> After concluding that this seems to be a true positive, I created this patch.
> However, as I do not in fact have this particular hardware, I was unable to test it.

Ah, I didn't realise this. If you are using a tool to find errors in the
code it's always a good idea to document that in the commit log. I'll
add an edited version of what wrote you above in the commit log, ok?

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

WARNING: multiple messages have this Message-ID (diff)
From: Kalle Valo <kvalo@kernel.org>
To: Niels Dossche <dossche.niels@gmail.com>
Cc: ath11k@lists.infradead.org, linux-wireless@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Carl Huang <cjhuang@codeaurora.org>
Subject: Re: [PATCH] ath11k: acquire ab->base_lock in unassign when finding the peer by addr
Date: Wed, 16 Mar 2022 16:34:19 +0200	[thread overview]
Message-ID: <87k0cuotjo.fsf@kernel.org> (raw)
In-Reply-To: <c0874b06-116d-7471-3b50-21099c729c3d@gmail.com> (Niels Dossche's message of "Wed, 16 Mar 2022 11:43:30 +0100")

Niels Dossche <dossche.niels@gmail.com> writes:

> On 3/16/22 07:13, Kalle Valo wrote:
>> Niels Dossche <dossche.niels@gmail.com> writes:
>> 
>>> ath11k_peer_find_by_addr states via lockdep that ab->base_lock must be
>>> held when calling that function in order to protect the list. All
>>> callers except ath11k_mac_op_unassign_vif_chanctx have that lock
>>> acquired when calling ath11k_peer_find_by_addr. That lock is also not
>>> transitively held by a path towards ath11k_mac_op_unassign_vif_chanctx.
>>> The solution is to acquire the lock when calling
>>> ath11k_peer_find_by_addr inside ath11k_mac_op_unassign_vif_chanctx.
>>>
>>> Fixes: 701e48a43e15 ("ath11k: add packet log support for QCA6390")
>>> Signed-off-by: Niels Dossche <dossche.niels@gmail.com>
>> 
>> On what hardware and firmware version did you test this?
>> 
>
> Thanks for your reply.
> I am currently working on a static analyser to detect missing locks.
> This was a reported case. I manually verified the report by looking
> at the code, so that I do not send wrong information or patches.
> After concluding that this seems to be a true positive, I created this patch.
> However, as I do not in fact have this particular hardware, I was unable to test it.

Ah, I didn't realise this. If you are using a tool to find errors in the
code it's always a good idea to document that in the commit log. I'll
add an edited version of what wrote you above in the commit log, ok?

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

  reply	other threads:[~2022-03-16 14:34 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-14 21:52 [PATCH] ath11k: acquire ab->base_lock in unassign when finding the peer by addr Niels Dossche
2022-03-14 21:52 ` Niels Dossche
2022-03-16  6:13 ` Kalle Valo
2022-03-16  6:13   ` Kalle Valo
2022-03-16 10:43   ` Niels Dossche
2022-03-16 10:43     ` Niels Dossche
2022-03-16 14:34     ` Kalle Valo [this message]
2022-03-16 14:34       ` Kalle Valo
2022-03-16 14:38       ` Niels Dossche
2022-03-16 14:38         ` Niels Dossche
2022-03-21 10:45 ` Kalle Valo
2022-03-21 10:45   ` Kalle Valo
2022-03-21 11:51   ` Niels Dossche
2022-03-21 11:51     ` Niels Dossche
2022-03-23  8:52 ` Kalle Valo
2022-03-23  8:52   ` Kalle Valo

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=87k0cuotjo.fsf@kernel.org \
    --to=kvalo@kernel.org \
    --cc=ath11k@lists.infradead.org \
    --cc=cjhuang@codeaurora.org \
    --cc=davem@davemloft.net \
    --cc=dossche.niels@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-wireless@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.