Re: "BUG: MAX_LOCKDEP_ENTRIES too low" with 6979 ">s_umount_key"

2020-05-17 Thread Qian Cai
> On May 16, 2020, at 9:16 PM, Waiman Long wrote: > > The lock_list table entries are for tracking a lock's forward and backward > dependencies. The lockdep_chains isn't the right lockdep file to look at. > Instead, check the lockdep files for entries with the maximum BD (backward >

Re: "BUG: MAX_LOCKDEP_ENTRIES too low" with 6979 ">s_umount_key"

2020-05-16 Thread Waiman Long
On 5/15/20 1:21 AM, Qian Cai wrote: Lockdep is screwed here in next-20200514 due to "BUG: MAX_LOCKDEP_ENTRIES too low". One of the traces below pointed to this linux-next commit, 8c8e824d4ef0 watch_queue: Introduce a non-repeating system-unique superblock ID which was accidentally just showed

"BUG: MAX_LOCKDEP_ENTRIES too low" with 6979 ">s_umount_key"

2020-05-14 Thread Qian Cai
Lockdep is screwed here in next-20200514 due to "BUG: MAX_LOCKDEP_ENTRIES too low". One of the traces below pointed to this linux-next commit, 8c8e824d4ef0 watch_queue: Introduce a non-repeating system-unique superblock ID which was accidentally just showed up in next-20200514 along with,