https://bugzilla.kernel.org/show_bug.cgi?id=209253 --- Comment #10 from Ian Pilcher (arequipeno@xxxxxxxxx) --- (In reply to Alex Williamson from comment #7) > Color me suspicious, but there are backtraces from two configurations in the > comments here that have no vfio devices, the original post and Justin's > second trace. The identified commit can only affect vfio configurations. > > All of the backtraces seem to be from triggering this warning: > > __u64 eventfd_signal(struct eventfd_ctx *ctx, __u64 n) > { > unsigned long flags; > > /* > * Deadlock or stack overflow issues can happen if we recurse here > * through waitqueue wakeup handlers. If the caller users potentially > * nested waitqueues with custom wakeup handlers, then it should > * check eventfd_signal_count() before calling this function. If > * it returns true, the eventfd_signal() call should be deferred to a > * safe context. > */ > if (WARN_ON_ONCE(this_cpu_read(eventfd_wake_count))) > return 0; It's quite possible that some of the backtraces in this bug have different root cause(s). That doesn't change the fact that commit c49fa6397b6d29ce10c0ae5b2528bb004a14691f does reliably trigger the WARNING for some of us. > It's not obvious to me how the backtraces shown can lead to recursive > eventfd signals. I've setup a configuration for stress testing, but any > detailed description of a reliable reproducer would be appreciated. Is the VM XML and other information sufficient for you to reproduce? (If not, I can set up access to my hypervisor.) -- You are receiving this mail because: You are watching the assignee of the bug.
