[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAM_iQpUB8v-xN6gmeKpt9BfdQCX6jR5Og6rqL=8EAsj1cNNNxw@mail.gmail.com>
Date: Thu, 10 Jan 2019 10:16:01 -0800
From: Cong Wang <xiyou.wangcong@...il.com>
To: Toke Høiland-Jørgensen <toke@...e.dk>
Cc: Linux Kernel Network Developers <netdev@...r.kernel.org>,
Cake List <cake@...ts.bufferbloat.net>,
Toke Høiland-Jørgensen <toke@...hat.com>
Subject: Re: [PATCH 1/4] sched: Avoid dereferencing skb pointer after child enqueue
On Wed, Jan 9, 2019 at 12:14 AM Toke Høiland-Jørgensen <toke@...e.dk> wrote:
>
> Cong Wang <xiyou.wangcong@...il.com> writes:
>
> > On Mon, Jan 7, 2019 at 11:50 AM Toke Høiland-Jørgensen <toke@...e.dk> wrote:
> >> @@ -1254,7 +1256,7 @@ static int qfq_enqueue(struct sk_buff *skb, struct Qdisc *sch,
> >> if (cl->qdisc->q.qlen != 1) {
> >> if (unlikely(skb == cl->qdisc->ops->peek(cl->qdisc)) &&
> >
> >
> > Isn't this comparison problematic too? While you are on it...
>
> Well, I was only looking at safety issues, and since it's not
> dereferencing the pointer, that's not really an issue here. The check is
> just going to always fail if GSO splitting is enabled. Which I'm not
> actually sure is an error in this case?
Yeah, I knew you only fix defereferences. The comparison is used
to check if the enqueued packet is the head of the queue, which
is incorrect to me for GSO splitting case. Don't worry, we can fix it later.
Powered by blists - more mailing lists