Hi Ross, Thanks for the report. I have analyzed it here [1] earlier and is harmless since lockdep checks doesn't seem to account for the difference in the lock time-space, there is similar fix in block layer as well (which I am unable to pull the ref as of now, but will try again). And this happened after we have added [2] [1] https://www.spinics.net/lists/linux-btrfs/msg79708.html [2] 542c5908abfe84f7 btrfs: replace uuid_mutex by device_list_mutex in btrfs_open_devices I am consolidating the locks in parts, will be fixed. Thanks, Anand On 07/27/2018 06:09 AM, Ross Zwisler wrote:
I was testing my new xfstest posted here: https://lists.01.org/pipermail/linux-nvdimm/2018-July/016850.html against a btrfs test device + scrach device setup, and hit a lockdep splat. I'm using vanilla v4.18.6. I've attached the splats to this mail, one just as it happened in dmesg and one passed through kasan_symbolize.py for files, line numbers, etc. Thanks, - Ross
-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
