lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.1906241433020.32342@nanos.tec.linutronix.de>
Date:   Mon, 24 Jun 2019 15:18:28 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Dmitry Vyukov <dvyukov@...gle.com>
cc:     Eric Dumazet <eric.dumazet@...il.com>,
        syzbot <syzbot+c4521ac872a4ccc3afec@...kaller.appspotmail.com>,
        Alexander Duyck <alexander.h.duyck@...el.com>,
        amritha.nambiar@...el.com,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        David Miller <davem@...emloft.net>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Ido Schimmel <idosch@...lanox.com>,
        LKML <linux-kernel@...r.kernel.org>,
        netdev <netdev@...r.kernel.org>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
        tyhicks@...onical.com, wanghai26@...wei.com, yuehaibing@...wei.com
Subject: Re: WARNING: ODEBUG bug in netdev_freemem (2)

On Mon, 24 Jun 2019, Dmitry Vyukov wrote:
> On Mon, Jun 24, 2019 at 2:08 PM Eric Dumazet <eric.dumazet@...il.com> wrote:
> > >>> ------------[ cut here ]------------
> > >>> ODEBUG: free active (active state 0) object type: timer_list hint:
> > >>> delayed_work_timer_fn+0x0/0x90 arch/x86/include/asm/paravirt.h:767
> > >>
> > >> One of the cleaned up devices has left an active timer which belongs to a
> > >> delayed work. That's all I can decode out of that splat. :(
> > >
> > > Hi Thomas,
> > >
> > > If ODEBUG would memorize full stack traces for object allocation
> > > (using lib/stackdepot.c), it would make this splat actionable, right?
> > > I've fixed https://bugzilla.kernel.org/show_bug.cgi?id=203969 for this.
> > >
> >
> > Not sure this would help in this case as some netdev are allocated through a generic helper.
> >
> > The driver specific portion might not show up in the stack trace.
> >
> > It would be nice here to get the work queue function pointer,
> > so that it gives us a clue which driver needs a fix.

Hrm. Let me think about a way to achieve that after I handled that
regression which is on my desk.

> I see. But isn't the workqueue callback is cleanup_net in this case
> and is in the stack?
> 
>   cleanup_net+0x3fb/0x960 net/core/net_namespace.c:553
>   process_one_work+0x989/0x1790 kernel/workqueue.c:2269

That's the work which does the cleanup, but I doubt that this is part of
the offending net_device.

Thanks,

	tglx



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ