netdev - Re: qdisc_enqueue, NET_XMIT_SUCCESS and kfree

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, 7 Aug 2008 11:39:30 +0000
From:	Jarek Poplawski <jarkao2@...il.com>
To:	David Miller <davem@...emloft.net>
Cc:	jussi.kivilinna@...et.fi, kaber@...sh.net, netdev@...r.kernel.org
Subject: Re: qdisc_enqueue, NET_XMIT_SUCCESS and kfree_skb

On Thu, Aug 07, 2008 at 03:45:45AM -0700, David Miller wrote:
...
> 
> BTW, speaking of ->requeue(), I think we could easily eliminate
> that thing.  It only exists because we allow drivers to kick things
> back to us via ->hard_start_xmit() return values.
> 
> There are two cases:
> 
> 1) NETDEV_TX_LOCKED... thanks to the bogon named LLTX
> 
> 2) NETDEV_TX_BUSY, which is pretty much a bug
> 
>    %99.999 of the cases that return NETDEV_TX_BUSY are error
>    conditions in the driver which log a message and we could
>    just as validly drop the packet for this case
> 
> But anyways, LLTX isn't dying tomorrow as much as we'd like it go
> away.
> 
> But we could cache the SKB instead of requeueing it, just like how
> we handle the ->gso_skb right now.
> 
> In fact it seems we can just reuse the ->gso_skb Qdisc member for
> this purpose.
> 
> Then all of the ->requeue() code and resulting complexity can just
> go away.

In most cases it looks like the right thing, but it seems there are
cases (RT or OOB) which could need more control on this, so they would
sometimes prefer to change the order of next xmitted packet if
previous had failed, I guess.

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