Hi Chris
On Wed, 13 Jul 2011, Chris Ball wrote:
> Hi Guennadi,
>
> On Mon, Jun 20 2011, Guennadi Liakhovetski wrote:
> > Calling mmc_request_done() under a spinlock with interrupts disabled
> > leads to a recursive spin-lock on request retry path and to
> > scheduling in atomic context. This patch fixes both these problems
> > by moving mmc_request_done() to the scheduler workqueue.
> >
> > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@xxxxxx>
> > ---
> >
> > This is a bug-fix: without it the system Oopses with LOCKDEP enabled, so,
> > it should really go in 3.0. OTOH it is pretty intrusine and non-trivial,
> > so, reviews and tests are highly appreciated! Also, unfortunately, I
> > wasn't able to test it well enough with SDIO, because the driver for the
> > only SDIO card, that I have, reproducibly crashes the kernel:
>
> Having trouble working out how to apply this -- for example, in this hunk:
>
> > @@ -618,7 +631,8 @@ irqreturn_t tmio_mmc_irq(int irq, void *devid)
> > if (ireg & (TMIO_STAT_CARD_INSERT | TMIO_STAT_CARD_REMOVE)) {
> > tmio_mmc_ack_mmc_irqs(host, TMIO_STAT_CARD_INSERT |
> > TMIO_STAT_CARD_REMOVE);
> > - mmc_detect_change(host->mmc, msecs_to_jiffies(100));
> > + if (!work_pending(&host->mmc->detect.work))
> > + mmc_detect_change(host->mmc, msecs_to_jiffies(100));
> > }
> >
> > /* CRC and other errors */
>
> In mmc-next there's a "goto out;" after the mmc_detect_change call, which
> looks like it's always been there. Am I missing a patch this depends on?
>
> (It'd be a good time to get a full set of tmio patches for 3.1 pulled
> together, if you can do that.)
Ok, if you don't mind, I'll get a couple of hours of sleep, and will reply
to you first thing in the morning:-)
Thanks
Guennadi
>
> Thanks!
>
> - Chris.
> --
> Chris Ball <cjb@xxxxxxxxxx> <http://printf.net/>
> One Laptop Per Child
>
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
