From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: Adrian Hunter <adrian.hunter@nokia.com>,
"linux-mmc" <linux-mmc@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"linux-pm" <linux-pm@lists.linux-foundation.org>,
"linux-kernel" <linux-kernel@vger.kernel.org>,
Philip Langdale <philipl@overt.org>
Subject: Re: [PATCH 1/2] MMC: fix all hangs related to mmc/sd card insert/removal during suspend/resume.
Date: Mon, 21 Jun 2010 22:26:15 +0200 [thread overview]
Message-ID: <201006212226.15859.rjw@sisk.pl> (raw)
In-Reply-To: <1277151261.5409.30.camel@maxim-laptop>
On Monday, June 21, 2010, Maxim Levitsky wrote:
> On Mon, 2010-06-21 at 23:04 +0300, Adrian Hunter wrote:
> > ext Maxim Levitsky wrote:
> > > If you don't use CONFIG_MMC_UNSAFE_RESUME, as soon as you attempt to
> > > suspend, the card will be removed, therefore this patch doesn't change
> > > the behavior of this option.
> > >
> > > However the removal will be done by pm notifier, which runs while
> > > userspace is still not frozen and thus can freely use del_gendisk,
> > > without the risk of deadlock which would happen otherwise.
> > >
> > >
> > > Card detect workqueue is now freezeable,
> > > therefore if you do use CONFIG_MMC_UNSAFE_RESUME,
> > > and remove the card during suspend, the removal will be
> > > detected as soon as userspace is unfrozen, again at the moment
> > > it is safe to call del_gendisk.
> > >
> > > Tested with and without CONFIG_MMC_UNSAFE_RESUME with suspend and hibernate.
> > >
> > > Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
> > > ---
> > > drivers/mmc/core/core.c | 54 +++++++++++++++++++++++++++------------------
> > > drivers/mmc/core/host.c | 6 +++++
> > > include/linux/mmc/host.h | 3 ++
> > > 3 files changed, 41 insertions(+), 22 deletions(-)
> > >
> > > diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> > > index 569e94d..0cba53a 100644
> > > --- a/drivers/mmc/core/core.c
> > > +++ b/drivers/mmc/core/core.c
> > > @@ -1259,26 +1259,11 @@ int mmc_suspend_host(struct mmc_host *host)
> > >
> > > if (host->caps & MMC_CAP_DISABLE)
> > > cancel_delayed_work(&host->disable);
> > > - cancel_delayed_work(&host->detect);
> > > - mmc_flush_scheduled_work();
> > >
> > > mmc_bus_get(host);
> > > if (host->bus_ops && !host->bus_dead) {
> > > if (host->bus_ops->suspend)
> > > err = host->bus_ops->suspend(host);
> > > - if (err == -ENOSYS || !host->bus_ops->resume) {
> > > - /*
> > > - * We simply "remove" the card in this case.
> > > - * It will be redetected on resume.
> > > - */
> > > - if (host->bus_ops->remove)
> > > - host->bus_ops->remove(host);
> > > - mmc_claim_host(host);
> > > - mmc_detach_bus(host);
> > > - mmc_release_host(host);
> > > - host->pm_flags = 0;
> > > - err = 0;
> > > - }
> > > }
> > > mmc_bus_put(host);
> > >
> > > @@ -1310,12 +1295,6 @@ int mmc_resume_host(struct mmc_host *host)
> > > printk(KERN_WARNING "%s: error %d during resume "
> > > "(card was removed?)\n",
> > > mmc_hostname(host), err);
> > > - if (host->bus_ops->remove)
> > > - host->bus_ops->remove(host);
> > > - mmc_claim_host(host);
> > > - mmc_detach_bus(host);
> > > - mmc_release_host(host);
> > > - /* no need to bother upper layers */
> > > err = 0;
> > > }
> > > }
> > > @@ -1330,6 +1309,37 @@ int mmc_resume_host(struct mmc_host *host)
> > > return err;
> > > }
> > >
> > > +/* Do the card removal on suspend if card is assumed removeable
> > > + * Do that in pm notifier while userspace isn't yet frozen, so we will be able
> > > + to sync the card.
> > > +*/
> > > +int mmc_pm_notify(struct notifier_block *notify_block,
> > > + unsigned long mode, void *unused)
> > > +{
> > > + struct mmc_host *host = container_of(
> > > + notify_block, struct mmc_host, pm_notify);
> > > +
> > > +
> > > + switch (mode) {
> > > + case PM_HIBERNATION_PREPARE:
> > > + case PM_SUSPEND_PREPARE:
> > > +
> > > + if (!host->bus_ops || host->bus_ops->suspend)
> > > + break;
> > > +
> > > + if (host->bus_ops->remove)
> > > + host->bus_ops->remove(host);
> > > + mmc_claim_host(host);
> > > + mmc_detach_bus(host);
> > > + mmc_release_host(host);
> > > + host->pm_flags = 0;
> > > + break;
> >
> > Is it possible that you receive PM_SUSPEND_PREPARE
> > but there is no suspend and therefore no resume
> > and therefore the card is removed but not detected
> > again?
> This is very good point.
> The solution is to kick mmc detection thread from this notifier.
> on resume.
> I update the patch.
>
> >
> > Is it possible that you are racing with kmmcd and the
> > card is added after you receive PM_SUSPEND_PREPARE but
> > before kmmcd is frozen?
> This is unlikely but valid race.
> I afraid I don't know nice way to solve it right now.
> I can add some ad-hoc variable to tell interrupt handler not to kick the
> detection workqueue after suspend notifier was called.
>
> I wish there was a generic freeze_workqueue function.
There are freezable workqueues that are automatically frozen during suspend
by the process freezer. However, at the moment they need to be singlethread
and I'm not sure if using one in this particular case is appropriate.
Rafael
next prev parent reply other threads:[~2010-06-21 20:28 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-17 21:21 [PATCH] Two fixes for my mmc/sd cardreader Maxim Levitsky
2010-06-17 21:23 ` [PATCH 1/2] MMC: fix all hangs related to mmc/sd card insert/removal during suspend/resume Maxim Levitsky
2010-06-21 20:04 ` Adrian Hunter
2010-06-21 20:14 ` Maxim Levitsky
2010-06-21 20:26 ` Rafael J. Wysocki [this message]
2010-06-22 0:03 ` Maxim Levitsky
2010-06-22 9:19 ` Rafael J. Wysocki
2010-06-22 21:17 ` Maxim Levitsky
2010-06-22 21:53 ` Rafael J. Wysocki
2010-06-22 22:20 ` Andrew Morton
2010-06-23 0:16 ` Rafael J. Wysocki
2010-06-23 3:08 ` MMC tree (Was: Re: [PATCH 1/2] MMC: fix all hangs related to mmc/sd card insert/removal during suspend/resume.) Stephen Rothwell
2010-06-23 3:52 ` Andrew Morton
2010-08-13 9:24 ` [PATCH] mmc: build fix: mmc_pm_notify is only available with CONFIG_PM=y Uwe Kleine-König
2010-08-13 10:01 ` Maxim Levitsky
2010-08-16 7:51 ` Maxim Levitsky
2010-08-16 5:28 ` Kukjin Kim
2010-06-17 21:23 ` [PATCH 2/2] mmc: make sdhci work with ricoh mmc controller Maxim Levitsky
2010-06-21 19:21 ` [PATCH] Two fixes for my mmc/sd cardreader Maxim Levitsky
2010-06-21 19:39 ` Andrew Morton
2010-06-21 19:50 ` Maxim Levitsky
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=201006212226.15859.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=adrian.hunter@nokia.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=maximlevitsky@gmail.com \
--cc=philipl@overt.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
Powered by JetHome