On Tue, Jun 27, 2017 at 5:54 PM, Gao Feng wrote:
> At 2017-06-28 01:49:50, "Eric Dumazet" wrote:
>>On Tue, 2017-06-27 at 10:08 -0700, Cong Wang wrote:
>>> On Tue, Jun 27, 2017 at 9:50 AM, Eric Dumazet
>>> wrote:
>>> > On Tue, 2017-06-27 at 09:30 -0700, Cong Wang wrote:
>>> >> On Mon, Jun 26, 20
On Tue, 2017-06-27 at 10:08 -0700, Cong Wang wrote:
> On Tue, Jun 27, 2017 at 9:50 AM, Eric Dumazet wrote:
> > On Tue, 2017-06-27 at 09:30 -0700, Cong Wang wrote:
> >> On Mon, Jun 26, 2017 at 6:35 PM, wrote:
> >> > From: Gao Feng
> >> >
> >> > When qdisc fail to init, qdisc_create would invoke
On Tue, Jun 27, 2017 at 9:50 AM, Eric Dumazet wrote:
> On Tue, 2017-06-27 at 09:30 -0700, Cong Wang wrote:
>> On Mon, Jun 26, 2017 at 6:35 PM, wrote:
>> > From: Gao Feng
>> >
>> > When qdisc fail to init, qdisc_create would invoke the destroy callback
>> > to cleanup. But there is no check if t
On Tue, 2017-06-27 at 09:30 -0700, Cong Wang wrote:
> On Mon, Jun 26, 2017 at 6:35 PM, wrote:
> > From: Gao Feng
> >
> > When qdisc fail to init, qdisc_create would invoke the destroy callback
> > to cleanup. But there is no check if the callback exists really. So it
> > would cause the panic if
On Mon, Jun 26, 2017 at 6:35 PM, wrote:
> From: Gao Feng
>
> When qdisc fail to init, qdisc_create would invoke the destroy callback
> to cleanup. But there is no check if the callback exists really. So it
> would cause the panic if there is no real destroy callback like these
> qdisc codel, pfi
