From: Vignesh R <vigneshr-l0cyMroinI0@public.gmane.org>
To: Rich Felker <dalias-8zAoT0mYgF4@public.gmane.org>,
"linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Cc: "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Subject: Re: 4.6-rc1 regression in SPI core -- deadlock
Date: Mon, 4 Apr 2016 09:23:31 +0530 [thread overview]
Message-ID: <5701E53B.5040407@ti.com> (raw)
In-Reply-To: <20160404012013.GA5735-C3MtFaGISjmo6RMmaWD+6Sb1p8zYI1N1@public.gmane.org>
On 04/04/2016 06:50 AM, Rich Felker wrote:
> I've spent several days trying to debug a deadlock using our local
> (not yet ready for upstream) driver for the J-Core SPI device and it
> seems to be a new deadlock in the SPI core caused by commit
> 556351f14e74 and unrelated to the particular driver. Commit
> 49023d2e4ead tried to solve a related deadlock problem, but there
> still seems to be a lock order issue and it's affecting SPI use even
> without the spi_flash_read optimization. The deadlock I'm observing
> has a kworker thread stuck in wait_for_completion called from
> spi_sync_locked (ultimately from mmc_rescan) and the completion is
> never finishing because this kworker thread has the bus locked while
> the spi master task has already started processing the queue but can't
> proceed because the bus lock is taken.
>
> Anyone else seen this? Ideas for a proper fix?
Could you try 24c8cd1b081286("spi: fix possible deadlock between
internal bus locks and bus_lock_flag") from linux-next?
--
Regards
Vignesh
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Vignesh R <vigneshr@ti.com>
To: Rich Felker <dalias@libc.org>,
"linux-spi@vger.kernel.org" <linux-spi@vger.kernel.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Jon Hunter <jonathanh@nvidia.com>,
Mark Brown <broonie@kernel.org>
Subject: Re: 4.6-rc1 regression in SPI core -- deadlock
Date: Mon, 4 Apr 2016 09:23:31 +0530 [thread overview]
Message-ID: <5701E53B.5040407@ti.com> (raw)
In-Reply-To: <20160404012013.GA5735@brightrain.aerifal.cx>
On 04/04/2016 06:50 AM, Rich Felker wrote:
> I've spent several days trying to debug a deadlock using our local
> (not yet ready for upstream) driver for the J-Core SPI device and it
> seems to be a new deadlock in the SPI core caused by commit
> 556351f14e74 and unrelated to the particular driver. Commit
> 49023d2e4ead tried to solve a related deadlock problem, but there
> still seems to be a lock order issue and it's affecting SPI use even
> without the spi_flash_read optimization. The deadlock I'm observing
> has a kworker thread stuck in wait_for_completion called from
> spi_sync_locked (ultimately from mmc_rescan) and the completion is
> never finishing because this kworker thread has the bus locked while
> the spi master task has already started processing the queue but can't
> proceed because the bus lock is taken.
>
> Anyone else seen this? Ideas for a proper fix?
Could you try 24c8cd1b081286("spi: fix possible deadlock between
internal bus locks and bus_lock_flag") from linux-next?
--
Regards
Vignesh
next prev parent reply other threads:[~2016-04-04 3:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-04 1:20 4.6-rc1 regression in SPI core -- deadlock Rich Felker
2016-04-04 1:20 ` Rich Felker
[not found] ` <20160404012013.GA5735-C3MtFaGISjmo6RMmaWD+6Sb1p8zYI1N1@public.gmane.org>
2016-04-04 3:53 ` Vignesh R [this message]
2016-04-04 3:53 ` Vignesh R
[not found] ` <5701E53B.5040407-l0cyMroinI0@public.gmane.org>
2016-04-04 7:04 ` Rich Felker
2016-04-04 7:04 ` Rich Felker
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=5701E53B.5040407@ti.com \
--to=vigneshr-l0cymroini0@public.gmane.org \
--cc=broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=dalias-8zAoT0mYgF4@public.gmane.org \
--cc=jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.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.