netdev - Re: [PATCH] net-sched: add packet length pointer parameter for qdisc

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]

Date:	Thu, 31 Jul 2008 09:36:13 +0000
From:	Jarek Poplawski <jarkao2@...il.com>
To:	Jussi Kivilinna <jussi.kivilinna@...et.fi>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH] net-sched: add packet length pointer parameter for
	qdisc_enqueue

On Thu, Jul 31, 2008 at 12:04:57PM +0300, Jussi Kivilinna wrote:
> Quoting "Jarek Poplawski" <jarkao2@...il.com>:
>
>> On 30-07-2008 20:55, Jussi Kivilinna wrote:
>>> Pass packet length to caller through pointer so that length is
>>> available to caller even if inner qdisc frees skb.
...
>> As I've written before, IMHO using an skb after enqueuing should be
>> avoided unless we refcounted it or the returned code is clear enough,
>> so the idea of this patch could be right to me. But, I guess, you are
>> changing here the way it's done: the size is calculated before the
>> current enqueing instead of after the last one.
>
> Doh, you're right. qdisc->enqueue should pass packet length too.
>
>>
>> BTW, since I don't really get this "stab" idea enough, I wonder how
>> it is expected to be used: with a top qdisc, a leaf one or some
>> summing?
>>
>
> With top and/or leaf qdisc, inner stab overrides upper.

Probably this could be called a bit ugly, but another way could be
simply updating these .bstas.bytes in ->dequeue() with a difference
between calculated and skb->len?

Jarek P.
--
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