> [ 36.896465] Trace: > [ 36.896465] [<fffffc0001049c8c>] process_scheduled_works+0xdc/0x420 > [ 36.898418] [<fffffc000104a740>] worker_thread+0x0/0x3d0 > [ 36.899395] [<fffffc000104a8f0>] worker_thread+0x1b0/0x3d0 > [ 36.900371] [<fffffc000104a740>] worker_thread+0x0/0x3d0 > [ 36.901348] [<fffffc000105705c>] kthread+0x17c/0x1c0 > [ 36.902324] [<fffffc000104a740>] worker_thread+0x0/0x3d0 > [ 36.903301] [<fffffc0001011198>] ret_from_kernel_thread+0x18/0x20 > [ 36.904277] [<fffffc0001056ee0>] kthread+0x0/0x1c0 > [ 36.905254] [<fffffc0001011180>] ret_from_kernel_thread+0x0/0x20 Very interesting, both the RCU bugs that I've encountered, kernel kernel threads have been at work just as the stack goes corrupted The stack trace is therefore often incomplete since return addresses have been overwritten by some one of the threads, some information on where this actually happens might therefore be lost on the stack trace. Magnus
