Messages in this thread | | | From | Taehee Yoo <> | Date | Fri, 17 Jan 2020 00:09:24 +0900 | Subject | Re: BUG: MAX_LOCKDEP_CHAINS too low! |
| |
On Thu, 16 Jan 2020 at 06:53, Cong Wang <xiyou.wangcong@gmail.com> wrote: >
Hi Cong,
> On Mon, Jan 13, 2020 at 3:11 AM Dmitry Vyukov <dvyukov@google.com> wrote: > > +Taehee, Cong, > > > > In the other thread Taehee mentioned the creation of dynamic keys for > > net devices that was added recently and that they are subject to some > > limits. > > syzkaller creates lots of net devices for isolation (several dozens > > per test process, but then these can be created and destroyed > > periodically). I wonder if it's the root cause of the lockdep limits > > problems? > > Very possibly. In current code base, there are 4 lockdep keys > per netdev: > > struct lock_class_key qdisc_tx_busylock_key; > struct lock_class_key qdisc_running_key; > struct lock_class_key qdisc_xmit_lock_key; > struct lock_class_key addr_list_lock_key; > > so the number of lockdep keys is at least 4x number of network > devices. > > I think only addr_list_lock_key is necessary as it has a nested > locking use case, all the rest are not. Taehee, do you agree? > > I plan to remove at least qdisc_xmit_lock_key for net-next > after the fix for net gets merged. >
Yes, I fully agree with this. If we calculate the subclass for lock_nested() very well, I think we might use static lockdep key for addr_list_lock_key too. I think "dev->upper_level" and "dev->lower_level" might be used as subclass. These values are updated recursively in master/nomaster operation.
Thank you Taehee Yoo
> Thanks!
| |