[Resending in plain text, apologies.] Hi Chandan, Josef, Chris,
I am not sure I understand the fix to the problem. It may happen that when updating the device tree, we need to allocate a new chunk via do_chunk_alloc (while we are holding the device tree root node locked). This is a legitimate thing for find_free_extent() to do. And do_chunk_alloc() call may lead to call to btrfs_create_pending_block_groups(), which will try to update the device tree. This may happen due to direct call to btrfs_create_pending_block_groups() that exists in do_chunk_alloc(), or perhaps by __btrfs_end_transaction() that find_free_extent() does after it completed chunk allocation (although in this case it will use the transaction that already exists in current->journal_info). So the deadlock still may happen? Thanks, Alex. > > > On Mon, Nov 2, 2015 at 6:52 PM, Chris Mason <c...@fb.com> wrote: >> >> On Mon, Nov 02, 2015 at 01:59:46PM +0530, Chandan Rajendra wrote: >> > When executing generic/001 in a loop on a ppc64 machine (with both >> > sectorsize >> > and nodesize set to 64k), the following call trace is observed, >> >> Thanks Chandan, I hit this same trace on x86-64 with 16K nodes. >> >> -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 > > -- 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
