On 06/18/2014 07:10 PM, Josef Bacik wrote:
On 06/18/2014 03:47 PM, Waiman Long wrote:
On 06/18/2014 06:27 PM, Josef Bacik wrote:
On 06/18/2014 03:17 PM, Waiman Long wrote:
On 06/18/2014 04:57 PM, Marc Dionne wrote:
Hi,
I've been seeing very reproducible soft lockups with 3.16-rc1 similar
to what is reported here:
https://urldefense.proofpoint.com/v1/url?u=http://marc.info/?l%3Dlinux-btrfs%26m%3D140290088532203%26w%3D2&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=cKCbChRKsMpTX8ybrSkonQ%3D%3D%0A&m=aoagvtZMwVb16gh1HApZZL00I7eP50GurBpuEo3l%2B5g%3D%0A&s=c62558feb60a480bbb52802093de8c97b5e1f23d4100265b6120c8065bd99565
, along with the
occasional hard lockup, making it impossible to complete a parallel
build on a btrfs filesystem for the package I work on. This was
working fine just a few days before rc1.
Bisecting brought me to the following commit:
commit bd01ec1a13f9a327950c8e3080096446c7804753
Author: Waiman Long<waiman.l...@hp.com>
Date: Mon Feb 3 13:18:57 2014 +0100
x86, locking/rwlocks: Enable qrwlocks on x86
And sure enough if I revert that commit on top of current mainline,
I'm unable to reproduce the soft lockups and hangs.
Marc
The queue rwlock is fair. As a result, recursive read_lock is not
allowed unless the task is in an interrupt context. Doing recursive
read_lock will hang the process when a write_lock happens somewhere in
between. Are recursive read_lock being done in the btrfs code?
We walk down a tree and read lock each node as we walk down, is that
what you mean? Or do you mean read_lock multiple times on the same
lock in the same process, cause we definitely don't do that. Thanks,
Josef
I meant recursively read_lock the same lock in a process.
I take it back, we do actually do this in some cases. Thanks,
Josef
This is what I thought when I looked at the looking code in btrfs. The
unlock code doesn't clear the lock_owner pid, this may cause the
lock_nested to be set incorrectly.
Anyway, are you going to do something about it?
-Longman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
