[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1349968843.21172.9508.camel@edumazet-glaptop>
Date: Thu, 11 Oct 2012 17:20:43 +0200
From: Eric Dumazet <eric.dumazet@...il.com>
To: Cong Wang <amwang@...hat.com>
Cc: stephen hemminger <shemminger@...tta.com>,
"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
Thomas Graf <tgraf@...hat.com>, rizzo@....unipi.it
Subject: Re: BUG: unable to handle kernel NULL pointer dereference in
qfq_dequeue()
On Thu, 2012-10-11 at 17:05 +0200, Eric Dumazet wrote:
> On Thu, 2012-10-11 at 16:38 +0800, Cong Wang wrote:
> > On Mon, 2012-10-08 at 17:15 +0800, Cong Wang wrote:
> > > Hi, all,
> > >
> > > We got the following kernel crash on RHEL6 and I confirmed upstream has
> > > the same problem (I didn't save this kernel log though):
> >
> > Ok, I got the backtrace of the latest kernel, see below. Seems
> > qfq_slot_scan() in qfq_dequeue() returns something bad, 'cl' becomes
> > '0x10'.
>
> not exactly, cl is -0x50
>
> >
>
>
> static struct qfq_class *qfq_slot_head(struct qfq_group *grp)
> {
> return hlist_entry(grp->slots[grp->front].first,
> struct qfq_class, next);
> }
>
>
> problem is : grp->slots[grp->front].first is NULL here,
>
> so we return RAX = -offsetof(struct qfq_class, next)
>
> (ie -0x50 : ffffffffffffffb0)
>
>
> So one bit is set in full_slots while the corresponding slots[] is
> empty.
>
> I wonder if qfq_slot_remove() is correct ?
I just realize its a 2.6.32 redhat kernel, while QFQ is a 3.0 addition.
Can you reproduce the bug on current kernel (3.6 or git tree)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists