On 29/5/18 9:53 pm, Andriy Gapon wrote:
On 29/05/2018 14:53, Hans Petter Selasky wrote:
On 05/29/18 13:20, Andriy Gapon wrote:
(kgdb) p *$4.lh_first->c_links.le.le_next
$6 = {
c_links = {
le = {
le_next = 0x0,
le_prev = 0xfe0003999f98
Where does the le_prev point?
On 29/05/2018 14:53, Hans Petter Selasky wrote:
> On 05/29/18 13:20, Andriy Gapon wrote:
>> (kgdb) p *$4.lh_first->c_links.le.le_next
>> $6 = {
>> c_links = {
>> le = {
>> le_next = 0x0,
>> le_prev = 0xfe0003999f98
>
> Where does the le_prev point?
>
> Typically happens
On 05/29/18 13:20, Andriy Gapon wrote:
(kgdb) p *$4.lh_first->c_links.le.le_next
$6 = {
c_links = {
le = {
le_next = 0x0,
le_prev = 0xfe0003999f98
Where does the le_prev point?
Typically happens when callouts are not properly drained before freeing
memory.
--HPS
__
Has anyone else seen this panic?
Any suspect commits?
Any suggestion on analyzing the problem?
Thanks!
panic: Bad link elm 0xfe004bfed798 next->prev != elm
cpuid = 0
time = 1527257839
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00413be770
vpanic(
