From: Pavel Skripkin <paskripkin@gmail.com>
To: Michael Straube <straube.linux@gmail.com>
Cc: Larry Finger <Larry.Finger@lwfinger.net>,
Phillip Potter <phil@philpotter.co.uk>,
"open list:STAGING SUBSYSTEM" <linux-staging@lists.linux.dev>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Greg KH <gregkh@linuxfoundation.org>
Subject: Re: staging: r8188eu: how to handle nested mutex under spinlock
Date: Sun, 3 Apr 2022 00:13:55 +0300 [thread overview]
Message-ID: <feba8981-5568-fa2f-ccc3-c5debf3c7091@gmail.com> (raw)
In-Reply-To: <356c24cf-625b-eea2-2c04-ce132d881cac@gmail.com>
Hi Michael,
On 4/2/22 23:47, Michael Straube wrote:
> Hi all,
>
> smatch reported a sleeping in atomic context.
>
> rtw_set_802_11_disassociate() <- disables preempt
> -> _rtw_pwr_wakeup()
> -> ips_leave()
>
> rtw_set_802_11_disassociate() takes a spinlock and ips_leave() uses a
> mutex.
>
> I'm fairly new to the locking stuff, but as far as I know this is not a
> false positive since mutex can sleep, but that's not allowed under a
> spinlock.
>
> What is the best way to handle this?
> I'm not sure if converting the mutex to a spinlock (including all the
> other places where the mutex is used) is the right thing to do?
>
I've looked into this like a month ago.
IMO, this code just need to be redesigned, since locking scheme is very
complicated there and, as smatch says, not correct.
Simple s/mutex_lock/spin_lock/ may work in that case, but one day
locking scheme should be reworked... Or just some code parts should be
dropped :))
With regards,
Pavel Skripkin
next prev parent reply other threads:[~2022-04-02 21:14 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-02 20:47 staging: r8188eu: how to handle nested mutex under spinlock Michael Straube
2022-04-02 21:13 ` Pavel Skripkin [this message]
2022-04-02 21:32 ` Larry Finger
2022-04-03 8:44 ` Michael Straube
[not found] ` <4389354.LvFx2qVVIh@leap>
[not found] ` <1813843.tdWV9SEqCh@leap>
2022-04-03 11:08 ` Michael Straube
[not found] ` <7365301.EvYhyI6sBW@leap>
2022-04-03 11:41 ` Michael Straube
2022-04-03 11:48 ` Pavel Skripkin
[not found] ` <1817830.CQOukoFCf9@leap>
2022-04-03 12:14 ` Michael Straube
2022-04-03 12:19 ` Pavel Skripkin
[not found] ` <4412825.cEBGB3zze1@leap>
2022-04-03 12:45 ` Pavel Skripkin
[not found] ` <2029549.KlZ2vcFHjT@leap>
2022-04-03 13:02 ` Pavel Skripkin
2022-04-03 20:51 ` Michael Straube
2022-04-03 21:15 ` Pavel Skripkin
2022-04-04 8:50 ` David Laight
2022-04-04 16:38 ` Pavel Skripkin
2022-04-04 16:59 ` David Laight
2022-04-04 17:12 ` Pavel Skripkin
[not found] ` <1858641.taCxCBeP46@leap>
[not found] ` <2366209.jE0xQCEvom@leap>
2022-04-03 12:18 ` Michael Straube
2022-04-04 13:33 ` Dan Carpenter
2022-04-04 14:16 ` Michael Straube
[not found] ` <3097543.5fSG56mABF@leap>
2022-04-03 11:44 ` Michael Straube
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=feba8981-5568-fa2f-ccc3-c5debf3c7091@gmail.com \
--to=paskripkin@gmail.com \
--cc=Larry.Finger@lwfinger.net \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=phil@philpotter.co.uk \
--cc=straube.linux@gmail.com \
/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