On 06/16/2014 11:06 PM, Tsutomu Itoh wrote: > On 2014/06/17 11:10, Tsutomu Itoh wrote: >> On 2014/06/17 9:47, Chris Mason wrote: >>> On 06/16/2014 07:57 PM, Tsutomu Itoh wrote: >>>> On 2014/06/17 8:52, Chris Mason wrote: >>>>> On 06/16/2014 07:28 PM, Tsutomu Itoh wrote: >>>>>> Hi Chris, >>>>>> >>>>>> On 2014/06/17 2:56, Chris Mason wrote: >>>>>>> On 06/16/2014 02:35 AM, Tsutomu Itoh wrote: >>>>>>>> I encountered soft lockup when executing 'xfstests btrfs/042' on >>>>>>>> 3.16-rc1. >>>>>>>> >>>>>>> >>>>>>> Did we recover, or was it stuck forever? >>>>>> >>>>>> The following messages are repeatedly output. >>>>>> And stuck forever. >>>>>> >>>>>> [ 1147.942181] BUG: soft lockup - CPU#0 stuck for 23s! >>>>>> [kworker/u25:4:5189] >>>>>> [ 1147.967175] BUG: soft lockup - CPU#3 stuck for 23s! >>>>>> [kworker/u25:9:5194] >>>>>> [ 1147.979172] BUG: soft lockup - CPU#4 stuck for 23s! >>>>>> [kworker/u25:15:5200] >>>>>> [ 1147.991169] BUG: soft lockup - CPU#5 stuck for 23s! >>>>>> [kworker/u25:7:5192] >>>>>> [ 1148.064153] BUG: soft lockup - CPU#6 stuck for 23s! >>>>>> [kworker/u26:3:3182] >>>>> >>>>> Can you please capture a stack trace from all the cpus? >>> >>> Very strange, please try to reproduce again, I'll dig through things here. >> >> I can reproduce it easily in my environment. > > This is my reproducer. >
Great, I was able to trigger it here, but only with lockdep disabled. When called from this part of btrfs_search_slot, the code for btrfs_set_path_blocking goes through an extra step to set the lock on the extent buffer we just found blocking before it is put into the path. But this is only done with lockdep on. With lockdep off, we assume the lock ordering inside the tree is protecting us and that we don't need to worry about blocks that are not in the path yet. Something is breaking this rule, probably in the quota code. I'll try to nail down what is going on. -chris -- 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
