With more time spent on this, it feels like some question to be passed along to my former colleagues. Unfortunately the dump does not contain any data that is simple to track because the initial BUG() trigger already ended by the time the final panic is done.
However debug_output() is rather unique for s390x and related to the fast dmesg like debug feature. Toggling the ccw device will attach/detach it to/from the qeth driver which registers/deregisters s390dbf views. De-registration is the problematic part. While that call is taking a mutex and then decrements a ref-count to the debug info area and that in theory should be protected by debug_open() incrementing that reference. But then there is also a snapshot copy copy included in the file info structure and I am not really sure how that exactly relates to the original structure and whether debug_output() would need additional ref-counting. Alternatively I also notice that qeth_core_exit() does not exactly undoes qeth_core_init(). It destroys the workqueue first while that was the first thing to create and the error path of qeth_core_init() would destroy the workqueue as the last thing, after having unregistered the debug views. Whether that really matters in this context, I am not sure. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1797367 Title: Ubuntu 18.04.1 - [s390x] Kernel panic while stressing network bonding To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1797367/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
