From: Tony Lindgren <tony@atomide.com>
To: Paul Cercueil <paul@crapouillou.net>
Cc: Bin Liu <b-liu@ti.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Johan Hovold <johan@kernel.org>,
od@zcrc.me, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] usb: musb: Fix runtime PM race in musb_queue_resume_work
Date: Mon, 17 Aug 2020 13:59:26 +0300 [thread overview]
Message-ID: <20200817105926.GF2994@atomide.com> (raw)
In-Reply-To: <20200809125359.31025-1-paul@crapouillou.net>
* Paul Cercueil <paul@crapouillou.net> [200809 12:54]:
> musb_queue_resume_work() would call the provided callback if the runtime
> PM status was 'active'. Otherwise, it would enqueue the request if the
> hardware was still suspended (musb->is_runtime_suspended is true).
>
> This causes a race with the runtime PM handlers, as it is possible to be
> in the case where the runtime PM status is not yet 'active', but the
> hardware has been awaken (PM resume function has been called).
>
> When hitting the race, the resume work was not enqueued, which probably
> triggered other bugs further down the stack. For instance, a telnet
> connection on Ingenic SoCs would result in a 50/50 chance of a
> segmentation fault somewhere in the musb code.
>
> Rework the code so that either we call the callback directly if
> (musb->is_runtime_suspended == 0), or enqueue the query otherwise.
Yes we should use is_runtime_suspended, thanks for fixing it.
Things still work for me so:
Reviewed-by: Tony Lindgren <tony@atomide.com>
Tested-by: Tony Lindgren <tony@atomide.com>
next prev parent reply other threads:[~2020-08-17 10:59 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-09 12:53 [PATCH] usb: musb: Fix runtime PM race in musb_queue_resume_work Paul Cercueil
2020-08-17 10:59 ` Tony Lindgren [this message]
2020-09-28 0:52 ` Paul Cercueil
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=20200817105926.GF2994@atomide.com \
--to=tony@atomide.com \
--cc=b-liu@ti.com \
--cc=gregkh@linuxfoundation.org \
--cc=johan@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=od@zcrc.me \
--cc=paul@crapouillou.net \
--cc=stable@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.