lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 3 Apr 2016 21:20:13 -0400
From:	Rich Felker <dalias@...c.org>
To:	linux-spi@...r.kernel.org
Cc:	linux-kernel@...r.kernel.org, Jon Hunter <jonathanh@...dia.com>,
	Vignesh R <vigneshr@...com>, Mark Brown <broonie@...nel.org>
Subject: 4.6-rc1 regression in SPI core -- deadlock

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? I've got it working for
me by disabling the bus locking in __spi_pump_messages entirely (like
before commit 556351f14e74) but I'm pretty sure this breaks the new
feature that was added.

Rich

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ