All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adrian Hunter <adrian.hunter@intel.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: linux-mmc <linux-mmc@vger.kernel.org>,
	Jaehoon Chung <jh80.chung@samsung.com>
Subject: Re: [PATCH v2] mmc: core: Remove redundant rescan_disable flag
Date: Tue, 10 May 2016 12:07:52 +0300	[thread overview]
Message-ID: <5731A4E8.5080608@intel.com> (raw)
In-Reply-To: <CAPDyKFqXEmrAtADNLrEUmF=6oc4-guNTGA=r0UFye3Ox8qO-2w@mail.gmail.com>

On 10/05/16 12:01, Ulf Hansson wrote:
> On 29 April 2016 at 20:40, Adrian Hunter <adrian.hunter@intel.com> wrote:
>> On 28/04/2016 9:29 p.m., Ulf Hansson wrote:
>>>
>>> For the reasons explained below, it's safe to remove the rescan_disable
>>> flag.
>>>
>>> 1)
>>> cancel_delayed_work_sync() prevents an executing work from re-scheduling
>>> itself.
>>>
>>> 2)
>>> We are using the system_freezable_wq for the rescan works. As that queue
>>> becomes frozen when userspace becomes frozen during system PM, we don't
>>> need to disable the rescan works in the PM_SUSPEND_PREPARE phase.
>>
>>
>> What about the case when a SDIO card has to be removed?  Seems like a rescan
>> could theoretically get scheduled and run before the workqueue is frozen.
> 
> When the queue gets frozen, it means currently running works will be
> synced. Works that are scheduled (or becomes scheduled) will be put on
> hold and not allowed to run before the workqueue becomes un-frozen.

In the pm_notifier the workqueue is not frozen, so new work could be queued
and run, which would potentially race with the "host->bus_ops->remove(host)"
a few lines further on.


  reply	other threads:[~2016-05-10  9:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-28 18:29 [PATCH v2] mmc: core: Remove redundant rescan_disable flag Ulf Hansson
2016-04-29 18:40 ` Adrian Hunter
2016-05-10  9:01   ` Ulf Hansson
2016-05-10  9:07     ` Adrian Hunter [this message]
2016-05-10  9:44       ` Ulf Hansson

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=5731A4E8.5080608@intel.com \
    --to=adrian.hunter@intel.com \
    --cc=jh80.chung@samsung.com \
    --cc=linux-mmc@vger.kernel.org \
    --cc=ulf.hansson@linaro.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.