Mark Fasheh wrote on 2016/04/11 11:09 -0700:
On Mon, Apr 11, 2016 at 09:05:47AM +0800, Qu Wenruo wrote:
Mark Fasheh wrote on 2016/04/08 12:18 -0700:
On Fri, Apr 08, 2016 at 03:10:35PM +0200, Holger Hoffstätte wrote:
[cc: Mark and Qu]
On 04/08/16 13:51, Holger Hoffstätte wrote:
On 04/08/16 13:14, Filipe Manana wrote:
Using Chris' for-linus-4.6 branch, which is 4.5-rc6 + all 4.6 btrfs
patches, it didn't reproduce here:
Great, that's good to know (sort of :). Thanks also to Liu Bo.
Are you sure that you are not using some patches not in 4.6?
We have a bingo!
Reverting "qgroup: Fix qgroup accounting when creating snapshot"
>from last Wednesday immediately fixes the problem.
Not surprising, I had some issues testing it out too. I'm pretty sure this
patch is corrupting memory, I just haven't found where yet though my
educated guess is that the transaction is being reused improperly.
--Mark
--
Mark Fasheh
Still digging the bug Mark has reported about the patch.
Good to have another report, as I can't always reproduce the soft
lockup from Mark.
It seems that the WARN_ON will bring another clue to fix it.
BTW, the memory corruption assumption seems to be quite helpful.
I didn't consider in that way, but it seems to be the only reason
causing dead spinlock while no other thread spinning and no lockdep
warning.
It seems to be the call to commit_cowonly_roots() in your patch which sets
everything off. If I remove that call I can run all day without a crash.
Btw, I'm not convinced this fixes the qgroup numbers anyway - we are still
inconsistent even if I don't get a crash.
Have you tested that the actual numbers on your end are coming out ok?
--Mark
Yes, my initial test shows that the snapshot of fs tree doesn't break
the number anymore.
And commit_cowonly_roots() is the core of the fix, without it the bug
won't be fixed.
I'm still digging but it seems to be related to missing
switch_commit_roots() call after commit_cowonly_roots(), but still
uncertain, as I'm not familiar with the commit codes.
Thanks,
Qu
--
Mark Fasheh
--
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
