public inbox for ath12k@lists.infradead.org
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Kalle Valo <kvalo@kernel.org>
Cc: ath12k@lists.infradead.org, linux-wireless@vger.kernel.org
Subject: Re: [PATCH RFC v2 1/4] wifi: ath12k: switch to using wiphy_lock() and remove ar->conf_mutex
Date: Tue, 24 Sep 2024 11:15:21 +0200	[thread overview]
Message-ID: <9ba6cee6834966401f125a697308cf9faed0d078.camel@sipsolutions.net> (raw)
In-Reply-To: <87o74da025.fsf@kernel.org>

On Tue, 2024-09-24 at 12:11 +0300, Kalle Valo wrote:
> > I don't think this is an issue here, but I'm not sure if you're aware
> > that in general, locking the wiphy mutex in some debugfs file handlers
> > can lead to deadlocks, specifically if those files are later _removed_
> > while holding the wiphy lock, as is e.g. the case for station, netdev
> > and link debugfs files. For this, we have wiphy_locked_debugfs_read()
> > and wiphy_locked_debugfs_write() [1].
> > 
> > [1] you are not required to understand how they are implemented ;-)
> 
> Thanks, this is good to know. I'm not that worried about that, at least
> it's not showing up in my tests, so my plan is to fix that in a separate
> patchset.

I don't think you'd ever even find that in tests, as far as I know
lockdep cannot track these dependencies, and to actually deadlock you'd
have to have the debugfs file(s) kept open by userspace while they're
removed.

In any case, just wanted to give a heads-up that this might be required
in some (future) cases, I didn't see any here where it was needed.

johannes


  reply	other threads:[~2024-09-24 10:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-18 18:10 [PATCH RFC v2 0/4] wifi: ath12k: switch to using wiphy_lock() Kalle Valo
2024-09-18 18:10 ` [PATCH RFC v2 1/4] wifi: ath12k: switch to using wiphy_lock() and remove ar->conf_mutex Kalle Valo
2024-09-19  2:43   ` Baochen Qiang
2024-09-24  8:57     ` Kalle Valo
2024-09-24 10:03       ` Kalle Valo
2024-09-19  7:06   ` Johannes Berg
2024-09-24  9:11     ` Kalle Valo
2024-09-24  9:15       ` Johannes Berg [this message]
2024-09-18 18:10 ` [PATCH RFC v2 2/4] wifi: ath12k: cleanup unneeded labels Kalle Valo
2024-09-18 18:10 ` [PATCH RFC v2 3/4] wifi: ath12k: ath12k_mac_op_set_key(): remove exit label Kalle Valo
2024-09-18 18:10 ` [PATCH RFC v2 4/4] wifi: ath12k: convert struct ath12k_sta::update_wk to use struct wiphy_work Kalle Valo
2024-09-19  3:01   ` Baochen Qiang

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=9ba6cee6834966401f125a697308cf9faed0d078.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=ath12k@lists.infradead.org \
    --cc=kvalo@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox